Ну вот, хочу предложить вашему вниманию новый язык программирования -- 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'а...
 

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

Угу, я не говорил что это 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 пока плохо, так что если будут вопросы, не стесняйтесь. Если будут проблемы скачивания с народа --  могу выслать на мэйл.

Зеркало побыстрее народа.ру: http://sardar.vingrad.ru/AWL/awl_and_demos.zip

В демках графика (рисование примитивами, отрисовка шрифтов etc). Красиво смотряться фракталы (Мандельброта и другие), при отрисовке тормозят, загружают на 2ядернике 1 ядро (не многопоточно значит?) на 50% всего. По памяти больше 2Мб не хавает. При ресайзе окошек фрактал Ньютона подвисает, kill спасает ситуацию, в остальных окошка проблем не замечено.

Как и раньше исходников нет, но это не мешает сказать wow! смотря на эту красоту 

Спасибо за отзыв.

Фракталы, действительно, едят довольно много процессора -- все-таки, вычисления требуются довольно объемные. Никакого мультитрединга в рамках AWL пока конечно нет, хотя кто знает -- может, когда-нибудь и будет. Памяти, действительно, и у меня потребляет около 2Mb, что даже как-то много: в конце интерпретатор выводит Memory stat peak = 38770. Наверное, в Win в статистику памяти процессора тоже включаются все задействованные DLL-ки. А вот kill-ом убивать мне не разу не приходилось: иногда программа подвисала даже на минуту, но потом все равно отвисала и продолжала рисовать нормально. Я думаю, что это шалости виндового планировщика -- AWL тут не при чем, ручаюсь.

А насчет исходников: а разве сами AWL-модули не в счет? Сплошные исходники ведь.   

Больше 1100 просмотров! Недурно.   

Вот еще небольшая информация к размышлению: я переписал тот код, который рисует Мандельброта, на Perl (5.8.7, для вывода графики используется Prima TK). Если сравнить скорость работы: Perl, конечно, быстрее -- но всего раза в полтора! По моему, очень неплохо -- если учесть, что AWL пока довольно плохо оптимизирован, и ресурсов "убыстрения" еще много.

Пока это прикидки "на глазок": будут аккуратные данные, обязательно их выложу. Вообще, фракталы хорошо использовать как бенчмарки: скорость видна очень наглядно.

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


Угу, ну дык говорим про исходники не ради галочки то (и в этом случае это вообще документы), а что бы пощупать софтину изнутри. По ману любой может реализовать AWL сам (ни в Европе, ни в России запретить не сможешь  ), так в чём проблема? 


А человеческая (помесь императивной/явно_управляемой с "неявной") многопоточность будет? А то как то двухядерник есть (ноут), а толку мало 

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

Реализовать нормальную многопоточность, повторюсь, идея соблазнительная. Но чтобы это было нормально, нужны средства запуска/останова/установки приоритетов для потоков, нужны средства синхронизации, вроде мониторов и т.п. Мне бы пока с текучкой разобраться. ;)

А вообще, по вопросу о дальнейших планах: кто нибудь знает, реально ли у нас что-нибудь издать как bookware? (Кто не знает, поясню: это когда издается книжка о каком-нибудь софте + сам софт прилагается к ней на диске.) Насколько я знаю, многое на западе распространялась как bookware -- Minix, например, на котором потом был основан Linux. Мне интересно, насколько это реально у нас.

  

Смотря какие ограничения ты внесёшь в свою bookware лицензию. Проще конечно пользовать LGPL или вообще BSD, это позволит тебе писать уникальные проприетарные продукты пользуясь свободными либами (тут свои заморочки). Книгу можно продавать, но так сходу её не каждый купит...  Если действительно есть силы и талант написать что то новое, затем распространить AWL, то конечно книга будет покупаться. Только не просто это книги писать 

