Re[2]: Ceylon
От: WolfHound  
Дата: 23.11.11 17:25
Оценка:
Здравствуйте, VladD2, Вы писали:

А>>3. можно делать пересечения и объединения интерфейсов (зачем не понял)

VD>Объединения — это вариантные типы. А пересечения любые другие классы. Так что ничего кроме нового синтаксиса для старых вещей они не придумали.
Тут ты не прав.
Объединения они не заменяют алгебраические типы, а дополняют их.
Более того при помощи объединений можно задать тип который может содержать только часть опций одного варианта.

А пересечения вообще мало где есть.
Они позволяют указать, что некий объект реализует сразу несколько не связанных наследованием интерфейсов.

А вот то что они сделали на объединениях опциональные типы мне не понравилось.
Иногда при таком раскладе информация теряется.
Например в этом случае если в Value засунуть опциональный тип то мы не сможем сказать лежит ли в словаре null или нет такого ключа.
calss Dictionary<Key, Value>
{
    shared Value? Get(Key key)...
}


VD>А вот синтаксис объявления переменных них у мягко говоря странный:

С переменными и полями они там вообще накуролесили будь здоров.
Там такой оверинжинеринг на марше что аж жуть.

VD>Вывод типов на зачаточном уровне. Макросов нет даже в зачатке.

Там весь вывод типов это аналог var в C#.

VD>Короче, язык может показаться интересным только на фоне убогой Явы. А после объявления Котлина ему вообще вряд ли выжить. Так и умрет не родившись.

Но что характерно даже этот язык и то лучше гугловских потугов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Ceylon
От: WolfHound  
Дата: 23.11.11 17:32
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>Его по-хорошему нужно разделить на несколько контрактов и выкинуть всякий мусор типа CanRead.

VD>Ну, и что мешало сделать это на базе интерфейсов?
WH>>Но такое разделение приведет к экспоненциальному росту интерфейсов в языках, которые не поддерживают пересечение типов.
VD>О, как?! Обоснуй.
Ну, давай разделим Stream на три интерфейса.
ReadableStream, WriteableStream и SeekableStream.
Количество комбинаций, которые они дают, сам посчитаешь?
А если еще пару интерфейсов добавить?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.11 18:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Объединения — это вариантные типы. А пересечения любые другие классы. Так что ничего кроме нового синтаксиса для старых вещей они не придумали.

WH>Тут ты не прав.
WH>Объединения они не заменяют алгебраические типы, а дополняют их.

Это ты не прав. Это они и есть. В науке ничего другого не известно.
Разница только в том, что компилятор самостоятельно создает такие типы по месту.

WH>Более того при помощи объединений можно задать тип который может содержать только часть опций одного варианта.


Ну, да. Только в реале это будет новый вариантный тип в который будут входить эта часть опиций.

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

Первое, мягко говоря, не эффективно. Второе, мягко говоря, чудовищно не эффективно.

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

WH>А пересечения вообще мало где есть.


Они везде есть. Это просто класс который реализует интерфейс А, Б и Ц. Из их примера:
shared interface Collection<Element>
        satisfies Producer<Element> & Consumer<Element> {}


В чем тут разница с:
public interface Collection<Element> 
        : Producer<Element>, Consumer<Element> {}

