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

ВВВ>>Итак, было уже немало сказано о преимуществах динамически-типизированных языков
D>Что то я так и не понял в чем преимущество? Есть вывод типов, есть структурные типы, зачем нужна динамика?

Здесь все просто.

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

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Главное преимущество динамики — тип известен в ран-тайме. Соответственно, можно писать код, в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны.
Можно пример когда такое нужно? Чем этот тип в рантайме будет отличатся от какого нибудь славоря?

Здравствуйте, 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

Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет.

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

ВВ>Здравствуйте, 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

Здравствуйте, 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

В динамике? Ни в чем. В статике такое работать не будет.

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

ВВ>Здравствуйте, 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

ВВ>В динамике? Ни в чем. В статике такое работать не будет.
Что тут не будет работь? Есть метод, у которого есть тип.

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

ВВ>>>>Причем тут словарь?
D>>>Это я про class Foo { int Bar } -> {"Bar", 0}
ВВ>>И что с этим классом не так?
D>С ним все хорошо, в динамике его можно заменить словарем.

Ну и что?
Он и в статике заменяется словарем под названием "таблица диспетчеризации". А в Хаскелле — словари под видом "тайп классов".
В чем проблема со словарями? Любой класс можно прекрасно считать словарем.

ВВ>>Речь о функции printf. Причем тут String.Format?
D>А при чем здесь F#? Можете просто объяснить что вы хотите сказать?

Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#.

ВВ>>>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет.
D>>>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров,
ВВ>>А я думаю, что это хорошая идея. Частный случай зависимого типа.
D>Да, только без статики предется постоянно анализировать тело метода что бы понять что он возвращает.

Анализирует — статика. Динамика ничего не анализирует. Она уже и так все знает.

ВВ>>В динамике? Ни в чем. В статике такое работать не будет.
D>Что тут не будет работь? Есть метод, у которого есть тип.

Типа нет. Вы пишете ерунду. Любая система типов консервативна. С ее точки зрения — функция foo не типизируется. Тип не может быть "или string, или int".

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

ВВ>Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#.
Тоесть, printf это пример на тему "в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны", хотя на сколько я понял printf как раз позволяет проверять коректность параметров при компиляции. По проще примеров нет?

ВВ>>>>>Функция типизируется в зависимости от значения переданного в нее параметра. Никаких "словарей" нет.
D>>>>Во первых, не думаю что это хорошая идея когда тип функции зависит от параметров,
ВВ>>>А я думаю, что это хорошая идея. Частный случай зависимого типа.
D>>Да, только без статики предется постоянно анализировать тело метода что бы понять что он возвращает.

ВВ>Анализирует — статика. Динамика ничего не анализирует. Она уже и так все знает.

Я говорю о програмисте, которому придется такой код поддерживать.

ВВ>Тип не может быть "или string, или int".
Алгебраические типы в шоке.

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

D>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ты просил пример, я привел. Теперь изволь этот пример посмотреть — функция printf в F#.
D>Тоесть, printf это пример на тему "в котором типы действительно вычисляются только в рантайме и в компайл-тайм неизвестны", хотя на сколько я понял printf как раз позволяет проверять коректность параметров при компиляции. По проще примеров нет?

Это простой пример. printf типизируется по своему параметру. Поэтому в F# формат должен быть известен в компайл-тайме. Динамика позволяет делать то же самое с форматом, который в компайл-тайме неизвестен.

ВВ>>Тип не может быть "или string, или int".
D>Алгебраические типы в шоке.

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

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


ВВ>Даже не знаю, что вам сказать. Попробуйте:
ВВ>а) действительно разобраться в том, что такое "алгебраический тип" и почему приведенный вами код никакого к ним отношения не имеет.
ВВ>б) почитать о том, что такое система типов и почему приведенный вами код является классическим (см. того же Пирса) примером кода, который не пропустит любая система типов.

Да, ладно, в чем проблема. В .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>?

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

РД>Да, ладно, в чем проблема. В .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

Скомпилируем или ошибку дадим?

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

ВВ>Здравствуйте, Рысцов Денис, Вы писали:

РД>>Да, ладно, в чем проблема. В .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, тогда скомпилируется, иначе ошибка.

Здравствуйте, 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?

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

ВВ>Здравствуйте, 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?
Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?

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

D>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?

Динамика появилась в четвертом дот-нете, например

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

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

D>>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите. Надеюсь вы все таки осознали что динамика не нужна?

A>Динамика появилась в четвертом дот-нете, например

И что вы теперь с помощью нее можете делать такого чего не могли раньше используя рефлекшен?
Имхо, замена словарей на сахар bar["Foo"] -> bar.Foo

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

ВВ>>Ну и чему же равно произведение foo 1 * foo 0?
D>Все записит от задачи, но вообще это вам понадобилось сделать тип функции зависящие он параментра, вот и скажите.

С чего бы? Вы мне обещали привести статически типизируемую функцию, тип которой зависит от *значений* параметров. Так что дерзайте.

D>Надеюсь вы все таки осознали что динамика не нужна?

Троллингом идите заниматься в другое место. Я в таком ключе вести беседу не намерен.

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


ВВ> Вы мне обещали привести статически типизируемую функцию, тип которой зависит от *значений* параметров. Так что дерзайте.
let foo x = if x == 0 then "bar" else 2 end;
foo :: int -> string | int

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

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

Читаю раздел "Парсер и AST".

Скажите почему из вашего построенного AST или даже вместо
него, просто не набрать дерево выражений using CodeDom?

Здравствуйте, 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 для ускорения компиляции.

А по поводу трансляции в КодеДом — а зачем, собственно?