Если когда нибудь напишешь SAPI модули для апача, IIS и прочих, т.е. AWL станет вебязыком как PHP, то можно хорошо заработать толкая среду разработки к нему вместе с фреймворком и готовым кодом на все случаи жизни. Плюсы подхода в том, что твой AWL будут расширять другие, помогая тебе его развивать, прям как в PHP. Решение конечно комплексное, деньги ты в первые 2 года будешь только терять.


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

Книга в виде мануала уже есть, надо только дописать отсутствующие разделы. Ну и, конечно, повнятнее растолковать то, что неясно, дать больше примеров, добавить приложения: подробный справочник по функторам, синтаксис и т.п. Мне сейчас интересно другое: какое из наших издательств в принципе взялось бы это издать, хотя бы небольшим тиражом? (Понятно, что издательству значительно проще издать 1001-ю книгу про Javascript, PHP и пр. -- чем публиковать что-нибудь принципиально новое, но связанное с риском.)

Кстати, насчет PHP: я вообще не думал о том, как можно было б использовать AWL на сервере -- пока это на 100% клиентская технология. (Хотя, конечно, одно другому не мешает.)



"Основан" -- понятие с очень нечеткой семантикой.   
Исходной код Линукса, конечно, не содержит что-либо от Миникса и 100%но лицензионно чист. Если же говорить о Миниксе как об источнике идей -- да, он таковым безусловно был, о чем сам Линус в "Just for fun" прямо пишет. Впрочем, согласен, что эта тема здесь -- совершенно не в топик.

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

В новых версиях -- есть (rnd, set_rnd). Через пару дней новую версию выложу.

а, пасибо! :-)

я думаю назрел вопрос о полноценном сайте 

Вопрос уже не назрел, а прям-таки перезрел.   

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

Итак: проекту AWL исполняется год!

Своеобразный юбилей, и как раз к нему есть ряд новостей:

1) Языку удалось привлечь определенное внимание компьютерной прессы.
Украинский ж-л "Мой компьютер", № 47 (426) -- см. http://mycomputer.ua/issuetoc/

2) Понемногу открывается официальный сайт: http://awl-project.narod.ru
Там уже есть ссылки на большую часть ресурсов, в т.ч. примеры и документацию.

3) Наконец, там же вы найдете новый AWL интерпретатор, версию 0.5.0
(считаю язык готовым примерно наполовину, исходя из этого и присвоил номер версии).
Основные отличия:

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

Скоро будет обновлена техническая документация, в т.ч. списки функторов и синтаксис.

Комментарии, как всегда, приветствуются.


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

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


regis,  были обращения после статьи? :-)

Были, конечно. Посещаемость сайта возросла очень здорово.

(Кстати, ссылка, которая сверху, похоже устарела: на http://mycomputer.ua/issuetoc/ уже оглавление следующего номера лежит. А 47-й, наверное, теперь где-нибудь в архиве?)

через пару недель статью выложат на сайте. и на главной странице МК ссылка будет.

А как же "Alternative Web Language"??

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

Мне вообще новые языки интересны чисто с практической точки зрения, по этому я смотрю на них прежде всего в таких разрезах:

1) На что нацелен язык, т.е. в какой области применения позиционируется
2) Синтаксис языка, т.е. желательна его понятность, простота и синтаксическая чистота (особенно если это язык общего назначения) - это прямым образом отобразится на его распространенности, поскольку "встречают по одежке".
3) Чем он отличается от нынесуществующих, и какова в нем изюминка, чем он лучше их и соответственно какой смысл выбрать именно его, а не что нибуть-другое, ведь очевидно, что выбирать новую еще не окрепшую технологию - это всегда большой риск.

Можно ли прокомментировать по этим пунктам?

Это сообщение отредактировал(а) cherep - 1.12.2006, 17:13

Именно так. Просто, пока я прикидываю перспективы AWL как исключительно клиентской Web-технологии (если так понятнее – как альтернативу JavaScript/Flash/SVG/XHTML, а не ASP/PHP/SSI и т.д.). Конечно, если бы еще AWL имелся на сервере, причем серверные компоненты гладко и без швов интегрировались с клиентскими – это было б просто замечательно. Но пока я об этом даже не думаю: т.к. прежде, чем всерьез планировать это, надо иметь более четкое представление о собственной функциональности AWL клиента.