?
Или, вот, казалось бы сложный случай:
shared class Transactional(Boolean requiresNew)
        satisfies OptionalAnnotation<Transactional,Member<Bottom,Void>> &
                  MethodAnnotation & AttributeAnnotation 
{


WH>Они позволяют указать, что некий объект реализует сразу несколько не связанных наследованием интерфейсов.


Афигеть! Ты не знал что Ява и Шарп это тоже умеют?

Заметь. У них ни одного примера объявления переменной с типом X&Y или параметра. "&" используется только в описании списка реализуемых интерфейсов.

WH>А вот то что они сделали на объединениях опциональные типы мне не понравилось.

WH>Иногда при таком раскладе информация теряется.
WH>Например в этом случае если в Value засунуть опциональный тип то мы не сможем сказать лежит ли в словаре null или нет такого ключа.
WH>
WH>calss Dictionary<Key, Value>
WH>{
WH>    shared Value? Get(Key key)...
WH>}
WH>


Или ты в примере ошибся, или ты что-то недопонял. Если у них в параметре типов указано Value, а не Value?, то Value? может быть получено только при условии, что в словаре нет такого элемента. Другой вопрос, что можно сделать так:
calss Dictionary<Key, Value?>
{
    shared Value? Get(Key key)...
}

Тогда конечно приплызд, так как Nothing|Nothing они рассматривают как Nothing.

Вот только какой смысл в таком словаре?

VD>>А вот синтаксис объявления переменных них у мягко говоря странный:

WH>С переменными и полями они там вообще накуролесили будь здоров.
WH>Там такой оверинжинеринг на марше что аж жуть.

Он там везде, на мой взгляд. В этом отношении Котлин выглядит по приличней. Сказывается, что он наследник, а не предок.

VD>>Вывод типов на зачаточном уровне. Макросов нет даже в зачатке.

WH>Там весь вывод типов это аналог var в C#.

Не. До C# им далеко. Там даже перегрузки нет. Без нее можно тупо использовать ХМ.

Я вот еще не понял есть ли у них неявные приведения типов. Похоже что нет.

И похоже что у них все типы ссылочные.

VD>>Короче, язык может показаться интересным только на фоне убогой Явы. А после объявления Котлина ему вообще вряд ли выжить. Так и умрет не родившись.

WH>Но что характерно даже этот язык и то лучше гугловских потугов.

Ну, Гугль — это вообще языкостроительная держава (гы-гы). Лучше нам денег дали бы.

ЗЫ

Мне вот интересует как в этом самом Циклоне объеденения получаются. Подозреваю, что они тупо сделали все типы ссылочными и решили этим все проблемы (как в Смолтоке). Только такой язык будет таким же тормозом как Солток. Когда каждый int — это объект о скорости вычислительных задач даже и заикаться не приходится. Разве что надеяться на всемогущий оптимизатор, которые локально сможет превратить объектный говнокод в машинный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.11 19:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ну, давай разделим Stream на три интерфейса.


Давай!

WH>ReadableStream, WriteableStream и SeekableStream.

WH>Количество комбинаций, которые они дают, сам посчитаешь?

Комбинации идут лесом. Их сколько получится при реализации, столько и будет.
Интерфейсов будет 3.

WH>А если еще пару интерфейсов добавить?


Будет 5.

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

И еще одни встречный вопрос. Что будет при компиляции вот такого примера?
using System.Console;

interface IRead { }
interface IWrite { }
interface ISeek { }

class A : IRead,  IWrite, ISeek {}
class B : IWrite, ISeek {}
class C : IRead,  ISeek {}
class D : IRead {}

module M
{
  RandomRead[T](x : T) : void
    where T: IRead, ISeek
  {
    WriteLine(x.GetType().Name)
  }
    
  Main() : void
  {
    RandomRead(A());
    RandomRead(B()); 
    RandomRead(C());
    RandomRead(D());
  }
}

И почему вариант А и C таки скомпилируются? Оно же, по твоей идее, без пересечения типов работать то не должно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Ceylon
От: WolfHound  
Дата: 23.11.11 19:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это ты не прав. Это они и есть. В науке ничего другого не известно.

VD>Разница только в том, что компилятор самостоятельно создает такие типы по месту.
Ну начнем с того что классические алгебраические типы для опций вообще никаких новых типов не создают.
Эту самодеятельность гибриды начали.

VD>Ну, да. Только в реале это будет новый вариантный тип в который будут входить эта часть опиций.

Не совсем.
Если бы это был новый вариантный тип, то к нему нельзя было бы присвоить опции старого варианта.

VD>Кстати, их дизайн подразумевает или принципиальный отказ от любых значимых типов (т.е. они даже яву в маразме переплюнули), или они будут вынуждены на любой чих клепать новые классы (незаметно).

Дизайн таких типов это не предусматривает.
Но вот то, что они компилируются в жабу, выбора им не оставляет.

VD>Первое, мягко говоря, не эффективно. Второе, мягко говоря, чудовищно не эффективно.

А какие варианты?
В немерле если захочешь положить int в опцию варианта тоже будет объект создан.

VD>Заметь. У них ни одного примера объявления переменной с типом X&Y или параметра. "&" используется только в описании списка реализуемых интерфейсов.

Это подразумевается, плюс есть в тестах.
https://github.com/ceylon/ceylon-spec/blob/master/test/typing/Intersection.ceylon
Ну, теперь покажи мне тоже самое в жабе или шарпе.
Так даже немерле не умеет.

VD>Или ты в примере ошибся, или ты что-то недопонял.

А не приходило в голову, что это ты что-то недопонял?
Dictionary<Int, String?>
В этом случае Get возвращает Nothing|Nothing|String который редуцируется в Nothing|String.
И мы теряем информацию о том положили мы null в словарь или мы вообще в словарь ничего не клали.

VD>Не. До C# им далеко. Там даже перегрузки нет. Без нее можно тупо использовать ХМ.

Им там даже ХМ не нужен.
Они тупо идут по коду и проставляют переменным тот тип который получился в инициализаторе.
Я же говорю весь вывод типов сводится к аналогу var.

VD>Я вот еще не понял есть ли у них неявные приведения типов. Похоже что нет.

Нету. И они этим очень гордятся.

VD>Мне вот интересует как в этом самом Циклоне объеденения получаются. Подозреваю, что они тупо сделали все типы ссылочными и решили этим все проблемы (как в Смолтоке).

Ну, если делать свою ВМ, которая это понимает из коробки то это решается почти тривиально.
Но при компиляции в жабу... Таки да. Тушите всех.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Ceylon
От: WolfHound  
Дата: 23.11.11 19:47
Оценка: 4 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>У меня встречный вопрос. Ты видел хотя бы одном примере чтобы они этот & для переменных или параметров использовали? Только во ведении заикнулись и все.

В тестах видел.

VD>Как ты думаешь, почему?

Ну может ты раскажешь?

VD>И почему вариант А и C таки скомпилируются? Оно же, по твоей идее, без пересечения типов работать то не должно.

А теперь попробуй сложить их в одну коллекцию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.11 21:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Разница только в том, что компилятор самостоятельно создает такие типы по месту.

WH>Ну начнем с того что классические алгебраические типы для опций вообще никаких новых типов не создают.

Кто такие "классические алгебраические типы"? Просвети, плиз. А то я знаком с теорией, которая ни разу ни интересна, так как чистая математика. И с практикой. Практика в МЛ, например, показывают, что под каждый тип заводят новый тип. Аналог сишного юниона с доп.полем описывающим идентификатор текущего типа. Еще знаю реализацию на базе поинтера в языках с хорошей информацией о типах (вроде дотнета). Только и там нужно или заводить отдельный тип, или чтобы все значения по ссылке передавались.

WH>Эту самодеятельность гибриды начали.


Да ладно.

VD>>Ну, да. Только в реале это будет новый вариантный тип в который будут входить эта часть опиций.

WH>Не совсем.
WH>Если бы это был новый вариантный тип, то к нему нельзя было бы присвоить опции старого варианта.

Что помешает? Создаем новый вариант с полями (или набор подтипов) и вперед. Накладно, конечно, но работает.
Алтернатива только одна — все типы всегда передавать по ссылке и хранить любой вариант в object-е. Тогда небольшой компиляторной магии для проверки типов будет достаточно. Только вот это приговор производительности.

VD>>Кстати, их дизайн подразумевает или принципиальный отказ от любых значимых типов (т.е. они даже яву в маразме переплюнули), или они будут вынуждены на любой чих клепать новые классы (незаметно).

WH>Дизайн таких типов это не предусматривает.
WH>Но вот то, что они компилируются в жабу, выбора им не оставляет.

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

VD>>Первое, мягко говоря, не эффективно. Второе, мягко говоря, чудовищно не эффективно.

WH>А какие варианты?
WH>В немерле если захочешь положить int в опцию варианта тоже будет объект создан.

Ну, да. Только я это явно сделаю, а не легким мановением руки. И в немерле нет никаких Natural и Number и отношений сабтайпинга между ними и целыми. Если я сделаю мат библиотеку и в качестве числа буду использовать в ней вариант Number хранящий все возможные типы чисел, то ты первый меня высмеешь и будешь обзывая нехорошими словами пальцем на меня показывать. И будешь прав, так как тогда уж проще было бы все decimal реализовать. Не эффективно, конечно, но не так фатально хотя бы.

Вот этот вот пример:
Natural|Integer i = -1;
Number num = i;  // Number is a supertype of both Natural and Integer
String|Natural|Integer val = i; // String|Natural|Integer is a supertype of Natural|Integer
Object obj = val; // Object is a supertype of String, Natural, and Integer

лично мне говорит, что у них все типы ссылочные.

Судя по всему производительность их вообще не колышет. У них даже массивов нет. Ява просто отдыхает по сравнению с этим чудом в чайных пакетиках.


VD>>Заметь. У них ни одного примера объявления переменной с типом X&Y или параметра. "&" используется только в описании списка реализуемых интерфейсов.

WH>Это подразумевается, плюс есть в тестах.
WH>https://github.com/ceylon/ceylon-spec/blob/master/test/typing/Intersection.ceylon
WH>Ну, теперь покажи мне тоже самое в жабе или шарпе.

Да в жабе то все как раз круто. Там дженирики — это экзестенциальные типы. Там много чего можно наворотить. Правда, та же фигня. Все боксится к чертям.
Но в Яве ведь массивы есть и встроенные типы. У них есть int, а есть Integer. Если ты что-то посчитать решил, то вряд выберет Integer (т.е. ссылочную обертку над целым).

В дотнете все еще печальнее. Дженерики могут оперировать с значимыми типами. Но кое что можно. Ограничения никто не отменял ведь.

WH>Так даже немерле не умеет.


А нужно? Не, тесты у них очень круты. А на практике то оно надо?
Точнее даже поставим вопрос по другому. А надо ли оно учитывая то во что это выльется на практике?

VD>>Или ты в примере ошибся, или ты что-то недопонял.

WH>А не приходило в голову, что это ты что-то недопонял?
WH>Dictionary<Int, String?>
WH>В этом случае Get возвращает Nothing|Nothing|String который редуцируется в Nothing|String.
WH>И мы теряем информацию о том положили мы null в словарь или мы вообще в словарь ничего не клали.

Ну, да. Только зачем это делать то? Теоретически наверно можно и Dictionary<Int, Nothing> описать. Вот только кроме смеху от этого никакого навара.
В общем, теоретически — это конечно косяк. Но на практике проблемы будут только у дятлов.

Если бы у них были констрэйны, то можно было бы наложить ограничение, что значение не должно быть Nothing (т.е. нулабл).

И кстати, то что у них Nothing|Nothing редуцируется — это еще одно, косвенное, подтверждение того, что они все значения по ссылкам хранят. Если был они создавали бы типы-обертки (вроде вариантов), то редукции не происходило бы. По крайней мере у нас таких проблем нет. Если я объявлю Hashtable[int, option[string]], то его метод Get вернет option[option[string]].

VD>>Не. До C# им далеко. Там даже перегрузки нет. Без нее можно тупо использовать ХМ.

WH>Им там даже ХМ не нужен.
WH>Они тупо идут по коду и проставляют переменным тот тип который получился в инициализаторе.

Ну, как же? А объеденения/пересечения? Они же по коллекциям с инициализаторов объеденения получают.
Так что-то очень похожее на классический ХМ.

WH>Я же говорю весь вывод типов сводится к аналогу var.


Ну, в Шарпе то сейчас вывод те такой уж и просто. Констрэйны, перегрузки, неявные приведения типов — это все накладывает отпечаток. Хотя конечно не бином Ньютона.

VD>>Я вот еще не понял есть ли у них неявные приведения типов. Похоже что нет.

WH>Нету. И они этим очень гордятся.

Гы. Это какая-то добрая традиция гордиться недостатками .
Типа не смогли реализовать — записали в преимущества. Вот сплайсы не осилили — лажа, у нас классная конкатенация строк зато есть!

VD>>Мне вот интересует как в этом самом Циклоне объеденения получаются. Подозреваю, что они тупо сделали все типы ссылочными и решили этим все проблемы (как в Смолтоке).

WH>Ну, если делать свою ВМ, которая это понимает из коробки то это решается почти тривиально.

Они вроде по верх Явы работают? Или это я с Котлином путаю?
Потом все равно без полной ссылочности проблем будет выше крыши.

Вообще, есть только два способа разместить пересекающиеся типы в памяти — запихнуть их в кучу и пересекать указатели (при этом нужно чтобы в куче еще информация о типах будет лежать), и создать нечто вроде сишного объеденения с тегом описывающим тип. И то, и то — оверхэд. Просто для красоты системов типов такое использовать нельзя, на мой (воспитанный злым С) взгляд.

WH>Но при компиляции в жабу... Таки да. Тушите всех.

Свет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.11.11 21:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>У меня встречный вопрос. Ты видел хотя бы одном примере чтобы они этот & для переменных или параметров использовали? Только во ведении заикнулись и все.

WH>В тестах видел.
VD>>Как ты думаешь, почему?
WH>Ну может ты раскажешь?

Ага, легко. На фиг они не нужны в 99% случаев. В немерловых тестов тоже много офигительных выкрутасов. Вот только больше их нигде не найти. Ну, вот на форумах в примерах, разв что .

А ради фичи которая полезна 3 раза в год прилеплять навороченную реализацию, способную легким движением руки просадить производительность кода, как-то не хочется.

VD>>И почему вариант А и C таки скомпилируются? Оно же, по твоей идее, без пересечения типов работать то не должно.

WH>А теперь попробуй сложить их в одну коллекцию.

Легко! Только я туда реальные объекты сложу. А коллекцию в параметр передам:
using Nemerle.Collections;
using System.Console;

interface IRead { }
interface IWrite { }
interface ISeek { }

class A : IRead, IWrite, ISeek {}
class B : IWrite, ISeek {}
struct C : IRead, ISeek {}
class D : IRead {}

module M
{
  RandomRead[T](x : Seq[T]) : void
    where T: IRead, ISeek
  {
    WriteLine(x.GetType())
  }
    
  Main() : void
  {
    RandomRead([A()]);
    RandomRead(array[C()]);
  }
}

Обрати внимание, что даже структура прокатывает, потому как рантайм специализации генерирует.

Я это все к тому, что имеющихся в дотнете средств, для правильного дизайна хватает. Но пишут как умеют. А Stream — это вообще наследие эры динозавров, когда еще дженериков в природе не было.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.11 00:50
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Спасибо, ни где не читал, что есть именованны параметры в немерли... давно они там?


Лет восемь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Ceylon
От: WolfHound  
Дата: 24.11.11 09:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А ради фичи которая полезна 3 раза в год прилеплять навороченную реализацию, способную легким движением руки просадить производительность кода, как-то не хочется.

Это твои фантазии.
1)Если их не использовать то и влияния они никакого не окажут.
2)При поддержке на уровне рантайма пересечение интерфейсов будет работать ровно с той же скоростью что и обычные интерфейсы.
Ведь что такое вызов методы через интерфейс?
Это обращение к таблице интерфейсов от туда получают таблицу методов интерфейса.
Вся разница между одним интерфейсом и пересечением интерфейсов это то что компилятор будет иметь право обращаться к нескольким слотам таблице интерфейсов.
Где ты здесь просадку производительности нашёл я не понял.

