Угу, я не говорил что это guards, просто похожий механизм используеться для сопостовления типу, например:



У тебя нет сопоставление типу (кстати это большое ограничение в языке с динамическими типами), только проверяеться значение как если бы все ветки были универсальный_тип (выражение/guard) ->.... С типами ещё ясно, но с guards которые могут быть любыми выражениями конечно сложно отследить, НО! попытаться стоит и если получиться, респект тебе на всю жизнь 
Можно как то ограничить выражения...


Взгляни на конструкцию выше, это более базовый, универсальный swtich, ты почти у этого (у тебя выражения, а не единственное "равнество значению" для выбора ветки).


Ну язык ещё не вышел, може просто изначально убрать проблему? Сэкономишь много критики   


Попытаюсь на досуге реализовать пару обычных задачек, возможно ещё какие общие требования всплывут. Главное сделать язык удобным, на вид он пока нравиться 

regis, во-первых, присоединяюсь к одобрению Sardar: налицо значительный прогресс 


Меня смущает, что интерпретатор получается монолитным: все библиотеки намертво вкомпилены. Мне кажется, значительно больше пользы может сейчас принести создание FFI, чтобы можно было без проблем создавать модули на Си и других языках, и экспортировать из них в AWL функции, классы и т.д. Тогда можно будет создавать байндинги к любым графическим библиотекам.

И ещё: по-прежнему не хватает документации. Если нет времени и возможности писать её сейчас, то даже грамматика yacc и несколько внутренних заголовочных файлов будут кстати.


В принципе, никто не мешает ввести встроенные функции типа is_integer, чтобы с помощью guards эмулировать сопоставление по типу, если я правильно понял, что ты имеешь в виду.


В случае произвольных выражений в guards, скорее всего, нереально. Ограничить можно (Так, например, сделано в Erlang: в guards разрешён только фиксированный набор операторов и функций с константным временем выполнения, т.к. язык нацелен на софт-реалтайм), но, пожалуй, полезнее будет отслеживать то, что можно, например операторы сравнения чисел (т.е. решать систему линейных неравенств), а остальное отдавать на откуп программисту.

Никто не мешает, но! это не красиво, так же не красиво как множество if...else с instanceof. Во внутренней форме конечно это всё if'ами реализовать просто. Преавда тут маленькая не точность, у меня то "жёсткие типы", потому все эти String, Integer и т.п. имеют смысл, а в AWL типов вроде как нет, следовательно is_integer и прочее не нужно... хотя текущий виртуальный тип можно было бы отслеживать, если только какой другой инновационной идеи за "общим типом" нет 
Но как сказал ранее можно просто попытаться анализировать выражение... я даже не знаю как подступиться к этому...


+1, но для прототипа языка это пока не важно. Модули и бинарная совместимость нужна когда будет точно очерчен и доказан(обоснован) язык, и начнёться следующая стадия: компиляция в промежуточные формы, статистика по коду и отсюда динамические трансформации, JIT компиляция если пойдёт как обычный язык (а в вебе AWL' у ИМХО ничего не светит, его ниша общее программирование...) и другое. Естественно жизнь себе можно очень сильно упростить генеря код под Java/(.Net/mono).


+1 !

Здравствуйте все!
Значит, по порядку:

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

- синтаксис и автогенерированный список функторов будут выложены буквально на днях.

- также и функторы-предикаты для тестирования типов, конечно, будут весьма полезны (is_int, is_string, is_list и так далее). Насчет guards - не знаю (насколько я понимаю, чтобы этот механизм имел смысл, все-таки нужна строгая типизация?)

- насчет монолитности интерпретатора: в принципе, все расширения, такие как интерфейс с Win, несложно вынести в DLL-ки, например. Наверное, когда все будет отлажено, я так и сделаю. Насчет подключения модулей на ходу будет, конечно, сложнее... буду разбираться с FFI. Пока это, действительно, не очень приоритетно.

- JIT-компиляция? Честно говоря, и я так далеко не заглядывал.    Хотя, конечно, было бы здорово, но смущает один момент: насколько я понимаю, чтобы код генерировался более-менее эффективный, нужна строгая типизация? В java или C#, например, именно так обстоит дело. В языке с полностью динамической типовой моделью мне плохо верится в JIT: не могу представить, чтобы это удовлетворительно работало, например, с Perl или Python.

- наконец, о реальной сфере применения AWL. Уже как прикладной скрипт-язык -- было б совсем неплохо! Но и насчет основы для некой альтернативной Web-технологии - я вполне сохраняю оптимизм. (Честно говоря, когда я начинал возиться с этим проектом, мне эта идея казалось полной утопией, а сейчас по прежнему кажется утопией, но уже не такой полной. ;) )

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

guard это условие, отсеивающее ветвь подошедшую по типу значения, просто удобно писать:

Заметь типы в обеих ветвях одинаковые, но guards: v == "строка" и v == "тесты" выфильтровывают не нужне тебе значения. Если все guards конвертнуть во временные уникальные типы, то в match от них можно будет отказаться, но это не читаемо и оскорбительно для человека 


