Ну вот, хочу предложить вашему вниманию новый язык программирования -- AWL. Работает, как интерпретатор. По своей идеологии он представляет собой нечто среднее между традиционными императивными языками (от BASIC до Java) и списковыми (LISP, Scheme). Собственно, в основе лежат списки, и вся работа ядра языка основана на них.

Завтра/послезавтра выложу в этой теме несколько ссылок для скачивания -- тогда приглашаю всех тестировать и критиковать мое творение. ;)

Интересно. Как человек, досужий до формальных языков и компиляторостроения, жду с нетерпением. (Что мешало сразу выложить? Интерес раззадориваешь? )

Не томи — выкладывай уже!

Не буду вас томить. ;)

ftp://odds_ends.rsl.ru/pub/sergei/Irbis/awl.zip

в архиве есть интерпретатор, описание в PDF, и несколько примеров.

Если будут проблемы со скачиванием (не должно быть) пишите сюда...

А пошто только бинарник?
Исходники давай.

Рассматривать этот мини-калькулятор с точки зрения пользователя не интересно.

Интересно посмотреть на реализацию.

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

Пара вопросов по реализации:
1) Модель интерпретатора: прямая интерпретация текстового представления / интерпретация AST / генерация байткода? (Подозреваю второе).
2) Управление памятью: подсчет ссылок / консервативный или точный сборщик мусора / детерминированное время жизни?
3) Внутреннее представление списков: цена доступа к N-му элементу и конкатенации — O(1) / O(N)?

Ну и наконец, самый главный вопрос: в чем причина создания yet another scripting language и какие планируются дополнения в языке?


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

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

Теперь ответы по реализации:

1) Не знаю, что такое "интерпретация AST", но подозреваю что вы правы. ;)
Внутри программный код представляется так же, как и прочие структуры данных -- т.е. те же списки и термы. Его выполнение -- это, грубо говоря, вызов определенного для терма метода eval. Никакого байт-кода не нужно.

2) Подсчитываются ссылки.

3) Списки на то и списки: доступ к N-му элементу в принципе требует O(N) времени. Конкатенация тоже не быстрая. Поэтому я подумываю о введении массивов наряду со списками (см. далее).

> в чем причина создания yet another scripting language

Намекну, что AWL расшифровывается как Alternative Web Language...

> ....и какие планируются дополнения в языке?

Уйма. Нормально работающие функторы, ООП, намного больше операций над числами, строками и списками, многомерные массивы, хэши, регулярные выражения, полноценный ввод-вывод и т.п.
С другой стороны -- все, что требуется для реализации функций языка как гипермедиа-средства. Как минимум, переносимая оконная графика и виджеты, форматирующие текст.
В общем, идей много.

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

Наконец, насчет исходников. Я в принципе не против, если есть желающие помочь в разработке. А так -- чего на них любоваться? ;)

А есть ли смысл?

Ага, ну примерно так я себе это и представлял.

Просто, к примеру, в Python стандартный тип называется списком, но поощряется его использование в качестве массива, так что вряд ли там доступ к элементу O(N).

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

Кстати, тут возможны два варианта: dynamic scoping vs lexical scoping. И автоматически возникает вопрос о поддержке замыканий. В общем, in any case, исходники стоит опубликовать и держать в актуальном состоянии

Мощно. Нужно упомянуть FFI с Си. Без этого любой скриптовый язык — игрушка. И чем более прозрачным будет FFI, тем лучше.
И все-таки, я не пойму, где killer application для AWL даже с учетом всех этих фич? Чем он будет выгодно отличаться от Python/Ruby/Perl/того же LISP в конце концов?

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

HTML/XML -- примеры чисто декларативных языков. AWL -- декларативно-процедурный. Там, где в HTML используем тэги для разметки текста -- что-нибудь вроде:

<P><font size=3><B>Список клиентов</B> [<I>Март-2006</I>]</P>

в AWL используем функторную запись:

P(Font_size(3, B("Список клиентов"), " [", I ("Март-2006"), "]"));

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

! Article_Header (Author Title Date) = (
Align_Right (Font_size (14, I(Author))),
Align_Center (Font_size (16, B(Title), ' ', Font_size (9, Date)))
);

получим не просто стиль, а готовый генератор для стандартных заголовков статей. Собственно, можно даже добавить в вышеприведенное тело статьи, т.е. целиком "завернуть" ее код в функтор, а header/footer для нее будут генерироваться автоматически.

По идее, вообще практически все стилевые тэги стандартного HTML можно реализовать в виде библиотечных средств. То же относится, например, к нумерованным спискам (<OL> .. </OL>):