Во-первых, на самом деле синтаксис не такой уж страшный ;) Впрочем, если есть конкретные идеи, что можно улучшить – предлагайте, я слушаю.
Во-вторых, что более важно, синтаксис очень вариантный. В AWL действительно уйма операций -- но практически все допускают функциональную запись как альтернативу "операторной" (семантически, никакой разницы нет). Т.е. не нравятся условные операции в виде a ? b : c -- пишите if (a, b, c); не нравятся циклы в виде a ?? b -- пишите while (a, b) или даже while (a) :: b ну и так далее.
(В опубликованных примерах, действительно, в основном используется «операторный» синтаксис, т.к. он мне нравится своей компактностью. Но я свои вкусы никому не навязываю.)



Спасибо.

Во-первых, как Alternative Web Language (клиентскую web-технологию). В принципе, в AWL реализуемо будет все то, для чего сейчас используются HTML/CSS (форматирование гипертекста, стилевая разметка и т.п.), Javascript (интерактивные компоненты и взаимодействие с пользователем) и ActionScript/SVG (векторная графика и анимация). Скоро будет на сайте небольшой проект того, как это могло бы выглядеть в реальной жизни.

Во-вторых, просто в качестве вполне самостоятельного переносимого скрипт языка.

В-третьих, возможно, как встраиваемый скрипт-язык для больших систем (наподобие Lua).



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



Сравнивать со всеми существующими языками будет очень долго. ;)
Для примера, можно взять Perl, Python и Ruby. (Сразу скажу, что из этой тройки я хорошо знаком только с Perl, насчет остальных языков могу и ошибаться.)

Синтаксис: если вам не нравится AWL, то что вы скажете о Perl ;) ?
Нет, про сам язык ничего плохого сказать не могу, но все-таки синтаксис… Особенно явные анахронизмы, оставшиеся от юниксовских оболочек и AWK: переменные с сигилами, barewords, интерполяция в строках, замечательные имена системных переменных типа $% или $:. (Многое из Perl-синтаксиса унаследовано в Ruby, что последний не красит.)
Вот в Python синтаксис проще и логичней – но то, что слишком большую роль в нем играют отступы и концы строк, мне кажется изрядным недостатком.

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

В отличие от AWL, Perl вообще неспособен работать интерактивно (Python может, насчет Ruby не знаю).

Далее, в AWL последовательно реализован «принцип эквивалентности кода и данных». Могу ошибаться, но, по-моему, ни в одном из рассматриваемых выше языков этого нет. Соответственно, невозможны напрямую такие вещи, как «ленивое» присваивание или передача параметров.

Реализация ООП в Perl и Python мне кажется не слишком удачной. Особенно в Perl, где объекты, фактически, являются просто хэшами, которым придан «объектный» вид. Вот в Ruby с ООП хорошо (даже слишком: «чисто объектный» подход, где все функции является методами, мне не нравится).

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

Реализация ассоциативных массивов в AWL существенно лучше, чем в Perl, т.к. допускает произвольный тип ключей.

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

Собственно, пока все. Если есть еще вопросы -- задавайте.


Это сообщение отредактировал(а) regis - 4.12.2006, 11:49

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

В Python-е numarray:

и Numpy:


Все за счет расширяемости языка. Расширяемость бы и AWL очень пригодилась -- не мешает об этом все-таки подумать.


как и в Питоне -- dict.


Для питона, опять же, монстрообразность проявляется только при сборке в Windows независимого от интерпретатора и библиотек приложения. Для *nix библиотеки родные. Плюс такого подхода -- кроссплатформенность.

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



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



В Питоне есть, я знаю.



Говоря о монстрообразности, я имел в виду не собственно размер исполняемого файла: понятно, что при использовании внешних библиотек он будет намного меньше -- но сам-то код из них никуда не денется. Так что, ни память, ни процессорные ресурсы не уменьшатся от того, что библиотеки разделяемые.