Значит всё таки каждая переменная имеет свой текущий тип? Это не плохо конечно, но тогда просто необходима конструкция match наподобии той, что выше по топу, ибо куча if'ов с is_int, is_list и т.д. есть зло.


Нет, смотри на objective-C 
JIT не компилирует твой код с потерей всех "динамических" качеств. В целом интерпретаторы деляться на два типа:

• те что выполняют AST (исходник деревом), наиболее просто в реализации и наиболее тормознуто
• те что выполняют байт код, подход эффективней и гибче.

Если твой интерпретатор работает с байткодом, то каждая инструкция выполняеться неким куском нативного кода. Простейший JIT, дающий прогу в памяти неимоверных размеров и по скорости медленней чем оригинальный байткод - это просто заменить весь байткод на конкретные инструкции проца и вызовы процедур. Дальше больше, threaded код позволяет сделать софтину малой и быстрой на процах с большим кешем и большой разницей между скоростью проца и скоростью памяти/шины (эта разница только растёт млин...), такой код будет быстрее байткода и иногда быстрее C'шного кода. Нечто среднее из обоих методов + оптимизатор и есть JIT.  При этом те же хеш-таблицы, деревья и прочее чем ты представлял обьекты/структуры остаються такими же, как и сборщик мусора. Просто конвертируеться байткод в нативное + основные либы, например работа с большими числами, могут полностью заменяться более быстрыми аналогами JIT

Прежде всего, выкладываю вот что:

http://awl-project.narod.ru/_functors.htm - каталог функторов

http://awl-project.narod.ru/_synchart.htm - полный синтаксис языка

(Каталог пока неполный, в синтаксической таблице встречаются некоторые глюки, но чем богаты...)





Строго говоря, у переменных типа нет, но вот у значений, которые содержатся в переменных, он, конечно есть. "Куча if-ов", конечно, не лучший вариант: намного изящнее, например, создать список из списков (предикат, имя типа)... , и выполнять поиск в нем -- что нибудь вроде:

TypeChecker = [(! is_int, "Integer") (! is_float, "Float") (! is_string "String")];

(Ну и так далее, сколько потребуется элементов.) Тогда для выражения EXPR можно будет сделать так:

     l_loop (T, TypeChecker, T[0] ! (EXPR) ? TYPE_STR = T[1]:    );

(присваиваем TYPE_STR тип выражения EXPR -- в общем, идея понятна)



Не буду спорить, но мне казалось, что байт-код и JIT -- разные вещи, и втрой термин, вроде, предполагает именно генерацию фрагментиков машинного кода (родного для хост архитектуры). В крайнем, случае, возможно, речь идет о "шитом коде", т.е. генерируются адреса рутин, которые потом напрямую вызываются. Хотя, конечно, тут я совсем не эксперт и могу плавать. ;)

Вот вопрос "AST versus байткод" -- тема интересная. Мне не раз встречались упоминания того, что байт-код, в принципе, эффективнее, чем AST, но пока не совсем ясно, за счет чего. Видимо, потому, что ссылки на код "ближе" друг к другу, кэш используется более эффективно, и это дает выигрыш?



Это сообщение отредактировал(а) regis - 10.8.2006, 12:28

Пока со всеми прощаюсь: ухожу в отпуск! Недели четыре меня в Интернете не будет.

Но, надеюсь, когда вернусь, смогу уже продемонстрировать что-нибудь новое.

I'm back! ;)

Пока хочу предложить вашему вниманию, новый, основательно подправленный и дополненный мануал по AWL - http://awl-project.narod.ru/AWL-doc.pdf. (Описания средств ООП, массивов и хэшей пока там нет, будут в следующем издании.) А пока очень рассчитываю на критику (конструктивную), и, если какие-то вопросы, тоже прошу не стесняться.

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



Это сообщение отредактировал(а) regis - 21.9.2006, 15:16

regis, файл не открываеться, ридер ругаеться. Отправь мне на мыло, положу на нормальное зеркало. Вообще отстойным народом.ру не нужно пользоваться 

ja.doma (где гулял с собакой) gмаил _точка_ цом

Может, он просто не докачался (размер должен быть 390,111)? Я скачал его FDM-ом, проверил, вроде нормально открывается... Хотя то, что народ -- весьма отстойный хостер -- увы, правда.  

А ваш адрес хочу уточнить: ja.doma <<@>> gmail <<.>> com ( без лишних <> и пробелов, конечно)?

Да, боязнь спамеров теперь уже образ жизни (15-45 в сутки получаю, благо выфильтровываютсья гуглом хорошо).

OK. Отослал.

На зеркале: http://sardar.vingrad.ru/AWL/AWL-doc.pdf

Спасибо!

Новая версия и немного новых примеров:

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

Здесь уже есть полноценная оконная система, основанная на иерархии виджетов, хотя ее еще предстоит дорабатывать. Вот с документированностью ООП AWL пока плохо, так что если будут вопросы, не стесняйтесь. Если будут проблемы скачивания с народа --  могу выслать на мэйл.