! NumList (L) = { i = 0; i ++ < #L ?? (B(i+1, '.'), ' ', L[i], Br) };

Теперь NumList(['C' 'Pascal' 'Java']) будет автоматически генерировать список

1. C
2. Pascal
3. Java

- с номерами выделенными п/ж и пр. Также можно определить словарные списки (<DD>/<DT>) и пр. Думаю, можно (и нужно) определить даже стили для таблиц. Таблица -- это, по сути, набор боксов для вставления в них текста + разделительные линейки для красоты + встроенный менеджер геометрии, управляющий размерами и положением ячеек. По большей части, все это можно создать средствами самого AWL -- при этом программист (дизайнер) будет иметь полный контроль над реализацией этих средств, о чем сегодня и не мечтает.

Это далеко не все, но пока вынужден прерваться...

Хм, из всего выше изложенного ясно, что автор полон энтузиазма,
но стоит на твердых позициях вульгарного материализма при
подходе к предмету.

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

Рекомендую:

1. прогрызть дыру в "Dragon Book";

2. посмотреть по сторонам, понять ситуацию
и прислушаться к тому, что думаю по данному вопросу
люди, не менее талантливые, чем ты сам, например вот эти:
Links Филиппа Вадлера

> Хм, из всего выше изложенного ясно, что автор полон энтузиазма,
> но стоит на твердых позициях вульгарного материализма при
> подходе к предмету.

Насчет "энтузиазма" -- верно, насчет "вульгарного материализма" -- поясните.

> Рекомендую:

> 1. прогрызть дыру в "Dragon Book";

Это вы про Ахо, Сети и Ульмана? Много слышал про эту книгу, но никогда не читал, и не понимаю, зачем надо прогрызать в ней дыру. ;)
Боюсь, что в связи с данной задачей она не особенно актуальна. Там, как я знаю, в основном рассматриваются лексеры, парсеры и оптимизация кода -- для AWL важно другое (по крайней мере, в данный момент).

> 2. посмотреть по сторонам, понять ситуацию
> и прислушаться к тому, что думаю по данному вопросу
> люди, не менее талантливые, чем ты сам, например вот эти:
> Links Филиппа Вадлера

Вы знаете, я всю жизнь смотрю по сторонам и (как мне кажется) неплохо понял ситуацию.
Ссылку я посмотрел, бегло. В детали этого Links я не вникал, но первое что вижу в скриптах -- до боли знакомые HTML-треугольнички. Значит, Yet Another Server Technology -- даже если она *очень* хорошая, все равно ориентирована на работу с HTML-разметкой, тупыми клиентами и протоколами, устаревшими до своего рождения.
Я бы уж скорее обратил внимание на Curl (www.curl.org, кажется). Это по крайней мере перспективнее (хотя тоже не скажу, что я в восторге).

Я обещал еще несколько идей... теперь по поводу организации взаимодействия между клиентом и сервером. Было б идеально, если б протокол работал в рамках собственно модели AWL -- т.е. передавал/получал AWL объекты. Как это будет работать? Примерно так:

request ("awl://myserver.org") => возвращает всю корневую AWL-страницу, размещенную на myserver;

request ("awl://myserver.org", param1, param2, ... paramN) => дополнительно передает ей параметры (напр., для поиска).

Может потребоваться загрузить не документ целиком, а какие-то его подузлы; сервер должен обеспечивать такую функциональность. В идеале вообще клиент должен иметь возможность формировать и передавать код фильтра, выполняемого на сервере, и выбирающего там все то, что нужно.
Протокол должен обеспечивать компактную и максимально эффективную передачу AWL-объектов. Если вместо текстуального представления списков/термов передавать их внутреннее (бинарное), использовать сжатие строк и пр., то можно добиться кое-чего. Может (и наверное должна быть) более сложная модель запросов -- асинхронная... что-нибудь вроде request_async (resource, onload) -- где код onload будет выполняться, когда resource загружен. (Думаю, что здесь closures и прочие функциональные штучки как раз могут пригодиться). Естественно, должно быть кэширование (на локальном компьютере -- локальный кэш-сервер: AWL-браузеров может быть много, желательно, чтобы они совместно использовали кэшированные ресурсы).

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

Новая рабочая версия интерпретатора ждет желающих ее потестировать здесь:

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

Теперь:

- синтаксические ошибки не фатальны;
- рекурсивные функторы работают!
- ряд новых операций/функторов -- см. исходники примеров.


Очень рассчитываю на всех, особенно на Void'а...