Добавлено @ 13:33 
Кстати, раз уж мы говорим о графических возможностях...

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

Первый (Java + AWT, JavaScript и Web): использовать "родные" для оконной среды элементы управления.

Второй (Java+Swing, Perl + Prima, TCL + Tk): реализовывать самому, вручную рисовать и обрабатывать события клавиатуры и мыши.

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

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



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

На сайте есть серьезные обновления.

- Выложена новая версия мануала в HTML/PDF. Наконец-то более-менее внятно документированы классы, объекты, виртуальные функции (эти главы еще будут дорабатываться).

- И еще один новый документ -- AWL-graphics.html -- более-менее внятно описывает то, как в среде AWL работает графика. Это особенно советую почитать. Как мне кажется, графической системы, построенной на подобной идеологии, ни в одном из распространенных языков нет. (Даже странно -- преимущества, на мой взгляд, вполне очевидны...)

Ну вот пока и все. Лично мне кажется, что за прошедший год удалось кое-чего реального добиться. ;) Надеюсь, что в следующем удастся добиться намного больше!

С наступающим всех!

Кстати, на сайте, наконец-то, выложена моя многострадальная статья "Ошибка тысячелетия". Те, кто ее не читал в свое время, теперь имеют возможность прочесть.

Сегодня выложил новую версию интерпретатора (0.5.1)!

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

И в разделе "Примеры" на сайте (http://awl-project.narod.ru/awl-examp.htm) тоже имеется кое-что новенькое...


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

Есть идея добавить материал про AWL, в англоязычную/русскоязычную Wikipedia. Кто-нибудь здесь имеет опыт активной работы над Википедией?

Жми http://ru.wikipedia.org/wiki/AWL , там жми "Создать новую страницу", пиши. Вёрстка элементарна, , всё что между == == это заголовок (количество = определяют уровень), блок текста отделённый пробелами (indent) это код. Там же ссылка на песочницу, где можно опробовать вёрстку. Пусть по началу не красиво, как только появиться, найдётся куча народу что поправят (я поправлю).

Спасибо! Но кое-что я уже сотворил самостоятельно:

http://en.wikipedia.org/wiki/AWL_programming_language

Не судите строго -- это пока только first attempt. На следующей неделе планирую добавить еще раздел-другой, прежде всего про графику и верстку документов.
Комментарии, идеи и исправления моего English (который, боюсь, far from perfect) приветствуются...

Новая версия AWL -- 0.5.3.

Самое существенное, что в ней реализовано: базисные средства работы с метадокументами, реализующими форматирование и вывод текста.
Несколько примеров того, как это работает, я тоже выложил; см. в самом конце http://awl-project.narod.ru/awl_examp_RU.htm



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

Немного не точно. С типами есть два свойства:

• динамичные (duck typing) и статичные
• строгая и не строгая типизация

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

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


Такая запись просто угнетает. Здесь же не конкатенация, а собирается список, который затем пугающего вида "<:" печатается в консоль? ИМХО как то это не эффективно со списком выглядит. Лучше сделать явный оператор конкатенации строк (уже не помню был такой у тебя или нет...), отличный от арифметического сложения.

Вижу активное использование рекурсии, но на сколько эффективно выполнены вызовы? Заменяет ли компиллер простые вызовы inline вставками кода? tail-recursion оптимизации? Иначе будет тормозить...


Что имелось в виду? То что свойство при каждом обращении ищется вновь и вновь в run-time'е? Так это просто (если объект хештаблицей реализовать,  большинство скриптовых движков такие) и не эффективно по сравнению высчитыванием смещения на момент трансляции.

Чего я ещё не вижу это хорошего синтаксиса, уж больно он страшен в нынешнем виде. Также хочется быть кратким, следовательно должно быть много syntatic sugar. К примеру (язык от балды):


В две строчки зачитали файл и просчитали хеши для каждого блока, затем отправили серверу на поиск совпадений. Если отбросить API, то видим очень выразительную [for in] конструкцию. Вот что то подобное хотелось бы в AWL.