Здравствуйте, 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 для ускорения компиляции.
А по поводу трансляции в КодеДом — а зачем, собственно?