regis, я бы с удовольствием, но у меня Access Denied (черт бы побрал провайдера). Выложите куда-нибудь в другое место или кидайте мне на мыло. 

Void, отослал вам на e-mail.

А что у вас с провайдером: не дает скачивать файлы с народа.ру, или как?
 

Итак, посмотрел новую версию AWL. Не скажу, что плотно тестировал, но не нашел к чему придраться с т.з. техники, разве что к отсутствию нормальной документации (надпись «106 функторов» только дразнит  ).

Предложение опубликовать исходники (под любой лицензией) остается в силе. 

Спасибо! Но вы мне здорово льстите -- багов в интерпретаторе до сих пор достаточно много. (Часть из них я уже нашел, но где они не скажу ;) )

Исходники будут опубликовны. Планирую их выложить, как только приведу в такое состояние, что за них не будет стыдно. ;)

И документация тоже будет. Скоро будут автоматически генерироваться (из исходников) полный список функторов + строгое описание синтаксиса языка. (Все это, правда, уже будет на английском.)

Теперь всем кто интересовался проектом: хотел бы знать ваше мнение по поводу идей и перспектив развития языка.

1) Должен ли, например, AWL иметь больше особенностей из функциональных языков? Должны ли поддерживаться closures и continuations? Какие виды структурирования данных желательно иметь (N-мерные массивы и хэши скоро будут, а еще?)

2) Любые предложения и идеи касательно реализации ООП в AWL.

3) Подумываю также, чтобы реализовать Win-интерфейс, пока в простейшем виде, чтобы можно было хотя бы открывать окошки и рисовать в них что-нибудь. В связи с этим можно обсудить уже существующие в скрипт языках средства GUI (Tcl/Tk, Perl + Prima и т.д.) Что советуете взять за основу?

 

Я же сказал, что тестировал достаточно поверхностно 

No problem.

Обязательно функторы как first-class values: должно быть возможно принимать их в качестве параметров и возвращать из других функторов. Отсюда с очевидностью следует необходимость замыканий.
Насчет continuations и currying (partial function application) не уверен.

Кортежи? Как эффективные списки фиксированной длины.
Еще вопрос в тему: нужен ли pattern matching?

Сложный вопрос. Если в полезности всех предыдущих предложений я заранее уверен, тут надо думать, чт́о будет удобнее, для каких целей…
Кроме модели Python/Ruby (dynamic strong duck typing) ничего в голову пока не идет.

Так или иначе должна присутствовать обработка ошибок, наверное, в виде exceptions handling. 

Фактически, функторы уже реализованы как вполне полноценный тип данных: можно создавать анонимные функторы, можно присваивать их переменным, передавать как параметры и возвращать значением из других функторов. Но и в случае это не будут замыкания (значения локальных параметров теряются после возврата).

Кстати, интересно было б знать, как реализованы замыкания в других языках -- сохраняется весь контекст вызова функции, или как?



Кортежи -- это, как я понимаю, то, что в Python называется tuples?

А pattern matching -- это регулярные выражения? Они, конечно, будут.



Согласен, что исключения должны быть. Тем более, что, похоже, это будет основной и единственный способ явной передачи управления.

 

В принципе, да. В компилируемых языках можно позволить себе оптимизацию на основе статического анализа использования замыкания.
Не знаю, как это ложится на рантайм-модель AWL, но мне реализация видится примерно следующей: при входе в функтор выделяется объект, хранящий локальное состояние функции (фактически, фрейм стека виртуальной машины). С любым функтором связывается фрейм его внешнего окружения. Разумеется, на фрейм должны считаться ссылки (или он должен собираться GC), чтобы решить проблему времени жизни замыкания, превышающего время жизни контекста вызова.
Кстати, у Аппеля в Tiger Books (Modern Compiler Implementation in C/Java/ML) есть кое-что по этому поводу, хотя в целом книги нацелена на статические компилируемые языки. Если найдете “…in ML” в электронном виде, сообщите пожалуйста, буду очень благодарен 

Да. Собственно, везде, где они есть, они называются tuples 

Я не совсем то имел в виду. Регулярные выражения лично я предпочитаю видеть библиотекой, а не вшитым в язык набором конструкций. Впрочем, в AWL трудно провести границу, учитывая, что любые операции есть функторы. А под pattern matching я имел в виду это (ну или это). Затрудняюсь оценить полезность сопоставления с образцом в скриптовом языке, просто для меня эта возможность автоматически записывается в “+” любого языка, который ее поддерживает.

Добавлено @ 18:12 
Кстати, как насчет инфиксных функторов, определяемых пользователем? 

Именно в этом то проблема (рантайм-модель, и язык сугубо бестиповой).
(М.б. попытаться "обернуть" возвращаемый функтор в некий (систменый) объект, сохраняющий контекст хотя бы частично? Вот это может сработать. Подумаю...)

Кстати: было б интересно взглянуть на практическое применение замыканий. Я имею в виду не простенькие иллюстрации этой концепции (которые можно найти в man для perl, например), а конкретный пример задачи, которая с использованием замыканий решается существенно проще/изащней, чем без оных. Если дадите ссылку, буду очень благодарен!



Если найду в e-виде, обязательно кину ссылку.



Хмм, сначала попробую получше разобраться в концепции, а потом скажу, нужна она в AWL или нет. ;)



Ну, по большому счету это уже расширение синтаксиса. Учитывая то, что парсер реализован вполне стандартно (flex + bison), это будет сделать непросто -- там особо синтаксис не порасширяешь.
 