VD>Легко! Только я туда реальные объекты сложу. А коллекцию в параметр передам:

Ох. Выключи дурку и сложи объекты типов A и C в одну коллекцию.
Что? Не можешь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Ceylon
От: WolfHound  
Дата: 24.11.11 10:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И с практикой. Практика в МЛ, например, показывают, что под каждый тип заводят новый тип.

Да правда чтоли?
Чтобы провернуть такой фокус нужна поддержка сабтапинга.
Покажи мне его в ML'ях.

VD>Что помешает? Создаем новый вариант с полями (или набор подтипов) и вперед. Накладно, конечно, но работает.

А данная система типов позволяет ничего не создавать.
Оверхед 0.

VD>Алтернатива только одна — все типы всегда передавать по ссылке и хранить любой вариант в object-е. Тогда небольшой компиляторной магии для проверки типов будет достаточно. Только вот это приговор производительности.

Ох. Совсем с фантазией плохо.
Если у нас подмножество опций варианта, то нам вообще ничего делать по сравнению с обычными вариантами не надо.
Это чисто статическая информация, которая, например, говорит match'у что доступны только эти опции и остальные проверять не надо.

VD>Да у жабы то как раз есть встроенные значимые типы. Но вот в их дизайн это никак не вписывается. Ну, или они на каждый чих невидимо значения боксят.

