Sardar, прежде всего, спасибо! Вижу, что статью Вы посмотрели. ;)



Все совершенно правильно -- в AWL: 1) вообще нет деклараций типов, 2) автоматические преобразования между скалярными типами (напр. числа <-> строки).
Но вот как аккуратно выразить эту мысль на английском?



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





Именно так: <: - это оператор вывода, причем если первый операнд является потоком стандартного вывода (это не обязательно консоль!), он может опускаться. Что же тут такого угнетающего? IMHO, читается получше, чем операции ввода-вывода в C++ типа

cout << xx << "," << yy << "," << zz;

Но вот если б в C++ еще добавили отдельные операции ввода/вывода (перегрузка << и >> явно была не самой удачной идеей), и еще разрешили опускать первый операнд, когда он самоочевиден -- то получилось бы примерно то же, что и в AWL.
Теперь по поводу списков:



Нет, как раз со списком будет самый эффективный вариант. Если вы думаете, что вычисление списка непременно создает его копию -- это, конечно, неверно. При выполнении приведенного кода *вообще* никаких операций выделения памяти не будет. (Кстати, в AWL начиная примерно с 5.0.1 работа со списками оптимизирована довольно хорошо: по умолчанию списки никогда не копируются без нужды. Если явно нужна копия списка List, примените l_copy(List)).



Разумеется, есть такой! A +$ B (или s_cat(A,B)) -- конкатенация A и B, рассматриваемых как строки. С его помощью этот код можно переписать так:



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



Как я понял, вы про пример "Ханойские башни"? Ну, здесь в принципе трудно обойтись без рекурсии, алгоритм такой.



Для этого, прежде всего, нужно заложить в компилер какой-то критерий того, что является "простым" вызовом, и что -- нет. Это далеко не очевидно.
В принципе, здесь стоит ориентироваться на то, как сделано в Scheme. (Там кроме собственно "функций" допустимы "макросы" -- по сути, инлайн функции, код которых подставляется при компиляции. Сделано все это очень культурно. Достаточно сказать, что немало штатных средств языка является такими макросами, подставляемыми незаметно для пользователя. Сделать похожий механизм в AWL -- очень соблазнительно.
Но, в любом случае, это должно быть явным, без самодеятельности компилятора.)



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



Нет, имеется в виду совершенно другое. Попробую объяснить этот механизм на пальцах.

В большинстве ОО-языков операции над объектами реализуются через методы класса. С технической точки зрения, что метод имеет один неявный аргумент (ссылку на объект) вдобавок ко всем прочим, и так получает доступ к этому объекту. Другими словами, связывание "класс-экземпляр" происходит при вызове методов (а время его действия ограничено времением выполнения метода). В AWL все не так.

Упомянутое связывание реализуется отдельной операцией:



формально означает "для object (как текущего экземпляра своего класса) вычислить/выполнить expr". В частности: object.component позволяет обратиться к компоненте object; object.method (...) -- вызвать метод применительно к object и т.д., как в большинстве ОО-языков. НО: выражение expr может быть *произвольным* (т.е. включать обращения к разным компонентам, вызовы разных методов и т.п.) В сущности, операция '.' в AWL работает примерно как with в Паскале (в C++ или Java аналогов нет).

Как все это правильно назвать по английски -- не знаю. Наверно, термин надо придумывать: точных аналогов именно такой ОО-модели, вроде, нигде не встречается. А жаль!



А вот здесь не вижу конкретики: что именно и как стоит улучшить. ;)
Ничего особенно страшного в синтаксисе нет. Любой незнакомый язык поначалу производит пугающее впечатление, но в процессе обучения это обычно проходит. ;)
И насчет синтаксического сахара замечание странноватое: 90% синтаксиса AWL (практически все унарные-бинарные операции с их приоритетами и т.п.) представляет собой как раз тот самый сахар. Без него AWL код представлял бы собой практически чистый аналог LISP (разве что там сплошные вложенные списки, а в AWL была бы смесь вложенных списков, вызовов функторов и блоков). Внутреннее представление программы именно таким и является. Впрочем, никто не мешает совсем забыть про "сахар", и программировать именно в таком стиле -- просто это, ИМХО, непрактично.



В этом примере я не совсем понял, что делает iterator(1024), и какая связь между переменной block и телом цикла (она там вроде не используется?) Но, в общем, все это тривиально переводится на AWL и будет выглядеть примерно так:



Как видите, разница невелика.
Понятно, здесь предполагается что функторы some_rolling_checksum и md5 определены где-то, а к объекту File применим "метод" reader.
А итератор l_loop -- и есть аналог для for ... in ...
Подробнее здесь:
http://awl-project.narod.ru/func_main.html#func_l_loop


Это сообщение отредактировал(а) regis - 26.4.2007, 10:57

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

Интересно как передать функции список, так что бы он не развернулся на параметры? Не стоило ли сделать для этого отдельный оператор как в Python'е?



А почему нельзя было просто print или echo? Как сторонний человек без предрассудков по языкам, "<:" воспринимается гораздо хуже чем слово 
А вообще print должно быть некой общей API функцией пишущей в любой поток (поточное, не блокирующее IO тоже нужно). Как часть языка оно смотрится не очень...


Чем больше смотрю на синтаксис, тем больше понимаю что это шифровка 
Интересно узнать как реализованы списки. Быть может к лету напишу простейший транслятор AWL -> Java.


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

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

