В реальности я надеюсь, что команда Н2 закончит проект и ее уволят... - Nemerle

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

F>> CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали.
А>Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

То что вы хотите называется "Ковариантность"
и это свойство не зависит от статики-динамики типизации

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

А>Тем что в статике требуется полное описание интерфейса и полное описание интерфейса всех параметров всех методов. Если например меняется тип одного из параметров, меняется и интерфейс.

не всё ли равно где будет размещено "полное описание интерфейса всех параметров всех методов"
-в документации
или
-в коде в секции "интерфейс"

или вы хотите предложить революционный способ динамики без документации?

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

P>То что вы хотите называется "Ковариантность"
P>и это свойство не зависит от статики-динамики типизации
Нет, ковариантность я как раз не хотел сказать.

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

WH>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

Очень приятная новость.

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

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

WH>>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

DR>Очень приятная новость.

Автоматом в unsafe или просто поддержка данной секции в немерли?

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

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

F>> Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.
WH>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

Я так понимаю макросами не все тут решилось ?
Частично unsafe можно симулировать в частности макрос fixed.

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

_NN>Я так понимаю макросами не все тут решилось ?
_NN>Частично unsafe можно симулировать в частности макрос fixed.

Но это же просто пиннинг объектов, настоящих указателей поддерживаемых CLR ведь не появляется, а IntPtr годится разве что передать куда-нибудь.

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

_NN>Я так понимаю макросами не все тут решилось ?
_NN>Частично unsafe можно симулировать в частности макрос fixed.
Там только получение IntPtr
А этого не достаточно.
Нужны нормальные указатели. С арифметикой и типизацией.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

F> Еще хочется, пожелать, в зависимости от позиционирования языка — перестать быть зависимым от ненужного. Например использование лямбд на аргументе Predicate<T> — тянет за собой !!!ненужную!!! за собой Nemerle.dll.
А вот F# тоже не тянет ненужное ?

F> Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого?
Можно продумать как это отменить, а чем конкретно это вам мешает ?

F> А вообще — я хотел сделать проект .NET 2.0 only. Конечно, никто не мешает, не использовать лишнее и референс не попадёт — но — это дурость несусветная, а если удалить референс — у интеграции крыша едет.
А что там мешает сделать .Net 2.0 only ?

F> Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить.
Ну к примеру:

using System.Console;

def a = x => x + 1;
def b = y => y * 2;

def c = a >> b <| 4;
WriteLine(c);

F> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

Это стоит записать в разряд недоработок, и исправить

C# компилятор тоже создает класс для лямбды.

F> В общем — N — хороший язык, действительно решает кучу задач. Но и детских болезней у него капец как много. От глупого IL кода, с теми же def — каждый следующий def что-то не собирается переиспользовать слот вообще — так и в целом встречались.

Делов то, подправьте реализацию и будет вам счастье

F> skip
F> Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
Код компилятора открыт для улучшений.

F> [Record] — нафиг. Это дрэг. А особенно с variant-ом.
Не нравится Record , не пользуйтесь. Никто вас не обязывает.

F> Код сгенерированный в итоге — не должен содержать ниаких левых аттрибутов. Не нужно аттрибутов, позволяющих восстановить средства его генерации (это кстати о вариантах — варианты — классы — да одно фигня это всё). Короче хрень получается щас, которая иногда друг с другом конфликтует.
Ничего не понятно.

F> С другой стороы — щас опять кодю на шарпе. Не хватает match. Очень и очень. Ну и многого ещё. Но вот стандартной библиотеки Nemerle — как раз очень хорошо, что нет. У меня хватает своих нароботок вообще. Some — это вообще бред в N. option — не бред. А вот реализации — бред. Тут уже обсуждали не раз.
Давайте вы будете писать конкретные проблемы.
Чем не нравится option ?
Между прочим в том же F# открыто пространство имен с option, Some, None. Но это вас не смущает.

F> Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.
В каком виде нужен unsafe ?
На текущий момент несколько вариантов.
1. Использовать C#.
2. Использовать Masrhal и обернуть в макрос для удобства.
3. Использовать C++/CLI .

F> Знаю, что пахнет негативом, это не со зла, наоборот, хочется большего и лучшего. Кому-то мои замечания покажутся глупыми — кому-то нет.
Да, есть много мелких недоработок.
Но если вы заинтересованны в развитии, то их можно устранить.
Код компилятора открыт, каждый может добавить то, что ему недостает и исправит недостатки которые ему мешают.
Вот я не поленился и добавил пару фич. Это не так сложно как кажется.

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

_NN>А вот F# тоже не тянет ненужное ?

Не имею ни малейшего понятия. F# я несколько раз загружал, потому что в какой-то тулзе нужно было поправить баг, но был настолько впечатлён — что стараюсь держаться от него подальше.

F>> Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого?
_NN>Можно продумать как это отменить, а чем конкретно это вам мешает ?
Ну мешает тем, что схватить зависимость от Nemerle.dll — очень легко, и средств контроллить этого нет. В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.

_NN>А что там мешает сделать .Net 2.0 only ?
Опять же неясно как таргетить компилятор на него. Но это беда текущей реализации компилятора и только.