Зачем? .НЕТ ведь на каждый чих ничего не боксит.

VD>Идеологически (теоретически) выглядит красиво, но с практической точки зрения это задница.

Если писать свой рантам, то будет вообще все шоколадно.

VD>Ну, да. Только я это явно сделаю, а не легким мановением руки. И в немерле нет никаких Natural и Number и отношений сабтайпинга между ними и целыми.

И этим не нужно гордится.
Это косяк .НЕТ который перекочевал в немерле.

VD>Если я сделаю мат библиотеку и в качестве числа буду использовать в ней вариант Number хранящий все возможные типы чисел, то ты первый меня высмеешь и будешь обзывая нехорошими словами пальцем на меня показывать. И будешь прав, так как тогда уж проще было бы все decimal реализовать. Не эффективно, конечно, но не так фатально хотя бы.

Ох.
Если все делать правильно. Те взять классы типов из хаскеля и не стесняться генерировать специализированные версии кода (что тривиально) то все будет просто замечательно.
И это, вообще говоря, единственно верный дизайн.
А то что в .НЕТ это порнография непотребная.

VD>Вот этот вот пример:

хъ
VD>лично мне говорит, что у них все типы ссылочные.
А мне говорит, что дизайн языка не мешает вот в это строчке сделать автобоксинг.
Natural|Integer i = -1;