Компилер пусть снабжает функции аннотациями, контролирующими процесс линковки. Например к вызову может добавить тег try-inline, если вызываемая функция оказывалась годной для вставки. Тогда на момент линковки загрузчик может следовать советам компилера и пробовать только помеченные вызовы, тем самым поднимая скорость загрузки. Естественно в памяти всей этой метаинфы уже нет, загруженные модули слинкованы на прямую.


Очень смахивает JavaScript и по моему Objective-C. В рантайме искать свойства/методы объекта просто, но накладно. У тебя получилось реализовать это без постоянного поиска при каждом обращении к свойству (прямая линковка)?


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

ИМХО, в списках параметров запятые не убавят читабельности, и не прибавят.



Не знаю, как в Питоне, а в AWL все намного проще:



В данном случае список не "развертывается", потому что развертываться некуда: параметр у функтора только один, он и получит все значения. И если параметр не один, но список переданных значений длиннее списка параметров -- последний получит все "неприсвоенный" хвост списка. Кстати, присваивания происходят так же.



Ну, во первых, как всегда, Output <: (a, b, c) -- это лишь синоним для f_put (Output, a, b, c). Второй синтаксис использовать никто не мешает.
Опять-таки, никто не мешает определить свои функторы, под названием print или echo или как-нибудь еще (а фэны Паскаля или Дельфи захотят, чтобы были write и writeln ;) ) Пожалуйста, пишем следующее:

! print (L) = <: L;

или, скажем:

! write(L) = <: L;
! writeln (L) = <: (L, "\n");

и пользуемся на здоровье...



Функтор f_put и пишет в любой поток, который задается его первым аргументом (Просто, если первый аргумент -- undef, то предполагается стандартный вывод). И понятие "часть языка" в AWL довольно условно (можно сказать даже что стандартная математика или присваивания в AWL -- *не часть языка*: стандартные функторы, и только.)



Кстати, при нормальной раскраске код будет восприниматься намного проще. А написать лексический колоризатор для AWL-кода -- это пара пустяков, намного проще, чем, скажем, для Perl.



Очень просто:



Понятно, что реальное определение X_List длиннее, но суть та же. ;)



Кстати, если вы всерьез хотите этим заняться, я готов прислать все исходники.



Про Obj-C я практически ничего не знаю, так что судить не берусь. В JavaScript -- так точно нельзя.



Именно так и реализовано. Именно поэтому, кстати, обращение к внутренностям класса извне класса должно быть квалифицированным (т.е. должно предваряться Class!!). 



"С внутренним устройством" без исходников точно не разберетесь. ;)

Сужу субьективно конечно, но без запятых на список это не похоже. Особенно когда в списке строки, не разобрать где что.


Кстати, это самая не приятная вещь в языке, постоянно указывать имя класса с методом. Полное ощущение что вызываем просто фукцию с более длинным именем и передаём ей просто структуру. В то время как помним что ООП это в первую очередь связывание данных (состояния) с кодом.

[quote]

Сужу субьективно конечно, но без запятых на список это не похоже. Особенно когда в списке строки, не разобрать где что.[quote]

Отчасти согласен: когда в списке данные разного типа, запись с квадратными скобками действительно может выглядеть не очень. Т.е. лучше этого избегать.



Ну, фактически в C++ (и вроде в Java) все также. Тоже извне класса надо обращаться по квалифицированному имени, например:

MyClass::a + MyClass::b + MyClass::c

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

Зато в AWL есть другое: оператор квалификации применим не  только к отдельным идентификаторам, но и к выражению в целом. Т.е. в выпеприведенном случае можно написать что-то вроде:

MyClass!! (a + b + c)

и этого вполне достаточно. Сложность "квалифицированного" выражения не ограничивается -- это может быть и целый блок, т.е. можно просто написать

MyClass!! { expr1, expr2 ..... exprN }

имея в блоке доступ к компонентам и функторам-методам MyClass без лишней головной боли.

Больше 3000 просмотров темы! Неплохо...

Ну вот, выложил я новую версию AWL: 0.5.4!

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

(В архиве есть и документация.)

Основные отличия от предыдущих:

- поддержка (пока очень экспериментальная) Unicode строк.

- поддержка (еще более экспериментальная) регулярных выражений (patterns).
  (См. в functor_index все функторы с именами типа rx_*)

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


Это сообщение отредактировал(а) regis - 21.6.2007, 10:25

Привет всем!

Уже неделю, как на http://awl-project.narod.ru/ выложена новая (0.5.5) версия языка, и документация. Скоро будет несколько новых примеров, возможно и manual будет обновлен.

Ну, наконец-то вышел журнал "Мир ПК" октябрь'2007.
В нем есть кое-что, имеющее отношение к теме. ;)

(У статьи будет продолжение; выйдет ориентировочно в декабрьском номере.)

Давно не писал в эту тему. ;(

Из новостей:

- сайт http://awl-project.narod.ru обновлен. Новую версию языка (0.5.6) теперь можно скачать.
- она же есть на CD для журнала "Мир ПК", # 12/ 2007, вместе с моей статьей о методах создания оконных приложений на AWL.

Ну и, конечно, всех -- с наступающим! Желаю всего наилучшего в новом году!

Nirvana, идея понятна. ( Похоже, я уже вам отвечал, почтой. )

Вот кстати: в Wiki появилась страничка, посвященная AWL, на немецком:

http://de.wikipedia.org/wiki/AWL_(Programmiersprache)

Big thx to Carlos Franke. Если кто-нибудь читает по немецки, буду рад, если он взглянет на статью
(сам я, увы, в немецком ни бум-бум).