Здравствуйте, alvas, Вы писали:
A>Предлагаю в этой ветке обсудить какие возможности отсутствуют в Nemerle. A>В общем чего людям в жизни не хватает
Каррирование
(Шучу).
Ну так:
— структурная типизация (не очень понятно, как сделать — на основе кортежей?)
— higher rank polymorphism (непонятно, как сделать)
— поддержка экви-рекурсии (хз вообще как делать)
— зависимые типы (аналогично)
— что-то типа трейтов в скале не помешало бы (как делать — хз. single parameter сделать можно, все что дальше упирается в убогость генериков)
Из того поменять:
— Поведение оператора _ (плейсхолдера). Более логичным мне кажется такое поведение: считать все выражение, в котором содержится _, единой функцией.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, alvas, Вы писали:
A>>Предлагаю в этой ветке обсудить какие возможности отсутствуют в Nemerle. A>>В общем чего людям в жизни не хватает
ВВ>Каррирование
Подскажи пожалуйста чем Каррирование отличается/лучше от частичного примениения.
ВВ>(Шучу).
ВВ>Ну так: ВВ>- структурная типизация (не очень понятно, как сделать — на основе кортежей?) ВВ>- higher rank polymorphism (непонятно, как сделать) ВВ>- поддержка экви-рекурсии (хз вообще как делать) ВВ>- зависимые типы (аналогично) ВВ>- что-то типа трейтов в скале не помешало бы (как делать — хз. single parameter сделать можно, все что дальше упирается в убогость генериков)
Так как это читают и простые смертные просьба давать ссылки, чтобы можно было почитать что все это означает
ВВ>Из того поменять: ВВ>- Поведение оператора _ (плейсхолдера). Более логичным мне кажется такое поведение: считать все выражение, в котором содержится _, единой функцией.
Здравствуйте, alvas, Вы писали:
ВВ>>Каррирование A>Подскажи пожалуйста чем Каррирование отличается/лучше от частичного примениения.
Боюсь, если я сейчас скажу, что карррирование "ортогонально" частичному применению, то меня немедленно забанят
ВВ>>- структурная типизация (не очень понятно, как сделать — на основе кортежей?) ВВ>>- higher rank polymorphism (непонятно, как сделать) ВВ>>- поддержка экви-рекурсии (хз вообще как делать) ВВ>>- зависимые типы (аналогично) ВВ>>- что-то типа трейтов в скале не помешало бы (как делать — хз. single parameter сделать можно, все что дальше упирается в убогость генериков) A>Так как это читают и простые смертные просьба давать ссылки, чтобы можно было почитать что все это означает
Последние два пункта там вполне относятся к Немерле.
В целом, Немерле сейчас слишком завязан на свой текущий бэкенд в виде CLR. То, что умеет CLR (а умеет он не так много), умеет и Немерле. А то, что не умеет — вы. Генерики вот в CLR весьма ограниченные — таковые они и в Немерле. Хотелось бы меньшей заточенности под CLR. Например, при компиляции немерлевских генериков можно было бы использовать либо CLR генерики (в простых случаях), либо старый-добрый System.Object.
ВВ>>Из того поменять: ВВ>>- Поведение оператора _ (плейсхолдера). Более логичным мне кажется такое поведение: считать все выражение, в котором содержится _, единой функцией. A>А чем сейчас _ считается?
У меня сейчас Немерле под рукой нет, насколько я помню, там разбор _ зависит от приоритета операций.
Например, "_ * x + y" будет превращено в одну функцию, а "x + y * _" будет разобрано как "x + func". Что, в целом, как-то неочевидно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, alvas, Вы писали:
ВВ>>>Каррирование A>>Подскажи пожалуйста чем Каррирование отличается/лучше от частичного примениения.
ВВ>Боюсь, если я сейчас скажу, что карррирование "ортогонально" частичному применению, то меня немедленно забанят
Можно в личку
ВВ>>>- структурная типизация (не очень понятно, как сделать — на основе кортежей?) ВВ>>>- higher rank polymorphism (непонятно, как сделать) ВВ>>>- поддержка экви-рекурсии (хз вообще как делать) ВВ>>>- зависимые типы (аналогично) ВВ>>>- что-то типа трейтов в скале не помешало бы (как делать — хз. single parameter сделать можно, все что дальше упирается в убогость генериков) A>>Так как это читают и простые смертные просьба давать ссылки, чтобы можно было почитать что все это означает
ВВ>Ну в общем все это гуглится.
ВВ>Кстати, нашел вот такую ссылочку: ВВ>http://intoverflow.wordpress.com/2010/06/30/haskell-features-id-like-to-see-in-other-languages/
ВВ>Последние два пункта там вполне относятся к Немерле.
ВВ>В целом, Немерле сейчас слишком завязан на свой текущий бэкенд в виде CLR. То, что умеет CLR (а умеет он не так много), умеет и Немерле. А то, что не умеет — вы. Генерики вот в CLR весьма ограниченные — таковые они и в Немерле. Хотелось бы меньшей заточенности под CLR. Например, при компиляции немерлевских генериков можно было бы использовать либо CLR генерики (в простых случаях), либо старый-добрый System.Object.
Насколько я знаю в джаве они еще хуже. А где правильные генерики?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>- что-то типа трейтов в скале не помешало бы
Если через квазицитаты можно сделать интерфейсы с реализацией методов, то можно на макросах сделать.
Если нет — нужно добавить в компилятор возможность задавать реализацию интерфейсов.
Про трэиты было на старом сайте nemerle.
Кстати при наличии сменного backend'a наверное получится сделать как в haxe — генерация под нужную платформу,
при условии что сам компилятор nemerle будет использовать свою библиотеку, непривязанную к какой либо платформе.
Здравствуйте, Denom, Вы писали:
D>Если через квазицитаты можно сделать интерфейсы с реализацией методов, то можно на макросах сделать. D>Если нет — нужно добавить в компилятор возможность задавать реализацию интерфейсов. D>Про трэиты было на старом сайте nemerle.
Ну сама возможность писать реализацию в интерфейсе мне кажется все же вторичной. Более интересен сам механизм тайп-классов — словари функций, не привязанные к инстансу, со статическим, а не динамическим диспатчем функций ну и, соответстенно, перегрузкой. При этом все же хочется как в Скале, а не как в Хаскель — чтобы тайп-класс сам по себе был бы первоклассным объектом, и его можно было бы явно передать в функцию. Нечто вроде NamedInstances из Хаскелевого wish-листа. (При том, что в той реализации, которая есть в Скале, это получается как бы by design).
D>Кстати при наличии сменного backend'a наверное получится сделать как в haxe — генерация под нужную платформу, D>при условии что сам компилятор nemerle будет использовать свою библиотеку, непривязанную к какой либо платформе.
Собственно, это главное что нужно Немерле — перестать молиться на КЛР и посмотреть на другие платформы. Особенно интересен был бы конечно LLVM.
Здравствуйте, Аноним, Вы писали:
А>тип как первоклассный. То есть разрешить передачу типа в функцию. Тогда возможен отказ от генериков. Уменьшение стадий макросов
Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alvas, Вы писали:
A>Предлагаю в этой ветке обсудить какие возможности отсутствуют в Nemerle.
A>В общем чего людям в жизни не хватает
Компиляция в javascript
Здравствуйте, VladD2, Вы писали:
А>>тип как первоклассный. То есть разрешить передачу типа в функцию. Тогда возможен отказ от генериков. Уменьшение стадий макросов
VD>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, alvas, Вы писали:
D>>>Компиляция в javascript
A>>А можно поподробней? A>>Спиной чувствую что крутая фича, только не могу понять чем
I>С джаваскриптом кк раз вполне нормально — пишешь себе на своем языке, а код для браузера генерится сам собой.
Я все-таки думал, что не об этом была речь. Или не только об этом
Здравствуйте, alvas, Вы писали:
I>>С джаваскриптом кк раз вполне нормально — пишешь себе на своем языке, а код для браузера генерится сам собой.
A>Я все-таки думал, что не об этом была речь. Или не только об этом
Джаваскрипт может выполнять не только браузер. На ём и серверные приложения пишутся. Соответственно вместо написания N-бакэндов, можно написать один транслятор.
Re[4]: Чего нет в Nemerle - хотелки
От:
Аноним
Дата:
29.05.11 18:41
Оценка:
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
А>>>тип как первоклассный. То есть разрешить передачу типа в функцию. Тогда возможен отказ от генериков. Уменьшение стадий макросов
VD>>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.
A>Приведи пример, пожалуйста
def astype(a, type){a:type}
так же хотелось бы получать аргументы с разделением константные или вариабельные
например macro power(a,b:int)
{
match constant(a)
| true // построение быстрого алгоритма
| false // генерирование метода деления на 2
}
хотелось бы иметь возможность узнать чистая функция или нет
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, dotneter, Вы писали:
A>>>В общем чего людям в жизни не хватает D>>Компиляция в javascript
A>А можно поподробней? A>Спиной чувствую что крутая фича, только не могу понять чем
Фича конечно крутая, все уходит в веб, плюс js одна из немногих кросс мобильных платформ. От C# сложно отказаться политически и инструментально, но js я бы с удовольстием заменил на что нибудь статически типизированое.
Имхо, интересный вариант взять бек эндом какой нибудь PhoneGap или Titanium и писать для мобильных приложения на Nemerle.
Здравствуйте, dotneter, Вы писали:
D>Фича конечно крутая, все уходит в веб, плюс js одна из немногих кросс мобильных платформ. От C# сложно отказаться политически и инструментально, но js я бы с удовольстием заменил на что нибудь статически типизированое. D>Имхо, интересный вариант взять бек эндом какой нибудь PhoneGap или Titanium и писать для мобильных приложения на Nemerle.
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, dotneter, Вы писали:
D>>Фича конечно крутая, все уходит в веб, плюс js одна из немногих кросс мобильных платформ. От C# сложно отказаться политически и инструментально, но js я бы с удовольстием заменил на что нибудь статически типизированое. D>>Имхо, интересный вариант взять бек эндом какой нибудь PhoneGap или Titanium и писать для мобильных приложения на Nemerle.
A>Это все реклама. Вы принцип опишите.
Не пойму, какое тут нужно описание? Как обычно, язык X транслируется в js.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, alvas, Вы писали:
A>>Здравствуйте, dotneter, Вы писали:
D>>>Фича конечно крутая, все уходит в веб, плюс js одна из немногих кросс мобильных платформ. От C# сложно отказаться политически и инструментально, но js я бы с удовольстием заменил на что нибудь статически типизированое. D>>>Имхо, интересный вариант взять бек эндом какой нибудь PhoneGap или Titanium и писать для мобильных приложения на Nemerle.
A>>Это все реклама. Вы принцип опишите. D>Не пойму, какое тут нужно описание? Как обычно, язык X транслируется в js. D>
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, dotneter, Вы писали:
D>>Здравствуйте, alvas, Вы писали:
A>>>Здравствуйте, dotneter, Вы писали:
D>>>>Фича конечно крутая, все уходит в веб, плюс js одна из немногих кросс мобильных платформ. От C# сложно отказаться политически и инструментально, но js я бы с удовольстием заменил на что нибудь статически типизированое. D>>>>Имхо, интересный вариант взять бек эндом какой нибудь PhoneGap или Titanium и писать для мобильных приложения на Nemerle.
A>>>Это все реклама. Вы принцип опишите. D>>Не пойму, какое тут нужно описание? Как обычно, язык X транслируется в js. D>>
D>>def Sum(x:int, y:int){
D>> return x + y;
D>>}
D>>
->>> D>>
D>>function sum(x,y){
D>> return x + y;
D>>}
D>>
A>Всего лишь тупой Script#?
Если получится сделать умным, будем умным. Я как то не представляю, а что у вас были за фантазии? Что тут еще такого можно сделать?
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, alvas, Вы писали:
A>>Всего лишь тупой Script#?
A>Тогда уже лучше JavaScript -> JavaScript
Что простите? Можно поподробнее?
Здравствуйте, dotneter, Вы писали:
A>>Всего лишь тупой Script#? D>Если получится сделать умным, будем умным. Я как то не представляю, а что у вас были за фантазии? Что тут еще такого можно сделать?
Я имел в виду "Это всего лишь тупо Script#?"
Я никоим разом не хотел обидеть этот замечательный продукт.
Писать на популярном языке (C#) и транслировать в другой популярный язык (js). В этом я вижу смысл.
У гугла есть Java -> js. Из той же оперы.
Мое предложение компилируемый/типизированный (поправьте меня знающие люди) js -> js. Тоже было бы классно. А может уже есть?
А вот молодой но перспективный N или Ela -> js
Как вы думаете народ будет изучать йет эназэ язык чтобы от генерировал сорцы js? Вот и я сомневаюсь
Здравствуйте, alvas, Вы писали:
A>Как вы думаете народ будет изучать йет эназэ язык чтобы от генерировал сорцы js? Вот и я сомневаюсь
А зачем изучают новые языки, если давно придуман асемблер? Думаю у адекватных людей вопрос состоит не из, изучать или нет, а стоит оно изучения или нет, если сделать так что бы стоило, то не вижу никаких проблем. Есть например кросc мобальная Corona, думаю ее используют не только знатоки Lua.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, alvas, Вы писали:
A>>Как вы думаете народ будет изучать йет эназэ язык чтобы от генерировал сорцы js? Вот и я сомневаюсь D>А зачем изучают новые языки, если давно придуман асемблер? Думаю у адекватных людей вопрос состоит не из, изучать или нет, а стоит оно изучения или нет, если сделать так что бы стоило, то не вижу никаких проблем. Есть например кросc мобальная Corona, думаю ее используют не только знатоки Lua.
A>Вот я например, понимаю Peg. Надо мне например, калькулятор, парсер Wiki, ... Для этого и N выучить не западло, чем трахаться с Antlr или yacc.
И чему это противоречит? Понадобился мне калькулятор, парсер Wiki в js, для этого и N выучить не западло.
A>>Вот я например, понимаю Peg. Надо мне например, калькулятор, парсер Wiki, ... Для этого и N выучить не западло, чем трахаться с Antlr или yacc. D>И чему это противоречит? Понадобился мне калькулятор, парсер Wiki в js, для этого и N выучить не западло.
OK. Тема задумывалась как пожелания народа к Немерле Тим. Захотят реализовать сделают
Здравствуйте, alvas, Вы писали:
I>>Джаваскрипт может выполнять не только браузер. На ём и серверные приложения пишутся.
A>Это я понял.
I>>Соответственно вместо написания N-бакэндов, можно написать один транслятор.
A>А вот это нет. Поподробней пожалуйста
Не ясно, как ты понял первую часть, но не понял вторую.
Например если будет трансляция в js, то это сразу даёт возможность запустит код для той же jvm. Я сильно сумлеваюсь, что в скором будущем появится реализация немерле для jvm.
А если дать трансляцию в Си, то можно будет запускать на самых разных платформах, чего Немерле уж точно никогда не сможет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, alvas, Вы писали:
I>>>Джаваскрипт может выполнять не только браузер. На ём и серверные приложения пишутся.
A>>Это я понял.
I>>>Соответственно вместо написания N-бакэндов, можно написать один транслятор.
A>>А вот это нет. Поподробней пожалуйста
I>Не ясно, как ты понял первую часть, но не понял вторую.
I>Например если будет трансляция в js, то это сразу даёт возможность запустит код для той же jvm. Я сильно сумлеваюсь, что в скором будущем появится реализация немерле для jvm.
jvm = java virtual machine?
I>А если дать трансляцию в Си, то можно будет запускать на самых разных платформах, чего Немерле уж точно никогда не сможет.
Здравствуйте, alvas, Вы писали:
A>jvm = java virtual machine?
Да.
I>>А если дать трансляцию в Си, то можно будет запускать на самых разных платформах, чего Немерле уж точно никогда не сможет.
A>Почему?
С никогда я возможно и погорячился. В обозримом будущем не сможет. Компилить в нативный код — это вагон работы для каждой платформы. Другой вариант делать свою VM — опять вагон работы. Проще сделать транслятор в js или в Си.
Здравствуйте, alvas, Вы писали:
I>>Например если будет трансляция в js, то это сразу даёт возможность запустит код для той же jvm.
A>Дай ссылку на js для jvm
Здравствуйте, Ikemefula, Вы писали:
I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.
А можно генерировать Vala, который на выходе генерирует C + GObject
Или какое-то другое извращение вместо того, чтобы поставить mono.
Здравствуйте, Ikemefula, Вы писали:
I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.
Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си.
Другой вопрос, что LLVM оправдывает свое название и реально низкоуровневая машина. К тому же регистровая. Ее поддержка может потребовать немалых сил.
Здравствуйте, catbert, Вы писали:
C>А можно генерировать Vala, который на выходе генерирует C + GObject C>Или какое-то другое извращение вместо того, чтобы поставить mono.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, alvas, Вы писали:
A>>Здравствуйте, VladD2, Вы писали:
А>>>>тип как первоклассный. То есть разрешить передачу типа в функцию. Тогда возможен отказ от генериков. Уменьшение стадий макросов
VD>>>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.
A>>Приведи пример, пожалуйста
А>def astype(a, type){a:type}
А>так же хотелось бы получать аргументы с разделением константные или вариабельные
А>например macro power(a,b:int) А>{
А>match constant(a) А>| true // построение быстрого алгоритма А>| false // генерирование метода деления на 2 А>}
Nemerle.Compiler.Parsetree.PExpr.Literal подойдет ?
А>хотелось бы иметь возможность узнать чистая функция или нет
Здравствуйте, alvas, Вы писали:
VD>>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.
A>Приведи пример, пожалуйста
Пример чего? Макросов использующих информацию о типах? Ну, например, смотри макрос lock из стандартной библиотеки:
macro @lock (lockOnExpr, body)
syntax ("lock", "(", lockOnExpr, ")", body)
{
def typer = Macros.ImplicitCTX();
def lockOnTExpr = typer.TypeExpr(lockOnExpr);
typer.DelayMacro(lastTry =>
match (lockOnTExpr.Type.Hint)
{
| Some(Class(typeInfo, _)) when typeInfo.IsValueType =>
when (lastTry)
Message.Error (lockOnExpr.Location,
$"`$typeInfo' is not a reference type as required by the lock expression");
None()
| None =>
when (lastTry)
Message.Error (lockOnExpr.Location,
"compiler was unable to analyze type of locked object, but it "
"must verify that it is reference type");
None()
| _ =>
def result =
<[
def toLock = $(lockOnTExpr : typed);
System.Threading.Monitor.Enter(toLock);
try { $body }
finally { System.Threading.Monitor.Exit(toLock); }
]>;
Some(result)
}
);
}
А вообще, можно сделать поиск "TypeExpr" по всему каталогу макросов и посмотреть случаи его использования.
Здравствуйте, alvas, Вы писали:
A>Предлагаю в этой ветке обсудить какие возможности отсутствуют в Nemerle. A>В общем чего людям в жизни не хватает
Не то чтобы абсолютно уверен, что это очень надо:
Упаковка юзингов, иногда они бывают надоедливые. Особенно если много файлов с одинаковым набором юзингов.
В отдельном файле, может быть с другим расширением (допустим *.usings) пишется:
(для примера напихал, может не из Немерла)
usings MyUsings
{
using System
using System.Collections.Generic
using System.Data
using System.Linq
using System.Text
using System.Windows.Forms
using System.Xml.Linq
using Microsoft.Office.Tools.Excel
using Microsoft.VisualStudio.Tools.Applications.Runtime
using Excel = Microsoft.Office.Interop.Excel
using Office = Microsoft.Office.Core
}
Такие файлы считываются в первую очередь.
А потом в обычных файлах можно так: usings MyUsings
using Somthing
.....
using ....
Здравствуйте, Silver_S, Вы писали:
S_S> Не то чтобы абсолютно уверен, что это очень надо: S_S>Упаковка юзингов, иногда они бывают надоедливые. Особенно если много файлов с одинаковым набором юзингов.
S_S>В отдельном файле, может быть с другим расширением (допустим *.usings) пишется: S_S>(для примера напихал, может не из Немерла)
Здравствуйте, Ikemefula, Вы писали:
I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.
Не появится. Точнее появится очень ограниченная возможность, так как в С много чего нет. Нет GC, нет библиотек. Для ограниченной задачи это решаемо. В общем случае объем работ таков, что проще использовать Mono.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Джаваскрипт может выполнять не только браузер. На ём и серверные приложения пишутся. Соответственно вместо написания N-бакэндов, можно написать один транслятор.
Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере? Не уж то в тормозах есть своя прелесть?
Немерле и так отлично на сервере работает. А преобрзование в жабаскрипт нужно исключительно для поддержки "легких" клиентов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
C>>А можно генерировать Vala, который на выходе генерирует C + GObject C>>Или какое-то другое извращение вместо того, чтобы поставить mono.
I>Менеджед это не всегда самое лучшее решение.
Ну, да! Куда лучше интерпретация! Блин, я хренею дорогая редакция! (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си.
Вот только это ничем не проще и не быстрее.
ВВ>Другой вопрос, что LLVM оправдывает свое название и реально низкоуровневая машина. К тому же регистровая. Ее поддержка может потребовать немалых сил.
Главная проблема — это качественный GC. В прочем, у меня есть мысли по этому поводу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alvas, Вы писали:
A>>Всего лишь тупой Script#?
A>Тогда уже лучше JavaScript -> JavaScript
Не такой уж тупой. Все же будет вывод типов и многие другие вкусности (например, $-строки). Если приложить услилия, то можно в жабасктипт конвертировать и более сложный немерловый код (паттерн-матчинг, вариантные типы, классы).
Это позволило бы писать скриптовый код так же как пишется статически-типизированный (с интеллисенсом и проверками времени компиляции). Конечно будут ограничении, но это лучше чем писать все на скрипте.
Если же эту идею совместить с идеей реактивного UI, то получится очень красиво.
Запусти прототип, погляди.
Мы планируем развить этот проект и сделать дин из самых интересных веб-фрэймворков. Все кому это интересно могут присоединиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ> Они просто более тормознутые, т.к. там нет специальной поддержки рантайма. Или по крайней мере не было раньше.
Ну там не только тормознутость накладывается рантаймом, а то что на самом деле не известно какой тип у нас и рантайм позволит присвоить
List<string> ls = new List();
List ll = ls;
List<Integer> li = (List<Integer>)ll;
а потом уже в рантайме во время использования метода get(index) выдаст ошибку .
Но это так... цветочки если правильно прогать то все нормально. Но второй недостаток -- в рантайме невозможно получить параметр типа (бывает надо, ели делать, например двигло работ с БД, или еще какие хирые штуку, был проект на шарпе в котором в статическом конструкторе в зависимотсти от парметра типа генрировался динамический метод через SRE )
Здравствуйте, VladD2, Вы писали:
VD>Не появится. Точнее появится очень ограниченная возможность, так как в С много чего нет. Нет GC, нет библиотек. Для ограниченной задачи это решаемо. В общем случае объем работ таков, что проще использовать Mono.
Сишных библиотек полно, нужен только удобный интероп.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си.
Да, мне кажется, что лучше уж сделать поддержку LLVM.
А из нее можно уже и JS сделать, например, с помощью Emscripten компилятора LLVM-to-JavaScript. Разработчики Mozilla таким образом портировали Doom на JS.
Здравствуйте, VladD2, Вы писали:
ВВ>>Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си. VD>Вот только это ничем не проще и не быстрее.
Я этого и не говорил. Хотя в перспективе различные бэкенды можно поддерживать не напрямую, а через LLVM. Т.е. достаточно будет компилироваться в LLVM, а там будет и нейтив, и JVM, и проч.
ВВ>>Другой вопрос, что LLVM оправдывает свое название и реально низкоуровневая машина. К тому же регистровая. Ее поддержка может потребовать немалых сил. VD>Главная проблема — это качественный GC. В прочем, у меня есть мысли по этому поводу.
Опять же в LLVM все же есть готовая инфраструктура для интеграции GC, а в случае компиляции в Си придется вообще делать с нуля.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Опять же в LLVM все же есть готовая инфраструктура для интеграции GC, а в случае компиляции в Си придется вообще делать с нуля.
Я не против LLVM. Но возможности наличия сишного бэкэнда это не отменяет. У С есть свои преимущества. Он как минимум более переносим и компактен.
Предлагаю тебе примкнуть к проекту Н2 и реализовать LLVM-бэкэнд, раз ты такой его сторонник.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>Не появится. Точнее появится очень ограниченная возможность, так как в С много чего нет. Нет GC, нет библиотек. Для ограниченной задачи это решаемо. В общем случае объем работ таков, что проще использовать Mono.
Z>Сишных библиотек полно, нужен только удобный интероп.
Можно ли сделать чтобы когда импортируешь ком-библиотеку, то на выходе получался не бинарник Interop.Word.dll, а исходники?
Z>>Сишных библиотек полно, нужен только удобный интероп.
A>Можно ли сделать чтобы когда импортируешь ком-библиотеку, то на выходе получался не бинарник Interop.Word.dll, а исходники?
Здравствуйте, VladD2, Вы писали:
VD>Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере?
А почему Питону, Руби, Пхп можно на сервер, а джаваскрипту нельзя ?
VD>Не уж то в тормозах есть своя прелесть?
Двигло вроде V8 точно не медленнее Питона, Руби, Пхп и подобных братьев.
Даже больше — JS V8 это уже практически рантайм-компилятор, без промежуточного байт-кода.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере?
А>А почему Питону, Руби, Пхп можно на сервер, а джаваскрипту нельзя ?
Здравствуйте, alvas, Вы писали:
VD>>>Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере?
А>>А почему Питону, Руби, Пхп можно на сервер, а джаваскрипту нельзя ?
A>А кто сказал что нельзя? Спросили вроде зачем
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, alvas, Вы писали:
VD>>>>Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере?
А>>>А почему Питону, Руби, Пхп можно на сервер, а джаваскрипту нельзя ?
A>>А кто сказал что нельзя? Спросили вроде зачем
А>А зачем там Питон, Руби, Пхп и прочая братия ?
Здравствуйте, alvas, Вы писали:
А>>А зачем там Питон, Руби, Пхп и прочая братия ?
A>Не отвечайте вопросом на вопрос
Хорошо. За тем же, что и Питон, Руби, Пхп — для написания серверных приложений, так как узкое место на сервере в большинстве случаев это сеть и база данных, а не скорость работы языка. Есть много людей владеющих джаваскриптом и они способны писать серверные приложения. На немерле можно написать фреймворк что бы остальные могли использовать его из джаваскрипта.
Здравствуйте, Аноним, Вы писали:
А>А почему Питону, Руби, Пхп можно на сервер, а джаваскрипту нельзя ?
Почему нельзя? Можно, но не нужно.
А>Двигло вроде V8 точно не медленнее Питона, Руби, Пхп и подобных братьев.
Точно. Но и точно не быстрее Немерла или Скалы. Так на фиг он упал?
А>Даже больше — JS V8 это уже практически рантайм-компилятор, без промежуточного байт-кода.
А VB 6 был полным компилятором. Только вот работал все равно в 10 раз медленее С++-ного кода. Тут проблема в архитектуре. Когда объект — это хэш-таблица, как не оптимизируй, но тормозов не избежать.
Язык с выводом типов и макросами покрывает большую часть вкусностей динамики. А платить скоростью, удобством и надежностью кода за большую гибкость полиморфизма я не намерен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А>Хорошо. За тем же, что и Питон, Руби, Пхп — для написания серверных приложений, так как узкое место на сервере в большинстве случаев это сеть и база данных, а не скорость работы языка.
Эту сказку ты расскажи тем кто разные Фэйсбуки спешно перекомпилировал в С с ПХП.
В ПХП или Жабаскрипте нет ничего что давало бы какие-то приемущества. Первый выбирают разные начинающий по тому как много нароботок вроде форумов или гостевых страниц. А второй вмонтирован во все броузеры, так что стал стандартом де факто в Интеренете. Но это не преимущества языка. Это большая известность. Но от того, что прост хозяйственное мыло не рекламмируют в праймтайме он не начинает хуже мыть.
А>Есть много людей владеющих джаваскриптом и они способны писать серверные приложения. На немерле можно написать фреймворк что бы остальные могли использовать его из джаваскрипта.
Лучше сделать наоборот. Сделать фрэймворк который позволил бы не писать на жабаскрипте, но получать его по статически-типизированному немерлу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alvas, Вы писали:
A>А вот молодой но перспективный N или Ela -> js A>Как вы думаете народ будет изучать йет эназэ язык чтобы от генерировал сорцы js? Вот и я сомневаюсь
Будет если четко будет понимать, что это ему даст значительный выигрыш. А если выигрыша не будет или он будет незначительным, то в этом просто нет смысла.
Именно по этому нет смысла делать просто конвертер из Х в У. Надо делать полноценное решение которое позволило бы резко упростить создание сложных веб-сайтов. Вот это будет по любому востребовано.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alvas, Вы писали:
A>Можно ли сделать чтобы когда импортируешь ком-библиотеку, то на выходе получался не бинарник Interop.Word.dll, а исходники?
Сделать можно все.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alvas, Вы писали:
A>>Можно ли сделать чтобы когда импортируешь ком-библиотеку, то на выходе получался не бинарник Interop.Word.dll, а исходники?
VD>Сделать можно все.
Разработчик Kevin Gaad, который судя по его профилю работает в компании Mozilla, представил свою разработку – компилятор .NET(C#) кода в JavaScript. Для демонстрации работоспособности библиотеки Кевин опубликовал портированный пример демонстрационного проекта игры на базе XNA 3.1.