А при поддержке рантайма даже автобоксинг не понадобится.

VD>Судя по всему производительность их вообще не колышет. У них даже массивов нет. Ява просто отдыхает по сравнению с этим чудом в чайных пакетиках.

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

VD>Да в жабе то все как раз круто. Там дженирики — это экзестенциальные типы. Там много чего можно наворотить. Правда, та же фигня. Все боксится к чертям.

Ох. В жабе дженериков нет.
Все что там есть это аннотации, которые проверяет компилятор.
А внутри все работает через Object'ы.

VD>А нужно? Не, тесты у них очень круты. А на практике то оно надо?

VD>Точнее даже поставим вопрос по другому. А надо ли оно учитывая то во что это выльется на практике?
А во что оно выльется?
Только сначала два раза перечитай то, что я написал и хорошо подумай.
Повторю еще раз: Если рантайм делать руками, то оверхед будет нулевой.

VD>Ну, да. Только зачем это делать то? Теоретически наверно можно и Dictionary<Int, Nothing> описать. Вот только кроме смеху от этого никакого навара.

VD>В общем, теоретически — это конечно косяк. Но на практике проблемы будут только у дятлов.
Те ты хочешь сказать что словарь, который хранит опциональные значения, не нужен никому и никогда?

VD>Если бы у них были констрэйны, то можно было бы наложить ограничение, что значение не должно быть Nothing (т.е. нулабл).

