Статья:
Ela. Разработка интерпретируемого языка программирования на .NET Framework

Автор(ы): Воронков Василий Владимирович
Дата: 23.12.2010
Описание проекта, посвященного разработке языка программирования Ela.

Авторы:
Воронков Василий Владимирович

Аннотация:
Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.

Здравствуйте, Воронков Василий Владимирович.

Статья (впрочем как и сам Ela) очень заинтересовала. Вот только...
Вы несколько "погорячились" с предложенным вариантом развития событий при описании "dangling else".
Рассматриваемый вами код:
if (isAdmin())
if (isAdvancedMode())
openAdvancedAdminConsole();
else
openAdminConsole();

на самом деле выполняется так:

if (isAdmin())
{
if (isAdvancedMode())
{ openAdvancedAdminConsole(); }
else
{ openAdminConsole(); }
}

а не так, как Вы написали в статье.

Это справедливо для C#, C++, C и ещё ряда языков.
Есть такое общепринятое правило (закреплённое стандартами C/C++/C#), что "else" относится к ближайшему "if".
Из легкодоступных источников можно проверить здесь http://en.wikipedia.org/wiki/Dangling_else.
А ещё проще написать программу и посмотреть как она выполняется.
Очень надеюсь, что допущенная ошибка обусловлена только лишь спешкой написания статьи, а не чем-то другим.

С уважением,
Дмитрий.

Здравствуйте.
Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования? И еще, планируется ли в будущем переход на регистровую ВМ.
P.S. Если говорю глупости — не судите строго знаний в этой области у меня еще пока нет, так, знаю несколько терминов и общих принципов понаслышке, только собираюсь пробовать. Ela — очень интересный для меня материал для изучения.

Было бы неплохо перевести на английский статью. Я выложил ссылку на сайт проекта в Hacker News. И первый же коммент:

Where's the documentation? Wiki's empty and the "Docs" directory in the source repository contains only "OperatorPrecedence.txt". So where can I find more about:
1. distinguishing features of Ela (i.e. "why Ela?")
2. programming in Ela
3. standard library
4. interpreter API

Здравствуйте, __lambda__, Вы писали:

___>Было бы неплохо перевести на английский статью. Я выложил ссылку на сайт проекта в Hacker News. И первый же коммент:
___>

___>Where's the documentation? Wiki's empty and the "Docs" directory in the source repository contains only "OperatorPrecedence.txt". So where can I find more about:
___>1. distinguishing features of Ela (i.e. "why Ela?")
___>2. programming in Ela
___>3. standard library
___>4. interpreter API

Будет. Коммит я только вчера сделал. А с 3-им пока туго.

Здравствуйте, Аноним, Вы писали:

Да, вы абсолютно правы. Собственно, и "закрепленность" этого правило связано с тем, что так просто работает парсер — он будет "клеить" else к ближайшей продукции "if". Странно, что редактор этого не заметил

Здравствуйте, Shizuka-kun, Вы писали:

SK>Здравствуйте.
SK>Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования?

Размер стековых типов так или иначе надо было ограничить. В противном случае, учитывая динамическую типизацию, стек нельзя было бы рассчитать в компайл-тайм, а это чревато. Да и декодирование данных со стека стало бы слишком дорогим. В общем бенефитов от того, что, скажем, операции над Int64 совершаются на стеке, практически не осталось бы.
А благодаря фиксации размера стековых типов до четырех байт, там получает довольно простая как бы in-place структура для описания любого значения. В ней содержится int + указатель. Она не слишком велика, и нет серьезной стагнации производительности из-за ее копирований на стеке (если заменить int на long, то разница в производительности будет весьма заметна). И практически нет никакого декодирования.

Кстати, разница в Int32 и в Int64 арифметике, конечно, заметная, но не космос.

SK>И еще, планируется ли в будущем переход на регистровую ВМ.

Вряд ли. Это надо все переписывать Саму ВМ, естественно, и, главное, компилятор. Компилятор в MSIL будет сделать проще Причем переписывать надо, а какие будут бенефиты сказать сложно. Например, текущая версия работает раза в полтара быстрее, чем та, которая описывается в статье за счет весьма локальных архитектурных улучшений и оптимизаций. Не факт, что регистровая ВМ даст такой же выигрыш. И кстати если стековая ВМ позволяет мне легко и просто пользоваться сборкой мусора "из коробки", то с регистровой такой трюк не прокатит. Кто мусор-то из регистров будет чистить? Разумное решение здесь — огранизовывать свой хип и хранить в регистрах только хэндлы. А это кардинально усложняет все, в том числе и интероп с дотнетным кодом.
Наконец тот же CLR, JVM — это все стековые машины. И имея стековую машину тоже проще будет их поддержать в перспективе, сделав просто транслятор из своего байт-кода.

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

SK>P.S. Если говорю глупости — не судите строго знаний в этой области у меня еще пока нет, так, знаю несколько терминов и общих принципов понаслышке, только собираюсь пробовать. Ela — очень интересный для меня материал для изучения.

Да я тоже в общем диссертацию на эту тему не защищал

Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.

Здравствуйте, __lambda__, Вы писали:

___>Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.

Кто вам не дает? Лопату в руки и...

Здравствуйте, __lambda__, Вы писали:

___>Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.

Вроде как есть MonoDroid

Здравствуйте, Воронков Василий Владимирович, Вы писали:

ВВВ>Статья:
ВВВ>Ela. Разработка интерпретируемого языка программирования на .NET Framework

Автор(ы): Воронков Василий Владимирович
Дата: 23.12.2010
Описание проекта, посвященного разработке языка программирования Ela.

ВВВ>Авторы:
ВВВ> Воронков Василий Владимирович
ВВВ>Аннотация:
ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.

Кое-какая документация по последней версии языка на англ.:

http://code.google.com/p/elalang/wiki/ElaOverview1
http://code.google.com/p/elalang/wiki/GettingStarted

ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.

Мега труд. Респект!
В статье было бы здорово где то иметь (желательно в начале) в кратце сравнительный анализ языка с уже существующими функциональными.
Что бы быстро представить себе о чём идёт реч

Здравствуйте, Tom, Вы писали:

Tom>Мега труд. Респект!
Tom>В статье было бы здорово где то иметь (желательно в начале) в кратце сравнительный анализ языка с уже существующими функциональными.
Tom>Что бы быстро представить себе о чём идёт реч

Ну идея была рассказать скорее о разработке, чем о самом языке. И так очень здоровая статья получилась.
По языку кое-какая информация появилась в вики.

Здравствуйте, Воронков Василий Владимирович, Вы писали:

ВВВ> Многие программисты на VB.NET знают такую интересную опцию как Option Strict, отключение которой позволяет избавить нас от утомительного труда описывать объявление для каждой используемой переменной.

Эта опция Option Explicit называется, а Option Strict включает статическую типизацию (точнее, отключает динамический поиск методов, или как там dynamic lookup называется).

А так статья хорошая, да и язык ничего.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Кое-какая документация по последней версии языка на англ.:

ВВ>http://code.google.com/p/elalang/wiki/GettingStarted

Первая строка не компилится
Вместо

var l = new ElaIncrementalLinker(CompilerOptions.Default, new LinkerOptions());

нужно

var l = new ElaIncrementalLinker(new LinkerOptions(), CompilerOptions.Default);

Еще ниже вместо
pi.PropertyName
нужно
pi.Name

В общем попробуй скомпилировать примеры перед выкладыванием

Здравствуйте, Воронков Василий Владимирович, Вы писали:

ВВВ>Статья:
ВВВ>Ela. Разработка интерпретируемого языка программирования на .NET Framework

Автор(ы): Воронков Василий Владимирович
Дата: 23.12.2010
Описание проекта, посвященного разработке языка программирования Ela.

ВВВ>Авторы:
ВВВ> Воронков Василий Владимирович

ВВВ>Аннотация:
ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.

Есть три вопроса по Ela
1. Можно ли обращаться к .Net классам напрямую или только через наследников Ela.Linking.ForeignModule?
2. Можно ли передавать в скрипты ссылку на внешний объект. Если я использую скриптовый язык в приложении, то хотелось бы его повесить на обработчики событый. Например изменить заголовок формы, нарисовать круг, ... а не использовать его как просто калькулятор.
3. Почему Ela?

Здравствуйте, alvas, Вы писали:

A>Есть три вопроса по Ela
A>1. Можно ли обращаться к .Net классам напрямую или только через наследников Ela.Linking.ForeignModule?

Из коробки такой возможности нет. Но ее можно добавить, не меняя сам язык. Например, вы можете написать своего наследника от ElaObject, который будет выступать в качестве враппера для дотнетных классов.

A>2. Можно ли передавать в скрипты ссылку на внешний объект. Если я использую скриптовый язык в приложении, то хотелось бы его повесить на обработчики событый. Например изменить заголовок формы, нарисовать круг, ... а не использовать его как просто калькулятор.

А какая разница — калькулятор или нарисовать круг? И там, и там передаете объект. Объект в качестве параметра можно передать любой — целое число, массив, собственный тип — неважно. Функции, написанные, скажем, на C# для Ela "как родные" — т.е. в них можно передавать обычные функции Ela, частично применять их и пр. Основная проблема на текущий момент — нет готовых биндингов для .NET наподобие Lua.NET. Так что АПИ придется описывать ручками.

A>3. Почему Ela?

Вот тут затрудняюсь ответить. Ela это вообще имя, женское. Происходит от санскр. इला, ilaa. Значений у этого слова как обычно в санскрите много. Одно из них — речь.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А какая разница — калькулятор или нарисовать круг? И там, и там передаете объект. Объект в качестве параметра можно передать любой — целое число, массив, собственный тип — неважно. Функции, написанные, скажем, на C# для Ela "как родные" — т.е. в них можно передавать обычные функции Ela, частично применять их и пр. Основная проблема на текущий момент — нет готовых биндингов для .NET наподобие Lua.NET. Так что АПИ придется описывать ручками.

1. А можно пример как передать из C# "собственный тип" в Ela и изменить пару полей?
2. А его методы вызывать можно?
3. А получить его обратно?

Здравствуйте, alvas, Вы писали:

ВВ>>А какая разница — калькулятор или нарисовать круг? И там, и там передаете объект. Объект в качестве параметра можно передать любой — целое число, массив, собственный тип — неважно. Функции, написанные, скажем, на C# для Ela "как родные" — т.е. в них можно передавать обычные функции Ela, частично применять их и пр. Основная проблема на текущий момент — нет готовых биндингов для .NET наподобие Lua.NET. Так что АПИ придется описывать ручками.
A>1. А можно пример как передать из C# "собственный тип" в Ela и изменить пару полей?

Собственно говоря, у вас есть все те же самые средства для создания своих типов, что и у меня. Никакого волшебства там внутри не происходит, все операции абстрактные. Система типов организована с использованием "типажей", traits. Типажи определяют, какие операции поддерживает ваш объект. Чтобы создать свой собственный тип, нужно при создании указать, какие трейты он поддерживает. Например, возможность обращаться к полям объекта — это трейт GetField. Возможность изменять — SetField.

Посмотрите, как реализован ElaArray. У массива есть встроенные поля, представляющие собой функции для изменения его in-place. Также полезно глянуть на ElaRecord. Он как раз поддерживает GetField|SetField.

A>2. А его методы вызывать можно?

Методов в смысле C# в Ela нет. Есть функции. Функции являются такими же значениями, как, скажем, строки или целые числа. Поле вашего объекта может возвращать в качестве своего значения функцию. Таким образом получается что-то похожее на метод. Посмотрите ElaArray в общем, он именно это и делает.

A>3. А получить его обратно?

Можете явно его передать куда-нибудь, т.е. сделать для Ela что-то вроде хоста. А вообще последнее выражение в программе всегда возвращает значение и его можно получить из интерпретатора. Разницы для Ela нет, что вы там пишите — $x + $y или какую-то более сложную логику. Что ElaInteger, что ваш какой-нибудь пользовательский тип — все это для виртуальной машины без разницы.

Здравствуйте, Воронков Василий, Вы писали:

A>>1. А можно пример как передать из C# "собственный тип" в Ela и изменить пару полей?

ВВ>Собственно говоря, у вас есть все те же самые средства для создания своих типов, что и у меня. Никакого волшебства там внутри не происходит, все операции абстрактные. Система типов организована с использованием "типажей", traits. Типажи определяют, какие операции поддерживает ваш объект. Чтобы создать свой собственный тип, нужно при создании указать, какие трейты он поддерживает. Например, возможность обращаться к полям объекта — это трейт GetField. Возможность изменять — SetField.

ВВ>Посмотрите, как реализован ElaArray. У массива есть встроенные поля, представляющие собой функции для изменения его in-place. Также полезно глянуть на ElaRecord. Он как раз поддерживает GetField|SetField.

Спасибо за информацию, но я просил код примера.

P.S.