Аннотация:
Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.
Re: Ela. Разработка интерпретируемого языка программирования
От:
Аноним
Дата:
24.12.10 07:00
Оценка:
Здравствуйте, Воронков Василий Владимирович.
Статья (впрочем как и сам 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.
А ещё проще написать программу и посмотреть как она выполняется.
Очень надеюсь, что допущенная ошибка обусловлена только лишь спешкой написания статьи, а не чем-то другим.
С уважением,
Дмитрий.
Re: Ela. Разработка интерпретируемого языка программирования
Здравствуйте.
Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования? И еще, планируется ли в будущем переход на регистровую ВМ.
P.S. Если говорю глупости — не судите строго знаний в этой области у меня еще пока нет, так, знаю несколько терминов и общих принципов понаслышке, только собираюсь пробовать. Ela — очень интересный для меня материал для изучения.
Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see.
Re: 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
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, __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-им пока туго.
Re[2]: Ela. Разработка интерпретируемого языка программирова
Да, вы абсолютно правы. Собственно, и "закрепленность" этого правило связано с тем, что так просто работает парсер — он будет "клеить" else к ближайшей продукции "if". Странно, что редактор этого не заметил
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Shizuka-kun, Вы писали:
SK>Здравствуйте. SK>Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования?
Размер стековых типов так или иначе надо было ограничить. В противном случае, учитывая динамическую типизацию, стек нельзя было бы рассчитать в компайл-тайм, а это чревато. Да и декодирование данных со стека стало бы слишком дорогим. В общем бенефитов от того, что, скажем, операции над Int64 совершаются на стеке, практически не осталось бы.
А благодаря фиксации размера стековых типов до четырех байт, там получает довольно простая как бы in-place структура для описания любого значения. В ней содержится int + указатель. Она не слишком велика, и нет серьезной стагнации производительности из-за ее копирований на стеке (если заменить int на long, то разница в производительности будет весьма заметна). И практически нет никакого декодирования.
Кстати, разница в Int32 и в Int64 арифметике, конечно, заметная, но не космос.
SK>И еще, планируется ли в будущем переход на регистровую ВМ.
Вряд ли. Это надо все переписывать Саму ВМ, естественно, и, главное, компилятор. Компилятор в MSIL будет сделать проще Причем переписывать надо, а какие будут бенефиты сказать сложно. Например, текущая версия работает раза в полтара быстрее, чем та, которая описывается в статье за счет весьма локальных архитектурных улучшений и оптимизаций. Не факт, что регистровая ВМ даст такой же выигрыш. И кстати если стековая ВМ позволяет мне легко и просто пользоваться сборкой мусора "из коробки", то с регистровой такой трюк не прокатит. Кто мусор-то из регистров будет чистить? Разумное решение здесь — огранизовывать свой хип и хранить в регистрах только хэндлы. А это кардинально усложняет все, в том числе и интероп с дотнетным кодом.
Наконец тот же CLR, JVM — это все стековые машины. И имея стековую машину тоже проще будет их поддержать в перспективе, сделав просто транслятор из своего байт-кода.
Да и мне кажется смысла нет гнаться за скоростью кода. Интерпретатор есть интерпретатор, работает с нормальной для интерпретатора скоростью, до нативного кода ему, понятно, как до луны, и регистровая машина тут ничего не изменит.
SK>P.S. Если говорю глупости — не судите строго знаний в этой области у меня еще пока нет, так, знаю несколько терминов и общих принципов понаслышке, только собираюсь пробовать. Ela — очень интересный для меня материал для изучения.
Да я тоже в общем диссертацию на эту тему не защищал
Re: Ela. Разработка интерпретируемого языка программирования
Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, __lambda__, Вы писали:
___>Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.
Кто вам не дает? Лопату в руки и...
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, __lambda__, Вы писали:
___>Сейчас меня запинают за такие слова в форуме по .NET Но было бы круто иметь Ela под Java. Какие плюсы: Ela можно использовать на Android девайсах, а также в Google App Engine.
Вроде как есть MonoDroid
Re: Ela. Разработка интерпретируемого языка программирования
ВВВ>Авторы: ВВВ> Воронков Василий Владимирович ВВВ>Аннотация: ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.
Кое-какая документация по последней версии языка на англ.:
ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.
Мега труд. Респект!
В статье было бы здорово где то иметь (желательно в начале) в кратце сравнительный анализ языка с уже существующими функциональными.
Что бы быстро представить себе о чём идёт реч
Народная мудрось
всем все никому ничего(с).
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Tom, Вы писали:
Tom>Мега труд. Респект! Tom>В статье было бы здорово где то иметь (желательно в начале) в кратце сравнительный анализ языка с уже существующими функциональными. Tom>Что бы быстро представить себе о чём идёт реч
Ну идея была рассказать скорее о разработке, чем о самом языке. И так очень здоровая статья получилась.
По языку кое-какая информация появилась в вики.
Re: Ela. Разработка интерпретируемого языка программирования
Здравствуйте, Воронков Василий Владимирович, Вы писали:
ВВВ> Многие программисты на VB.NET знают такую интересную опцию как Option Strict, отключение которой позволяет избавить нас от утомительного труда описывать объявление для каждой используемой переменной.
Эта опция Option Explicit называется, а Option Strict включает статическую типизацию (точнее, отключает динамический поиск методов, или как там dynamic lookup называется).
А так статья хорошая, да и язык ничего.
Re[2]: 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. Значений у этого слова как обычно в санскрите много. Одно из них — речь.
Re[3]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А какая разница — калькулятор или нарисовать круг? И там, и там передаете объект. Объект в качестве параметра можно передать любой — целое число, массив, собственный тип — неважно. Функции, написанные, скажем, на 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, что ваш какой-нибудь пользовательский тип — все это для виртуальной машины без разницы.
Re[5]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
A>>1. А можно пример как передать из C# "собственный тип" в Ela и изменить пару полей?
ВВ>Собственно говоря, у вас есть все те же самые средства для создания своих типов, что и у меня. Никакого волшебства там внутри не происходит, все операции абстрактные. Система типов организована с использованием "типажей", traits. Типажи определяют, какие операции поддерживает ваш объект. Чтобы создать свой собственный тип, нужно при создании указать, какие трейты он поддерживает. Например, возможность обращаться к полям объекта — это трейт GetField. Возможность изменять — SetField.
ВВ>Посмотрите, как реализован ElaArray. У массива есть встроенные поля, представляющие собой функции для изменения его in-place. Также полезно глянуть на ElaRecord. Он как раз поддерживает GetField|SetField.
Здравствуйте, alvas, Вы писали:
ВВ>>Посмотрите, как реализован ElaArray. У массива есть встроенные поля, представляющие собой функции для изменения его in-place. Также полезно глянуть на ElaRecord. Он как раз поддерживает GetField|SetField.
A>Спасибо за информацию, но я просил код примера.
А чем приведенные мной ссылки не нравятся?
Re[7]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, alvas, Вы писали:
A>Да всем нравится, но глянь как все красиво начиналось. A>Можно "передать любой — целое число, массив, собственный тип — неважно". A>А закончилось ...
Я ведь тебе сказал, что автоматических биндингов нет. Следовательно, нужно писать враппер. Что никак не отменяет вышесказанного.
A>Так можешь выложить пример как изменить заголовок формы или там ее размер передав в Ela?
Пишешь враппер
Как-то так:
public sealed class ElaForm : ElaObject
{
private Form form;
public ElaForm(Form form) : base(ElaTraits.GetField|ElaTraits.SetField)
{
this.form = form;
}
protected override ElaValue GetField(string field, ExecutionContext ctx)
{
if (field == "Text")
return new ElaValue(form.Text);
else
{
ctx.UnknownField(field, new ElaValue(this));
return Default();
}
}
protected override void SetField(string field, ElaValue value, ExecutionContext ctx)
{
if (field == "Text")
form.Text = value.AsString(ctx);
else
ctx.UnknownField(field, new ElaValue(this));
}
}
Далее выполняешь код, используя исправленную функцию Eval из доки:
Eval("$obj.Text <- \"New form caption\"", new { obj = new ElaForm(myForm) });
Re[9]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, alvas, Вы писали:
A>Вот это другое дело A>Буду копать
На самом деле имитировать классы для Ela не очень удобно. Лучше все-таки готовить более функциональное АПИ. Его и из языка будет удобнее использовать. Например, альтернативная реализация вышеприведенного, но через модуль будет выглядеть так:
//Универсальный враппер для любого объекта, для Ela - это блек бокс. Работать можно только через ваше АПИ.public sealed class ElaWrapper<T> : ElaObject
{
public T Value { get; private set; }
public ElaForm(T value) : base(ElaTraits.None)
{
Value = value;
}
}
public class FormModule : Ela.Linking.ForeignModule
{
public override void Initialize()
{
base.Add<ElaObject>("create", CreateForm);
base.Add<String,ElaObject,ElaObject>("setCaption", SetCaption);
base.Add<ElaObject,String>("getCaption", GetCaption);
base.Add<Int32,ElaObject,ElaObject>("setWidth", SetWidth);
base.Add<ElaObject,Int32>("getWidth", GetWidth);
base.Add<Int32,ElaObject,ElaObject>("setHeight", SetHeight);
base.Add<ElaObject,Int32>("getHeight", GetHeight);
}
public ElaObject CreateForm()
{
return new ElaWrapper<Form> { Value = new Form { Text = caption } };
}
public ElaObject SetCaption(string caption, ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
obj.Value.Text = caption;
return obj;
}
public string GetCaption(ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
return obj.Value.Text;
}
public ElaObject SetWidth(int width, ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
obj.Value.Width = width;
return obj;
}
public int GetWidth(ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
return obj.Value.Width;
}
public ElaObject SetHeight(int height, ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
obj.Value.Height = height;
return obj;
}
public int GetHeight(ElaObject obj)
{
var frm = (ElaWrapper<Form>)obj;
return obj.Value.Height;
}
}
Использование:
open Form with create, setCaption, setWidth, setHeight
//В конце получаем инициализированную форму
let frm = create () |> setCaption "Form1" |> setWidth 100 |> setHeight 200
Re: Ela. Разработка интерпретируемого языка программирования
Здравствуйте, Воронков Василий Владимирович, Вы писали:
Всетаки для динамических языков нужна псевдотипизация для интеллисенсе прежде всего.
Очень удобно получатьподсказку через точку,сигнатуры методв итд. При этом резко уменьшается число опечаток и набор текста, т.к. писать приходится оочень много.
По поврду наследования тожеспорно, т.к. при наличии иерархии общих полей и методов,общую часть приходится выводить в отдельные модули а при развитом наследовании вызывает путаницу, чего нет при перекрытии предка. Здесь опять же речь идет не о контракте, а о повторном использовании кода, что в реализации не сложно при налчии модулей предка.
и солнце б утром не вставало, когда бы не было меня
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Serginio1, Вы писали:
S>Всетаки для динамических языков нужна псевдотипизация для интеллисенсе прежде всего. S>Очень удобно получатьподсказку через точку,сигнатуры методв итд. При этом резко уменьшается число опечаток и набор текста, т.к. писать приходится оочень много.
Ну это отедльная задача. Делать ограниченный вывод типов можно и для динамического языка. Собственно, так нередко делается. См. тот же pychecker.
S> По поврду наследования тожеспорно, т.к. при наличии иерархии общих полей и методов,общую часть приходится выводить в отдельные модули а при развитом наследовании вызывает путаницу, чего нет при перекрытии предка. Здесь опять же речь идет не о контракте, а о повторном использовании кода, что в реализации не сложно при налчии модулей предка.
Вовсе необязательно. Наследование по сути не более чем ad hoc полиморфизм. Причем далеко не самая удачная его форма. Те же тайп-классы в Хаскеле с этой функцией справляются куда удачнее. Динамическому языку ничего и делать-то особо не нужно, чтобы получить такой полиморфизм. Он там как бы "первоклассный". Чтобы на каком-нибудь ДжаваСкрипте имитировать наследование не нужны даже прототипы — достаточно обычных объеков. Разница по сравнению, скажем, с Питоном в том, что ДжаваСкрипте функция-конструктор объекта будет просто функцией. В питоне — она будет делать вид, что является классом, тогда как на самом деле не более чем функция конструктор.
Здесь важно то, что в динамических языках классов нет. Ибо нет системы типов — в том смысле, в котором этот термин употреблял, скажем, Пирс, — и класс не может выступать в роли "контракта", ибо этот контракт просто некому проверять. Поэтому что бы ты ни делал, все равно будет просто утиная типизация.
Re[3]: Ela. Разработка интерпретируемого языка программирова
ВВ>Здесь важно то, что в динамических языках классов нет. Ибо нет системы типов — в том смысле, в котором этот термин употреблял, скажем, Пирс, — и класс не может выступать в роли "контракта", ибо этот контракт просто некому проверять. Поэтому что бы ты ни делал, все равно будет просто утиная типизация.
Может я не совсем понял, но объектные функции мало ничем не отличаются от функций расширения. В том же питоне объект указывается явно.
Вот очень неудобно работать со структурами, т.к. они не поддерживают наследование и перекрытие функций. По сути наследование без классов это использование методов структуры принятую за предка. Контракт существует, но на уровне имен и сигнатуры методов.При этом проверка происходит только во время исполнения.
Но и можно в теле метода наследника ссылаеться на метод предка без копирования метода.
А иерархия в моей работе неизбежна, и недостатки наследования для меня очевидны.
и солнце б утром не вставало, когда бы не было меня
Re[4]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Serginio1, Вы писали:
ВВ>>Здесь важно то, что в динамических языках классов нет. Ибо нет системы типов — в том смысле, в котором этот термин употреблял, скажем, Пирс, — и класс не может выступать в роли "контракта", ибо этот контракт просто некому проверять. Поэтому что бы ты ни делал, все равно будет просто утиная типизация. S> Может я не совсем понял, но объектные функции мало ничем не отличаются от функций расширения. В том же питоне объект указывается явно. S> Вот очень неудобно работать со структурами, т.к. они не поддерживают наследование и перекрытие функций. По сути наследование без классов это использование методов структуры принятую за предка. Контракт существует, но на уровне имен и сигнатуры методов.При этом проверка происходит только во время исполнения.
Все, что ты описываешь, решается без наследования. "Структура" на самом деле представляет собой просто хэш-таблицу с функциями. Наследование — копирование хэш-таблицы. Перекрытие — замена отдельных ключей в хэш-таблице. Это, если хочешь, готовая таблица диспетчеризации, которую ты можешь заполнять ручками.
В реальности классы а ля Питон — это не более чем сахар над подобным механизмом. Ну т.е. сахар этот может и уместен и упрощает использование языка, но это совсем не те же самые классы, что в С++, шарпе, Джаве и пр.
Тайп-классы еще лучше. Лучше тем, что это все та же хэш-таблица с функциями — причем именно так все и реализовано в том же Хаскеле. Но хэш-таблица не прибита гвоздями к объекту, а передается отдельно. Т.о. можно передать один и тот же набор методов для разных объектов. Мы просто-напросто перестаем прикидываться классами и выворачиваем механизм с хэш-таблицами явно, и он в результате становится более гибким.
Я лишь хочу сказать, что программировать в ООП-стиле можно практически на любом динамическом языке, для этого не нужно каких-то специальных фич. ООП — это фактически ad hoc полиморфизм через объекты, он присутствует в любой динамике, если там вообще есть возможность создать объект.
Но под class based OOP я все же понимаю вполне конкретную штуку. И эта штука, если посмотреть объективно, нереализуема в динамически-типизированном языке просто потому что она изначально расчитана на статику и требует наличия системы типов.
Re[5]: Ela. Разработка интерпретируемого языка программирова
ВВ>Но под class based OOP я все же понимаю вполне конкретную штуку. И эта штука, если посмотреть объективно, нереализуема в динамически-типизированном языке просто потому что она изначально расчитана на статику и требует наличия системы типов.
Под ООП подразумевается наследование, перекрытие. А как оно будет реализовано никого не волнунет.
Так или иначе присутствуют некая структура (Хэш таблица) с методами, методы внутри могут ссылаться на метод другой структуры являющейся для данной структуры base.
То есть присутсвует поле base.
Решение просто генерить методы которые присутствуют в base если эти методы не перекрыватся, внутри которых вызов методов base.
Это не противоречит и твоим понятиям об ООП. Просто добавить другой вид сахара.
Так и в структурах из-за того что нет наследования присутствует поля структуры являющиеся по сути родителем.
Так или иначе суть иерархи присутсвет во многис случаях, и удобное повторное использование кода c перекрытием всегда будет приветствоваться.
А ООП по сути свой и есть сахар.
и солнце б утром не вставало, когда бы не было меня
Re[6]: Ela. Разработка интерпретируемого языка программирова
Можно даже не имея предварительно информации о типе родителя, пересылать все методы которые не находятся в объекте
пересылать полю являющемся родителем. Это поле может быть единственным, а может и нет (при множественном наследовании).
Сдесь уже от реализации зависит.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Serginio1, Вы писали:
S>Можно даже не имея предварительно информации о типе родителя, пересылать все методы которые не находятся в объекте S>пересылать полю являющемся родителем. Это поле может быть единственным, а может и нет (при множественном наследовании). S>Сдесь уже от реализации зависит.
Ты уже практически изобрел Prototype based OOP через делегацию
Re: Ela. Разработка интерпретируемого языка программирования
ВВВ>Авторы: ВВВ> Воронков Василий Владимирович
ВВВ>Аннотация: ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.
С удовольствием смотрю за развитием Ela.
Хотел спросить. Вы книгу сразу на английском пишете или есть русские черновики?
Если есть — не могли бы вы их выслать или выложить в открытый доступ?
Здравствуйте, alvas, Вы писали:
A>С удовольствием смотрю за развитием Ela. A>Хотел спросить. Вы книгу сразу на английском пишете или есть русские черновики? A>Если есть — не могли бы вы их выслать или выложить в открытый доступ?
Черновиков русских нет. Да вроде мой английский... эээ... достаточно "русский"
А на русском я недавно блог завел: http://blogs.msdn.com/b/__1/
Там скорее в целом об ФП "простым языком", так сказать. Но есть и пересечения с книгой.
Re[3]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Черновиков русских нет. Да вроде мой английский... эээ... достаточно "русский"
Печально. Просто последнюю версию ela скачало 6 человек. Последнюю книгу 15. Я в том числе.
Я это 17% и 7% аудитории соответственно = русскоязычная аудитория. Как минимум. Надеюсь больше
Стоит ли игнорировать эту аудиторию, ориентируясь на абстрактных англоязычных?
P.S. Nemerle потому и ожил, что вокруг него собралось комьюнити. В данном случае русскоговрящее.
Здравствуйте, alvas, Вы писали:
A>Печально. Просто последнюю версию ela скачало 6 человек. Последнюю книгу 15. Я в том числе. A>Я это 17% и 7% аудитории соответственно = русскоязычная аудитория. Как минимум. Надеюсь больше
Честно, не очень понял, что за проценты
A>Стоит ли игнорировать эту аудиторию, ориентируясь на абстрактных англоязычных? A>P.S. Nemerle потому и ожил, что вокруг него собралось комьюнити. В данном случае русскоговрящее.
Мне казалось, английскую смогут читать все, как русскоговорящие, так и англоговорящие. А русскую — только русские.
A>P.P.S. В общем я за русскую версию книги
Из идеологических соображений или на английском действительно тяжело читать?
Re[5]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, alvas, Вы писали:
A>>Печально. Просто последнюю версию ela скачало 6 человек. Последнюю книгу 15. Я в том числе. A>>Я это 17% и 7% аудитории соответственно = русскоязычная аудитория. Как минимум. Надеюсь больше
ВВ>Честно, не очень понял, что за проценты
A>>Стоит ли игнорировать эту аудиторию, ориентируясь на абстрактных англоязычных? A>>P.S. Nemerle потому и ожил, что вокруг него собралось комьюнити. В данном случае русскоговрящее.
ВВ>Мне казалось, английскую смогут читать все, как русскоговорящие, так и англоговорящие. А русскую — только русские.
A>>P.P.S. В общем я за русскую версию книги
ВВ>Из идеологических соображений или на английском действительно тяжело читать?
Тяжело читать потому что не родной.
Как я читаю доку на русском? Распечатываю на принтере и привет диван
Как я читаю доку на английском? Гугл Транслейт и прощай диван
VladD2 пишет статьи на русском, а потом просит перевести ее на английский. Ты же не считаешь его тупым?
Если перевод на русский будешь делать только для меня — естественно шкурка выделки не стоит. Но есть хороший шанс создать комьюнити вокруг Ela на rsdn. Много тебе фидбека от "абстрактных англоговорящих"? Если, да — не парься. Если нет — подумай над моими словами.
P.S. Я ощутил потенциал Ela + твоя скорость обновлений вдохновляют.
Ты понимаешь, я так вопрос не ставил. И действительно не думал, что кто-то будет читать через Гугл Транслейт. С т.з. скорости мне все равно, на каком языке писать — я много лет писал техническую документацию на английском. Если бы на русском я бы смог писать книгу, скажем, в два раза быстрее, то тут вопроса бы не возникло.
Влад, кстати, в первую очередь, так сказать, художественно переводил материалы с nemerle.org, которые уже были доступны на английском. Т.е. фактически знакомтл русское комьюнити с Немерле. Причем первоначальную документацию на английском по Немерле писали тоже не англичане, а поляки.
В общем выбор английского языка мне показался достаточно естественным
Перевести, конечно, можно, но поддерживать версию на двух языках сложновато.
A>Если перевод на русский будешь делать только для меня — естественно шкурка выделки не стоит. Но есть хороший шанс создать комьюнити вокруг Ela на rsdn. Много тебе фидбека от "абстрактных англоговорящих"? Если, да — не парься. Если нет — подумай над моими словами.
Ну а как определить, какое количество людей отпугивает документация на английском?
A>P.S. Я ощутил потенциал Ela + твоя скорость обновлений вдохновляют.
Ну пока можешь блог почитать. Кстати, УРЛ починили: http://blogs.msdn.com/b/vorov/
Половина книги "обще-теоретического" характера туда переедет.
Re[7]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, alvas, Вы писали:
ВВ>Ты понимаешь, я так вопрос не ставил. И действительно не думал, что кто-то будет читать через Гугл Транслейт. С т.з. скорости мне все равно, на каком языке писать — я много лет писал техническую документацию на английском. Если бы на русском я бы смог писать книгу, скажем, в два раза быстрее, то тут вопроса бы не возникло. ВВ>Влад, кстати, в первую очередь, так сказать, художественно переводил материалы с nemerle.org, которые уже были доступны на английском. Т.е. фактически знакомтл русское комьюнити с Немерле. Причем первоначальную документацию на английском по Немерле писали тоже не англичане, а поляки. ВВ>В общем выбор английского языка мне показался достаточно естественным
И не только тебе. И полякам тоже. И кто в конце концов занимается разработкой N? Абстрактные англоговорящие?
ВВ>Перевести, конечно, можно, но поддерживать версию на двух языках сложновато.
Если не сложно сделай первую версию перевода. А там как пойдет.
A>>Если перевод на русский будешь делать только для меня — естественно шкурка выделки не стоит. Но есть хороший шанс создать комьюнити вокруг Ela на rsdn. Много тебе фидбека от "абстрактных англоговорящих"? Если, да — не парься. Если нет — подумай над моими словами.
ВВ>Ну а как определить, какое количество людей отпугивает документация на английском?
A>>P.S. Я ощутил потенциал Ela + твоя скорость обновлений вдохновляют.
ВВ>Ну пока можешь блог почитать. Кстати, УРЛ починили: http://blogs.msdn.com/b/vorov/ ВВ>Половина книги "обще-теоретического" характера туда переедет.
Здравствуйте, Воронков Василий Владимирович, Вы писали:
ВВВ>Итак, было уже немало сказано о преимуществах динамически-типизированных языков
Что то я так и не понял в чем преимущество? Есть вывод типов, есть структурные типы, зачем нужна динамика?
Talk is cheap. Show me the code.
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, dotneter, Вы писали:
ВВВ>>Итак, было уже немало сказано о преимуществах динамически-типизированных языков D>Что то я так и не понял в чем преимущество? Есть вывод типов, есть структурные типы, зачем нужна динамика?
Здесь все просто.
Главный недостаток динамики — тип известен в ран-тайме. Соответственно, невозможно применить ряд оптимизаций и подсказать программисту об ошибках.
Главное преимущество динамики — тип известен в ран-тайме. Соответственно, можно писать код, в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны.
Re[3]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали: ВВ>Главное преимущество динамики — тип известен в ран-тайме. Соответственно, можно писать код, в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны.
Можно пример когда такое нужно? Чем этот тип в рантайме будет отличатся от какого нибудь славоря?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[4]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Главное преимущество динамики — тип известен в ран-тайме. Соответственно, можно писать код, в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны. D>Можно пример когда такое нужно? Чем этот тип в рантайме будет отличатся от какого нибудь славоря?
Причем тут словарь?
Функцию printf в F# знаешь? В F# она может работать, только если строка формата является константой, ибо на основе нее вычисляется тип функции. В динамике — тип можем вычисляться в рантайме, а следовательно, строка формата также может быть известна только в рантайме.
А можно вообще изобразить что-нибудь такое:
let fun (x::xs) = fun' x xs
where fun' a [] = \y -> y + a
fun' a (x::xs) = \y -> fun' (y + a + x) xs
Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет.
Re[5]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, dotneter, Вы писали:
D>>Здравствуйте, Воронков Василий, Вы писали: ВВ>>>Главное преимущество динамики — тип известен в ран-тайме. Соответственно, можно писать код, в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны. D>>Можно пример когда такое нужно? Чем этот тип в рантайме будет отличатся от какого нибудь славоря?
ВВ>Причем тут словарь?
Это я про class Foo { int Bar } -> {"Bar", 0} ВВ>Функцию printf в F# знаешь? В F# она может работать, только если строка формата является константой, ибо на основе нее вычисляется тип функции. В динамике — тип можем вычисляться в рантайме, а следовательно, строка формата также может быть известна только в рантайме.
Не понятно, да у программы есть рантайм который весь сложно засунуть в стадию компиляции.
string.Format("{0}{1}",1) упадет в рантайме, если избавиться от стоки, можно добится того что бы не падало. О чем речь?
ВВ>А можно вообще изобразить что-нибудь такое:
ВВ>
ВВ>let fun (x::xs) = fun' x xs
ВВ> where fun' a [] = \y -> y + a
ВВ> fun' a (x::xs) = \y -> fun' (y + a + x) xs
ВВ>
ВВ>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет.
Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров, но даже есть и так, nо в чем сложность?
let foo x = if x == 0 then "bar" else 2 end;
foo :: int -> string | int
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[6]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, dotneter, Вы писали:
ВВ>>Причем тут словарь? D>Это я про class Foo { int Bar } -> {"Bar", 0}
И что с этим классом не так?
ВВ>>Функцию printf в F# знаешь? В F# она может работать, только если строка формата является константой, ибо на основе нее вычисляется тип функции. В динамике — тип можем вычисляться в рантайме, а следовательно, строка формата также может быть известна только в рантайме. D>Не понятно, да у программы есть рантайм который весь сложно засунуть в стадию компиляции. D>string.Format("{0}{1}",1) упадет в рантайме, если избавиться от стоки, можно добится того что бы не падало. О чем речь?
Речь о функции printf. Причем тут String.Format?
ВВ>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет. D>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров,
А я думаю, что это хорошая идея. Частный случай зависимого типа.
D>но даже есть и так, nо в чем сложность? D>let foo x = if x == 0 then "bar" else 2 end; D>foo :: int -> string | int
В динамике? Ни в чем. В статике такое работать не будет.
Re[7]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, dotneter, Вы писали:
ВВ>>>Причем тут словарь? D>>Это я про class Foo { int Bar } -> {"Bar", 0}
ВВ>И что с этим классом не так?
С ним все хорошо, в динамике его можно заменить словарем.
ВВ>>>Функцию printf в F# знаешь? В F# она может работать, только если строка формата является константой, ибо на основе нее вычисляется тип функции. В динамике — тип можем вычисляться в рантайме, а следовательно, строка формата также может быть известна только в рантайме. D>>Не понятно, да у программы есть рантайм который весь сложно засунуть в стадию компиляции. D>>string.Format("{0}{1}",1) упадет в рантайме, если избавиться от стоки, можно добится того что бы не падало. О чем речь?
ВВ>Речь о функции printf. Причем тут String.Format?
А при чем здесь F#? Можете просто объяснить что вы хотите сказать?
ВВ>>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет. D>>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров,
ВВ>А я думаю, что это хорошая идея. Частный случай зависимого типа.
Да, только без статики предется постоянно анализировать тело метода что бы понять что он возвращает.
D>>но даже есть и так, nо в чем сложность? D>>let foo x = if x == 0 then "bar" else 2 end; D>>foo :: int -> string | int
ВВ>В динамике? Ни в чем. В статике такое работать не будет.
Что тут не будет работь? Есть метод, у которого есть тип.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[8]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, dotneter, Вы писали:
ВВ>>>>Причем тут словарь? D>>>Это я про class Foo { int Bar } -> {"Bar", 0} ВВ>>И что с этим классом не так? D>С ним все хорошо, в динамике его можно заменить словарем.
Ну и что?
Он и в статике заменяется словарем под названием "таблица диспетчеризации". А в Хаскелле — словари под видом "тайп классов".
В чем проблема со словарями? Любой класс можно прекрасно считать словарем.
ВВ>>Речь о функции printf. Причем тут String.Format? D>А при чем здесь F#? Можете просто объяснить что вы хотите сказать?
Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#.
ВВ>>>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет. D>>>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров, ВВ>>А я думаю, что это хорошая идея. Частный случай зависимого типа. D>Да, только без статики предется постоянно анализировать тело метода что бы понять что он возвращает.
Анализирует — статика. Динамика ничего не анализирует. Она уже и так все знает.
ВВ>>В динамике? Ни в чем. В статике такое работать не будет. D>Что тут не будет работь? Есть метод, у которого есть тип.
Типа нет. Вы пишете ерунду. Любая система типов консервативна. С ее точки зрения — функция foo не типизируется. Тип не может быть "или string, или int".
Re[9]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#.
Тоесть, printf это пример на тему "в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны", хотя на сколько я понял printf как раз позволяет проверять коректность параметров при компиляции. По проще примеров нет?
ВВ>>>>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет. D>>>>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров, ВВ>>>А я думаю, что это хорошая идея. Частный случай зависимого типа. D>>Да, только без статики предется постоянно анализировать тело метода что бы понять что он возвращает.
ВВ>Анализирует — статика. Динамика ничего не анализирует. Она уже и так все знает.
Я говорю о програмисте, которому придется такой код поддерживать.
ВВ>Тип не может быть "или string, или int".
Алгебраические типы в шоке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[10]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#. D>Тоесть, printf это пример на тему "в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны", хотя на сколько я понял printf как раз позволяет проверять коректность параметров при компиляции. По проще примеров нет?
Это простой пример. printf типизируется по своему параметру. Поэтому в F# формат должен быть известен в компайл-тайме. Динамика позволяет делать то же самое с форматом, который в компайл-тайме неизвестен.
ВВ>>Тип не может быть "или string, или int". D>Алгебраические типы в шоке.
Даже не знаю, что вам сказать. Попробуйте:
а) действительно разобраться в том, что такое "алгебраический тип" и почему приведенный вами код никакого к ним отношения не имеет.
б) почитать о том, что такое система типов и почему приведенный вами код является классическим (см. того же Пирса) примером кода, который не пропустит любая система типов.
Re[11]: Ela. Разработка интерпретируемого языка программиров
ВВ>Даже не знаю, что вам сказать. Попробуйте: ВВ>а) действительно разобраться в том, что такое "алгебраический тип" и почему приведенный вами код никакого к ним отношения не имеет. ВВ>б) почитать о том, что такое система типов и почему приведенный вами код является классическим (см. того же Пирса) примером кода, который не пропустит любая система типов.
Да, ладно, в чем проблема. В .net переопределены Func<T1>, Func<T1,T2>, Func<T1,T2,T3> ...
Что мешает наплодить таких классов:
class Union<T,U> {
public T X1 { get; set; }
public U X2 { get; set; }
}
А int|string будет алиасом для Union<int,string>?
Re[12]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, Рысцов Денис, Вы писали:
РД>Да, ладно, в чем проблема. В .net переопределены Func<T1>, Func<T1,T2>, Func<T1,T2,T3> ... РД>Что мешает наплодить таких классов:
РД>
РД>class Union<T,U> {
РД> public T X1 { get; set; }
РД> public U X2 { get; set; }
РД>}
РД>
РД>А int|string будет алиасом для Union<int,string>?
Ага, и типом будем именно Union<>, а не что другое. И какой тогда смысл этого к примера, когда речь идет о вычислении типа в рантайме? Никакого.
let foo x = if x == 0 then"bar"else 2
foo 1 * foo 0
Скомпилируем или ошибку дадим?
Re[13]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Рысцов Денис, Вы писали:
РД>>Да, ладно, в чем проблема. В .net переопределены Func<T1>, Func<T1,T2>, Func<T1,T2,T3> ... РД>>Что мешает наплодить таких классов:
РД>>
РД>>class Union<T,U> {
РД>> public T X1 { get; set; }
РД>> public U X2 { get; set; }
РД>>}
РД>>
РД>>А int|string будет алиасом для Union<int,string>?
ВВ>Ага, и типом будем именно Union<>, а не что другое. И какой тогда смысл этого к примера, когда речь идет о вычислении типа в рантайме? Никакого.
ВВ>
ВВ>let foo x = if x == 0 then"bar"else 2
ВВ>foo 1 * foo 0
ВВ>
ВВ>Скомпилируем или ошибку дадим?
Вроде очевидно. Если имеется функция (*) :: int | string -> int | string -> something, тогда скомпилируется, иначе ошибка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[14]: Ela. Разработка интерпретируемого языка программиров
ВВ>>let foo x = if x == 0 then"bar"else 2
ВВ>>foo 1 * foo 0
ВВ>>
ВВ>>Скомпилируем или ошибку дадим? D>Вроде очевидно. Если имеется функция (*) :: int | string -> int | string -> something, тогда скомпилируется, иначе ошибка.
Ну и чему же равно произведение foo 1 * foo 0?
Re[15]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, dotneter, Вы писали:
ВВ>>>
ВВ>>>let foo x = if x == 0 then"bar"else 2
ВВ>>>foo 1 * foo 0
ВВ>>>
ВВ>>>Скомпилируем или ошибку дадим? D>>Вроде очевидно. Если имеется функция (*) :: int | string -> int | string -> something, тогда скомпилируется, иначе ошибка.
ВВ>Ну и чему же равно произведение foo 1 * foo 0?
Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[16]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, dotneter, Вы писали:
D>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, dotneter, Вы писали:
D>>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?
A>Динамика появилась в четвертом дот-нете, например
И что вы теперь с помощью нее можете делать такого чего не могли раньше используя рефлекшен?
Имхо, замена словарей на сахар bar["Foo"] -> bar.Foo
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[16]: Ela. Разработка интерпретируемого языка программиров
Здравствуйте, dotneter, Вы писали:
ВВ>>Ну и чему же равно произведение foo 1 * foo 0? D>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите.
С чего бы? Вы мне обещали привести статически типизируемую функцию, тип которой зависит от *значений* параметров. Так что дерзайте.
D>Надеюсь вы все таки осознали что динамика не нужна?
Троллингом идите заниматься в другое место. Я в таком ключе вести беседу не намерен.
Re[17]: Ela. Разработка интерпретируемого языка программиров
ВВ> Вы мне обещали привести статически типизируемую функцию, тип которой зависит от *значений* параметров. Так что дерзайте.
let foo x = if x == 0 then "bar" else 2 end;
foo :: int -> string | int
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re: Ela. Разработка интерпретируемого языка программирования
Здравствуйте, Воронков Василий Владимирович, Вы писали:
ВВВ>Аннотация: ВВВ>Описание проекта, посвященного разработке языка программирования Ela с использованием C# и .NET Framework.
Читаю раздел "Парсер и AST".
Скажите почему из вашего построенного AST или даже вместо
него, просто не набрать дерево выражений using CodeDom?
Меня постоянно преследуют умные мысли. Но я быстрее.
Re[2]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, sailichev, Вы писали:
S>Читаю раздел "Парсер и AST". S>Скажите почему из вашего построенного AST или даже вместо S>него, просто не набрать дерево выражений using CodeDom?
CodeDom весьма ограничен и не покрывает всех возможностей целевого языка. Собственно, он и для представления дерева C# не подходит так же. Ибо в нем много странных ограничений. Например, нет вообще унарных операторов. В нем есть разделение на Statement и Expression. В Ela — нет. Да и вообще представление операторов в коде-доме для Ela не подходит.
Ну и сам по себе CodeDom не очень удобен в использовании, т.к. универсален. Единственный способ его использования — это расширение CodeDom теми "нодами", которые необходимы для конкретного языка. В случае с Ela это было 50% всего AST.
Но как только вы начинаете его расширять — сразу же теряется все преимущество CodeDom — возможность его трансляции в разные языки, благодаря существованию готовых генераторов. Ну и смысл в нем? Усложнить себе жизнь?
Ну и на уровне AST в Ela есть много маленьких фишек, которые упрощают жизнь компилятору. Например, у каждого элемента AST есть свой тайп-код, представленный в виде энумерации, благодаря которому можно построить эффективный свитч. Используются специальные "хинты" для упрощения анализа — например, хинт Assignable, который позволяет избавиться от нудных проверок на уровне компилятора. Раньше, когда в Ela частичное применение реализовывалось на манер Scala/Nemerle с использованием оператора _, то этот самый оператор так же обрабатывался еще на уровне AST для ускорения компиляции.
А по поводу трансляции в КодеДом — а зачем, собственно?
Re[3]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, Воронков Василий, Вы писали:
ВВ>CodeDom весьма ограничен и не покрывает всех возможностей целевого языка. Собственно, он и для представления дерева C# не подходит так же. Ибо в нем много странных ограничений. Например, нет вообще унарных операторов.
Незнаю на счет "весьма" но для любого ограничения есть workaround. готовый.
ВВ>В нем есть разделение на Statement и Expression. В Ela — нет. Да и вообще представление операторов в коде-доме для Ela не подходит.
Можно не обращать внимание на наличие Statement.
ВВ>Ну и сам по себе CodeDom не очень удобен в использовании, т.к. универсален. Единственный способ его использования — это расширение CodeDom теми "нодами", которые необходимы для конкретного языка. В случае с Ela это было 50% всего AST. ВВ> Но как только вы начинаете его расширять — сразу же теряется все преимущество CodeDom — возможность его трансляции в разные языки, благодаря существованию готовых генераторов. Ну и смысл в нем? Усложнить себе жизнь?
При чем тут трансляция в разные языки. У вас свой язык. Это не нужно.
ВВ>Ну и на уровне AST в Ela есть много маленьких фишек, которые упрощают жизнь компилятору. Например, у каждого элемента AST есть свой тайп-код, представленный в виде энумерации, благодаря которому можно построить эффективный свитч. Используются специальные "хинты" для упрощения анализа — например, хинт Assignable, который позволяет избавиться от нудных проверок на уровне компилятора. Раньше, когда в Ela частичное применение реализовывалось на манер Scala/Nemerle с использованием оператора _, то этот самый оператор так же обрабатывался еще на уровне AST для ускорения компиляции.
ВВ>А по поводу трансляции в КодеДом — а зачем, собственно?
Затем что становится не нужен свой компилятор.
И не нужны маленькие фишки упрощающие ему жизнь. И прочая.
И не нужна виртуальная машина.
Хотя я может цели всей затеи не так понимаю...
А есть спецификация по языку в каком-либо виде?
Меня постоянно преследуют умные мысли. Но я быстрее.
Re[4]: Ela. Разработка интерпретируемого языка программирова
Здравствуйте, sailichev, Вы писали:
ВВ>>CodeDom весьма ограничен и не покрывает всех возможностей целевого языка. Собственно, он и для представления дерева C# не подходит так же. Ибо в нем много странных ограничений. Например, нет вообще унарных операторов. S>Незнаю на счет "весьма" но для любого ограничения есть workaround. готовый.
Какой, интересно? Добавлять собственные узлы?
ВВ>>В нем есть разделение на Statement и Expression. В Ela — нет. Да и вообще представление операторов в коде-доме для Ela не подходит. S>Можно не обращать внимание на наличие Statement.
Нет, нельзя. То, что в Ela является Expression, в CodeDom будет Statement. Соответственно, в голом виде я уже не смогу его использовать в виде выражения. В итоге единственный workaround — заворачивать все Statement в CodeStatementExpression, что уже не добавлят удобства.
S>При чем тут трансляция в разные языки. У вас свой язык. Это не нужно.
Это единственное преимущество CodeDom. Зачем он еще нужен тогда?
ВВ>>А по поводу трансляции в КодеДом — а зачем, собственно? S>Затем что становится не нужен свой компилятор. S>И не нужны маленькие фишки упрощающие ему жизнь. И прочая. S>И не нужна виртуальная машина.
С чего бы это?
Компилятор нужен. Мало того, что CodeDom не покрывает весь язык, так еще и отсутствует однозначная трансляция между, скажем, функциями в C# и функциями в Ela. В итоге вся работа, которую сейчас выполняет компилятор, свалилась бы на парсер. Как бы мы, интересно, паттерн-матчинг представляли? Генерили бы на КодеДоме кучу иф-ов? А каррированные функции как представить? А прозрачную ленивость? Я уж не говорю о том, что даже код вида "x+y" я в C# не могу отранслировать как "x+y", ибо в C# это вполне конкретная операция, а в Ela — абстрактная, так что придется генерить много кода.
В итоге кода получилось бы *больше*, и этот код занимался бы ручным построением CodeDom-а и выглядел бы, соответствующе.
И главное — что бы это дало? Кроме тормознутого компилятора. Итоговая скорость кода отличалась бы незначительно, ценности для эмбединга никакой и пр.
S>Хотя я может цели всей затеи не так понимаю... S>А есть спецификация по языку в каком-либо виде?