Зачем?

VD>И кстати, то что у них Nothing|Nothing редуцируется — это еще одно, косвенное, подтверждение того, что они все значения по ссылкам хранят. Если был они создавали бы типы-обертки (вроде вариантов), то редукции не происходило бы. По крайней мере у нас таких проблем нет. Если я объявлю Hashtable[int, option[string]], то его метод Get вернет option[option[string]].

Ох.
Это просто разные механизмы.
Они похожи, но они разные.
Не путай варианты с объединениями.
Это не одно и то же.
И варианты у них тоже есть.

VD>Ну, как же? А объеденения/пересечения? Они же по коллекциям с инициализаторов объеденения получают.

Ох. Пройтись по коллекции и сложить все найденные типы в Set.
Тоже мне вывод типов.

VD>Гы. Это какая-то добрая традиция гордиться недостатками .

VD>Типа не смогли реализовать — записали в преимущества. Вот сплайсы не осилили — лажа, у нас классная конкатенация строк зато есть!
Ну нужно же хоть как-то оправдать свои фейлы.

VD>Они вроде по верх Явы работают? Или это я с Котлином путаю?

И то и другое по верх явы работает.
Но меня это не волнует.
Я дизайн языка исследую.

VD>Вообще, есть только два способа разместить пересекающиеся типы в памяти — запихнуть их в кучу и пересекать указатели (при этом нужно чтобы в куче еще информация о типах будет лежать), и создать нечто вроде сишного объеденения с тегом описывающим тип. И то, и то — оверхэд. Просто для красоты системов типов такое использовать нельзя, на мой (воспитанный злым С) взгляд.