F>> Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить.

using System;

class Program
{
    static Main() : void
    {
        Method(x => x + 1);
    }

    static Method(func : Func[int, int]) : void
    {
        Console.WriteLine( func(100) );
    }
}

Приводит к тому что в теле Program появляется новый класс, который реализует — Nemerle.Builtins.Function.
В шарпе же новый inner class НЕ генерируется. Генерируется метод с телом лямбды и поле кешированным делегатом.
Т.е. что не нравится:
1. в таком простом случае имеем зависимость от Nemerle.dll.
2. генерировать класс на каждый чих, может быть удобно, но довольно расточительно. Рантайму от этого точно никак не легче.

Каковы плюсы использования Nemerle.Builtins.Function?
1. Ну по всей видимости это позволяет возложить на рантайм кеширование делегата, упрощая код самого компилятора.
2. По идее обращение к такому делегату заставляет CLR проинициализировать класс делегата и уже не нужны проверки на существование делегата (т.е. возможно даже есть выигрыш в рантайме, т.к. код генерируемый шарпом вынужден постоянно проверять закеширован ли делегат). Но не помню уже точно как там происходит, CLR по моему утыкает код с проверками проинициализирован ли класс, и в итоге вполне можем получить тоже самое.

С другой стороны, Nemerle конечно же традиционно генерирует какую-то ерунду, сводя на нет плюсы которые мы только что раскрыли:

    IL_0000: ldsfld class Program/_N__N_lambda__3301__3377 Program/_N__N_lambda__3301__3377::Instance
    IL_0005: stloc.0
    IL_0006: ldloc.0
    IL_0007: dup
    IL_0008: ldvirtftn instance !1 class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>::apply(!0)
    IL_000e: newobj instance void class [mscorlib]System.Func`2<int32, int32>::.ctor(object, native int)
    IL_0013: call void Program::Method(class [mscorlib]System.Func`2<int32, int32>)
    IL_0018: ret

В строчке IL_000e — мы создаём делегат, и никакого кеша для System.Func оказывается не существует.

Конечно же переписав код без Func, а используя функциональный тип — имеем уже код не имеющий этой проблемы:

.method private hidebysig static 
    void Main () cil managed 
{
    // Method begins at RVA 0x2064
    // Code size 13 (0xd)
    .maxstack 1
    .entrypoint
    .locals init (
        [0] class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>
    )

    IL_0000: ldsfld class Program/_N__N_lambda__3327__3341 Program/_N__N_lambda__3327__3341::Instance
    IL_0005: stloc.0
    IL_0006: ldloc.0
    IL_0007: call void Program::Method(class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>)
    IL_000c: ret
} // end of method Program::Main

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

Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.

F>> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

_NN>Это стоит записать в разряд недоработок, и исправить

_NN>C# компилятор тоже создает класс для лямбды.

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

F>> В общем — N — хороший язык, действительно решает кучу задач. Но и детских болезней у него капец как много. От глупого IL кода, с теми же def — каждый следующий def что-то не собирается переиспользовать слот вообще — так и в целом встречались.

_NN>Делов то, подправьте реализацию и будет вам счастье

Не уверен что это так просто.

F>> Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
_NN>Код компилятора открыт для улучшений.
F>> [Record] — нафиг. Это дрэг. А особенно с variant-ом.
_NN>Не нравится Record , не пользуйтесь. Никто вас не обязывает.

using System;

[Record]
class X
{
   x : int;
}

Отлично, код компилируется, хотя я об этом его не просил.
Я за существование полезных макросов, но по дефолту открывать нэймспейсы с ними, как по мне, стоит только для фундаментальные макросов, навроде if. А так у меня есть Record, но "запретить" его использовать я никак не могу. Есть какой-то ключик о котором я не знаю?

_NN>Давайте вы будете писать конкретные проблемы.
_NN>Чем не нравится option ?
_NN>Между прочим в том же F# открыто пространство имен с option, Some, None. Но это вас не смущает.
Аналогично как с делегатами. Получаю в нагрузку некотроллируемую зависимость. Это следствие вышеописанного.

_NN>В каком виде нужен unsafe ?
_NN>На текущий момент несколько вариантов.
_NN>1. Использовать C#.
_NN>2. Использовать Masrhal и обернуть в макрос для удобства.
_NN>3. Использовать C++/CLI .
Поддержка указателей. Использую C#, т.к. других вариантов нет. unsafe — это не только интероп, но крайне полезен при реализации методов критичных по скорости.

_NN>Да, есть много мелких недоработок.
_NN>Но если вы заинтересованны в развитии, то их можно устранить.
_NN>Код компилятора открыт, каждый может добавить то, что ему недостает и исправит недостатки которые ему мешают.
_NN>Вот я не поленился и добавил пару фич. Это не так сложно как кажется.
_NN>

Да знаю я.

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

P>>То что вы хотите называется "Ковариантность"
F> Нет, ковариантность я как раз не хотел сказать.

я отвечал для товарища анонима

DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

interface ICellRange ...
interface ICellRange2 : ICellRange ...