Собственно, именно это я и предложил  Просто условно разделил «системный объект» на собственно функтор (я так понимаю, на уровне рантайма он имеет древовидное представление — AST) и его контекст, который я не очень остроумно обозвал фреймом.

imho, б́ольшее практическое значение имеют не замыкания сами по себе, а функции высшего порядка. Однако без замыканий HOF теряют значительную часть своей выразительности.

Мне очень неудобно давать ссылку на самого себя, но так уж получилось, что буквально вчера я пытался пролить свет на этот вопрос в другой теме 

Понятно. Что ж, отложим этот вопрос на неопределенный срок. 

Я имел в виду именно то, что в AWL "оборачивание" придется делать как-то явным образом (наверное). Приведу пример: если нам нужен генератор функций, прибавляющих что-то к аргументу. В AWL уже можно написать довольно изящно:

` Генератор унарной функции, прибавляющей фиксированную константу N к аргументу X `
! make_adder (N) = !(X) = (X + N);

вот только работать это правильно не будет (значение N вне вызова make_adder будет undef).

С другой стороны, если добавить специальную конструкцию для сохранения каких-то переменных контекста (скажем bind (A, B, C...) сохраняет переменные A B C...), то можно написать нечто вроде:

! make_adder (N) = bind (N, !(X) = (X + N));

и вот это уже будет полноценным замыканием. Не ручаюсь, что все будет именно так, просто иллюстрирую идею.



Спасибо за ссылку. Скачал "Функциональное программирование" Филда и Харрисона -- буду читать понемногу.



Кстати говоря, можно реализовать средствами самого языка очень многие синтаксические расширения. (В сущности, свой мини-парсер можно смастерить и им пользоваться.) Ну, например, если очень хочется иметь инфиксные бинарные операции (op1, op2...), не так уж трудно написать функтор вроде my_parser который понимал бы что-нибудь вроде:

my_parser ([EXPR1 op1 EXPR2 op2 EXPR3 op1 EXPR4])

и автоматически переводил это скажем в

func_op2 (func_op1 (EXPR1, EXPR2), func_op1 (EXPR3, EXPR4)).

причем можно определить любой набор своих операций со своей привязкой к функторам, приоритетами и ассоциативностями.

Еще раз спасибо! Кстати, хотел вам добавить + в репутацию, но выяснил, что для этого 100 постов надо иметь. Примите пока словестную благодарность за помощь и интерес к моему проекту. ;)
 

Работа понемногу продолжается. Уже скоро будет доступна для тестирования новая версия AWL -- с базовыми средствами ООП, поддержкой модуляризации (через include) и другими приятными вещами.

Пока я ее тестирую, про новые возможности можно почитать вот здесь:

http://awl-project.narod.ru/AWL-new.htm

Любые комментарии, как всегда, приветствуются. Если что-то непонятно, не стесняйтесь спрашивать здесь -- постараюсь ответить.
 

Как я вижу, счетчик посещений растет, но люди все равно молчат, как партизаны.   

Впрочем, их дело. Новость, которой хочу поделится,  состоит в том, что я уже понемногу подключаю интерпретатор к Win, и собираюсь написать несколько простых программ, рисующих в окнах что-нибудь простое, но красивое (напр., фрактальные кривые). Как только будет готово, выложу здесь (вместе с интерпретатором).
 

Выкладываю:

http://awl-project.narod.ru/awl-030806.zip

regis, круто!
Успел заметить  BINTREE.AWL -> BTree.Insert, сопоставление значению (cmp), компилер не отслеживает все возможные вариации и ответвления, это на дебаге сильно сказываеться. В OCaml компилер сразу может определить при каком условии ни одна из веток не будет подходящей, следовательно либо ты учитываешь этот вариант, либо добавляешь ветку "всё остальное" (_), в котором обычно кидаешь исключение. Правда компилер ошибаеться если используються guards, но это мелочи   Главное меньше ошибок можно допустить, ясность кода.

В целом очень одобрямс  

P.S. возможность не явного декларирования локальных переменных в функторе есть страшное зло, которое лучше отключить. Как ты правильно заметил результат будет не предсказуем если такая переменная была определена выше по контексту ("снаружи"), следовательно убери эту ещё одну возможность выстрелить себе в ногу 

Строго говоря, это не guards (таких вещей в AWL нет пока), а обычный условный оператор с несколькими ветвями. Т.О. вся ответственность за логику проверяемого условия лежит на программисте. М.б. надо добавить что-нибудь вроде switch, причем чтобы интерпретатор проверял логическую непротиворечивость условий? Тут есть о чем подумать.



Тут полностью согласен, что это не такая удачная идея, как мне раньше казалось. Теперь мне как минимум очевидно, что если переменная не декларирована явно в функторе/классе, то она должна попадать в *глобальное* пространство имен. Ну, а если будет режим, требующий явного объявления всех переменных (типа use strict в Perl), то в этом случае будут варнинги или ошибки.



Спасибо! То ли еще будет...
Я пока только сделал самый примитивный интерфейс с Win API; в будущем, конечно, вся обработка Win-сообщений, например, будет не такой неуклюжей, как сейчас -- все будет упаковано в удобную ООП-оболочку. И, конечно, графических, шрифтовых и пр. примитивов будет намного больше. Думаю, что скоро на AWL уже простенькие игрушки можно будет писать.   



Это сообщение отредактировал(а) regis - 4.8.2006, 13:36