А варианты можно?
Если варианты можно, то почему нельзя использовать объединения?
Они хоть и ведут себя по разному но их реализация будет идентична.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Ceylon
От: Ziaw Россия  
Дата: 24.11.11 13:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Повторю еще раз: Если рантайм делать руками, то оверхед будет нулевой.


А что, есть такие планы?
Re[8]: Ceylon
От: WolfHound  
Дата: 24.11.11 14:25
Оценка:
Здравствуйте, Ziaw, Вы писали:

WH>>Повторю еще раз: Если рантайм делать руками, то оверхед будет нулевой.

Z>А что, есть такие планы?
У кого?
А авторов Ceylon? Не знаю. Но сильно сомневаюсь.
У меня? В отдаленной перспективе есть такое желание. Ибо существующие рантаймы мне очень не нравятся.
Но будет это не раньше чем я закончу с фронтендом Н2.
Ибо без ДСЛей писать такое полное сумасшествие.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.11 16:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Ну, да. Только я это явно сделаю, а не легким мановением руки. И в немерле нет никаких Natural и Number и отношений сабтайпинга между ними и целыми.

WH>И этим не нужно гордится.
WH>Это косяк .НЕТ который перекочевал в немерле.

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

Даже свой рантайм вряд ли позволит обойти эти ограничения. Можно только сделать вид что все хорошо.

WH>Если все делать правильно. Те взять классы типов из хаскеля и не стесняться генерировать специализированные версии кода (что тривиально) то все будет просто замечательно.

WH>И это, вообще говоря, единственно верный дизайн.
WH>А то что в .НЕТ это порнография непотребная.

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

WH>
WH>Natural|Integer i = -1;
WH>

WH>А при поддержке рантайма даже автобоксинг не понадобится.

Ну, и как ты предлагаешь представлять null в данном случае?

WH>Мне плевать, что колышет авторов сабжа.

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

Ну, в теории можно многое сделать. Только вот сколько жизней на это надо положить.

ЗЫ

Ладно, убедил речистый. Если сделать идеальный рантамй, то в нем может и моно обойти многие проблемы. Только вот доживем ли мы до этого момента?

Я осмелюсь напомнить, что последний комит в парсер у тебя был ~20 дней назад. Там ведь казалось бы фигня осталось. Но даже эта фигня затягивается на месяцы. А от этой фигни зависит дальнейшее развитие.

Давай на время прекратим мечтать и займемся прозой?

Сейчас нам всем нужен идеальный парсер. До делай его и начнем мечтать об идеальном типизаторе. А там уже глядишь и до идеального рантайма доживем. ОК?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Ceylon
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.11.11 16:42
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>А что, есть такие планы?


О!!! Планы это единственное что у нас в избытке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.