interface IDocument
{
  ICellRange GetCell();
}
interface IDocument2 : IDocument
{
  ICellRange2 GetCell();
}

class CellRangeImp : ICellRange2 ...

class DocumentImp : IDocument2
{
  public CellRangeImp GetCell()
  {
    return new CellRangeImp();
  }
}

c#3.5
и ни строчки лишнего, ни строчки динамики

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

А.

Ну можно по всякому, собственно было бы желание решить проблему — решение найдется.

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

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

_NN>>А вот F# тоже не тянет ненужное ?

F> Не имею ни малейшего понятия. F# я несколько раз загружал, потому что в какой-то тулзе нужно было поправить баг, но был настолько впечатлён — что стараюсь держаться от него подальше.

Дам подсказку, в F# присутствуют все вами перечисленные проблемы с открытыми пространствами имен и зависимостями =)

F> Ну мешает тем, что схватить зависимость от Nemerle.dll — очень легко, и средств контроллить этого нет. В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.
Как раз большинству это не мешает.
Это сродни С++ проектам без CRT.
Не спорю, могло быть и полезно, но никто это не реализовывал, потому как не типичный случай.

_NN>>А что там мешает сделать .Net 2.0 only ?
F> Опять же неясно как таргетить компилятор на него. Но это беда текущей реализации компилятора и только.
F>Приводит к тому что в теле Program появляется новый класс, который реализует — Nemerle.Builtins.Function.
F>В шарпе же новый inner class НЕ генерируется. Генерируется метод с телом лямбды и поле кешированным делегатом.
Оптимизацию приделать можно было бы
F>Т.е. что не нравится:
F>1. в таком простом случае имеем зависимость от Nemerle.dll.
F>2. генерировать класс на каждый чих, может быть удобно, но довольно расточительно. Рантайму от этого точно никак не легче.
Это в следствии от того, что функциональный тип появился в Nemerle когда еще не было C# 3 и не было System.Func / System.Action.
А переделывать все это не было времени.
Как уже я говорил, можно вынести на обсуждение и подумать как это улучшить.

F>Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.
Кодогенерацию можно улучшать и улучшать, но на это точно времени ни у кого нет.

F> Не уверен что это так просто.

Смотря что конечно.

F>Отлично, код компилируется, хотя я об этом его не просил.
F>Я за существование полезных макросов, но по дефолту открывать нэймспейсы с ними, как по мне, стоит только для фундаментальные макросов, навроде if. А так у меня есть Record, но "запретить" его использовать я никак не могу. Есть какой-то ключик о котором я не знаю?
Предложение дельное, выносите на обсуждение.

F> Поддержка указателей. Использую C#, т.к. других вариантов нет. unsafe — это не только интероп, но крайне полезен при реализации методов критичных по скорости.
Как тут писали будущее не за горами

F> Да знаю я.

Ну так за чем дело встало ?

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

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

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

И ещё наверное удобнее на ты...

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

WH>>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

DR>Очень приятная новость.

Ну, я делаю не совсем ансфэйф. Только его часть позволяющую зпинить массив или строку и получить доступ к нему по индексу (без проверок).

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

А>Автоматом в unsafe или просто поддержка данной секции в немерли?

Что?

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

VD>Ну, я делаю не совсем асфэйф. Только его часть позволяющую зпинить массив или строку и получить доступ к нему по индексу (без проверок).

Мне больше ничего и не надо.

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

WH>Нужны нормальные указатели. С арифметикой и типизацией.

Думаю, за завтра я это дело доделаю.

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

F>> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

_NN>Это стоит записать в разряд недоработок, и исправить

_NN>C# компилятор тоже создает класс для лямбды.

Это надо, скорее, записать в разряд легкомысленных высказываний со стороны fddima. Скорее всего он что-то напутал или намеренно искажает факты. Не с чего там компиляции замедляться. А вот исполнение от функциональных типов только ускоряется.

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

_NN>>Это стоит записать в разряд недоработок, и исправить

_NN>>C# компилятор тоже создает класс для лямбды.

VD>Это надо, скорее, записать в разряд легкомысленных высказываний со стороны fddima. Скорее всего он что-то напутал или намеренно искажает факты. Не с чего там компиляции замедляться. А вот исполнение от функциональных типов только ускоряется.
Ну ладно, и вправду сбрехал. Почему-то показалось что сильно изменилось время.
На самом деле:

Func[X,Y] — 640ms
X -> Y — 748ms

Но из всего, на что можно было бы ответить, ты почему-то выбрал самое неважное.

	От:	para
	Дата:	15.08.12 07:54
	Оценка:

	От:	para
	Дата:	15.08.12 08:15
	Оценка:

	От:	fddima
	Дата:	15.08.12 08:28
	Оценка:

От:	Don Reba	https://stackoverflow.com/users/49329/don-reba
Дата:	15.08.12 09:20
Оценка:

	От:	Аноним
	Дата:	15.08.12 09:34
	Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	15.08.12 10:00
Оценка:

От:	VladD2	www.nemerle.org
Дата:	15.08.12 19:07
Оценка: