Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hardcase, Вы писали:
H>>Здравствуйте, gandjustas, Вы писали:
G>>>Вместо оператора using можно сделать функцию using, что гораздо проще. В ленивом языке вообще любую конструкцию можно функцией выразить.
H>>Вырази конструкцию создания экземпляра анонимного типа ленивой функцией.
G>А что сразу определение функции не спросил?
Если функцию для using или lock я понимаю, то ответ на вопрос про определение типов в функциях в условиях статической типизации для меня не очевиден. Пример в студию!
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mystic, Вы писали:
M>>А много ли таких фичей? Лично я метапрограммирование больше применял для описания некоторых данных, которые потом переводились в разные таблицы.
VD>Какие проблемы, такие и решения. Но есть и общие для разных предметных областей фишки. Скажем автоматизация паттернов ООП.
Смотря каких паттернов. В общем случае, мне кажется, игра не стоит свеч: на изучение более абстрактной настройки понадобится время, а используется раз в год, два раза на пасху.
Re[5]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, VladD2, Вы писали:
FR>>Ну в них (кроме лиспа) как и в Smalltalk или в D легкий вариант
VD>Легкий? Этого легкого варианта хватило на Рельсы и еще осталось! Он не легкий, он тормозной. А это не одно и тоже .
По сравнению с полноценными макросами конечно легкий.
Ну и для меня его такого и хватает вполне.
VD>Ну, камловский препроцессор штука весьма огнаниченная. Плюс и ОКамл и Хаскель распространены чуть больше чем немерле, то есть чуть больше чем никак. А их расширения еще меньше. Может по этому и не востребованы?
Ну все-таки распространены они все-таки намного шире, да и поверхностное знакомство с ними есть у гораздо большего числа программистов из-за ВУЗов.
Но я имел в виду что в мейнстрим так и не прошли даже такие.
FR>>Тот же Dylan этого недостатка не имел.
VD>Я не знаком с Dylan. Думаю, что у него своих тараканов хватало. Это интерпретатор?
По сути Common Lisp с паскалевым синтаксисом, компилятор, язык динамический с опциональной поддержкой типизации:
define function absolute-value(x :: <integer>)
=> (result :: <integer>)
if (x >= 0)
x;
else
-x;
end;
end;
Здравствуйте, Sinix, Вы писали:
S>Потому что если озадачиться 100% совместимостью (в том числе и обратной), там работы явно не на 2 человекомесяца. Навскидку:
Это верно
S>- dynamic (если будет использоваться родной биндер шарпа — придётся всё-таки полноценно имитировать вывод перегрузок), иначе поведение в рантайме начнёт отличаться от compile-time.
Сделать можно, даже аналог в языке есть (ага, макрос), но пока не нужно.
S>- expression trees.
Они есть, догадайся на чем реализованы
S>возможность использования запятой после последнего элемента enum-а/инициализатора, неоднозначность со скобками в object initializer.
Это фичи парсера, так что мимо.
S>- и даже вот такие баги компилятора.
Такая хреновина действительно бесполезна. Какому бишь проценту пользователей она нужна?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[8]: Способно ли метапрограммирование заменить отдельные я
VD>C++ Builder, конечно, тоже дерьмо еще то. Но уж позволь не поверить.
Это ты просто с билдером не работал
FR>>Правда я IDE для OCaml'а на самом деле не использую, надобности нет,
VD>Потому и не используешь, что качество такое у нее.
Нет не из-за этого, просто и проекты маленькие и сам язык железобетонный, отладки не требует
FR>>но блин подсел на тот же Eclipse(PyDev) с питоном.
VD>Что подтверждает мои слова.
Даже если бы OCaIDE был бы по возможностям близок к PyDev больших преимуществ это не принесло бы.
Re: Способно ли метапрограммирование заменить отдельные язык
Здравствуйте, Chrome, Вы писали:
C>Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку.
Почему ты все метапрограммирование сводишь к подключаемой грамматике? Это более широкое понятие, охватывающее гораздо больший спектр техник, чем одни только подключаемые грамматики. Те же шаблоны в С++, перегрузка операторов в куче языков, текстовые макросы в Си — это все не подключаемые грамматики, но это вполне себе метапрограммирование.
Метапрограммирование — это, фактически, кодогенерация, в том или ином виде. В случае сишных макросов это прямая текстовая кодогенерация, в более продвинутых случаях — кодогенерация прямо в представлении компилятора, но все равно это она и есть.
Насчет заменить отдельные языки — смотря какие языки ты имеешь в виду. Если языки, которые используются для внешней кодогенерации — то да, способно, до определенного предела. Но, опять же, оно заменить эти языки только в этой крайне узкой нише. Если универсальные языки, особенно нативные — так они обычно подразумевают бэкэнд, обычно несовместимый. Т.е. распарсить-то ты может и распарсишь сишный код на немерле, только вот что это тебе даст, когда нет указателей и прочего...
Здравствуйте, VladD2, Вы писали:
FR>>Ну есть еще term rewriting,
VD>Это как раз плевая задача. Видимо ты все же имеешь в виду что-то другое.
Так я же ниже прямо написал (выделил), элементарный очень легко чуть сложнее все, тем более Pure гораздо сложнее пролога.
FR>>если элементарный пролог совсем не сложно, то его же эффективно работающий или например тот же Pure очень сложно и на этом фоне разбор синтаксиса и т. п. исчезающе малая величина.
VD>А причем тут Пролог? В прологе основная сложность — это унификация и рекурсивный поиск с бэктрекингом. Этот механизм так же можно предоставить в виде библиотеки. И только от ее авторов будет зависеть качество ее реализации.
Вот качественная и потребует столько трудозатрат что хоть ты ее макросом оформи хоть как отдельный язык с написанным на си парсером на этом фоне одинаково
VD>Я как раз прикидывал. В принципе можно сделать и очень универсальное решение. Потуги уже в общем-то были даже. Тут кто-то на лиспе подобное дело делал.
VD>Ну, да даже фрэймворк позволяющий создавать и развивать статически-типизированные гибридные языки с энергичной семантикой дал бы уже не малый просто для фантазии. Ведь в этот класс языков входят не только C# и Немерле, а еще F#, OKaml, Дельфи, Васик и многие другие. Это по сути все языки дотнета. Почему не пойти дальше и не сделать не толко бэкэнд (дотнет) общими, но и мидл-энд, и фронт-энд?
Вот и все, а появится завтра суперрефал?
Эх вспоминаю как писал надцать лет назад еще студентом на Форте универсальный баскенд для всех языков, даже успел минимальный паскаль реализовать до того как забросил
FR>>В принципе все реализуемо даже на языке шаблонов C++
VD>Не. Слишком сложно.
Ну я же в шутку.
VD>Ты просто не писал настоящих компиляторов. Затраты на разработку языка очень высоки! Чем качественнее хочется получить результат, тем сложнее задача.
VD>Языки с паттерн-матчингом и ФВП немного упрощают задачу, но не существенно.
Ну тот же dmz показал что не очень и высоки для простого языка. Тем более если back end LLVM или NEТ.
VD>А сложных уж и подавно. Попробуй ради хохмы создать компилятор C#-а хотя бы за в десять раз большее время, а я посмеюсь.
Ну это не спортивно, напиши на немерле компилятор C++
Ну и я речь веду про простые языки, так как сложные на макросах тоже запросто не реализуешь.
Re[4]: Способно ли метапрограммирование заменить отдельные я
using Nemerle.Collections;
using Nemerle.Utility;
using Nemerle.Text;
using Nemerle.WPF;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Windows.Controls;
using System.Windows;
using System.Console;
public class MyStateControl : Button
{
public this() { base() }
[DependencyProperty(Metadata = FrameworkPropertyMetadata("a", (_, _) => { }, (_, b) => b))]
public DependencyProperty1 : string { get { } set { } }
[DependencyProperty(IsReadOnly)]
internal DependencyProperty2 : string { get { } set { } }
[DependencyProperty(IsReadOnly, ValidateCallback = value => value > 0, Metadata = PropertyMetadata((_, _) => { }))]
public static GetDependencyProperty3(_ : DependencyObject) : int;
[DependencyProperty]
public static GetDependencyProperty4(item : DependencyObject) : int;
}
module Program
{
[STAThread]
Main() : void
{
try
{
def control = MyStateControl();
control.DependencyProperty1 = control.DependencyProperty1 + control.DependencyProperty2;
def x = MyStateControl.GetDependencyProperty3(control);
def y = MyStateControl.GetDependencyProperty4(control);
MyStateControl.SetDependencyProperty4(control, x + y);
}
catch
{
| e => WriteLine(e.ToString());
}
}
}
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Не знаю как у вас, а в F# coputational expressions рассахариваются именно в вызовы функций. WH>Ну так ты тот ужос в который оно переписывается видел? WH>Проблема ведь не в том что бы что-то во что-то переписать, а в том что бы это было красиво.
Это уже ты придумал про "красиво".
G>>Ашо это за еврейские замашки сразу на производительность съезжать? G>>Или ты хочешь сказать что аналогичная производительность доступна только на Nemerle? WH>Она доступна только макросам. Ибо там идет очень жестокое переписывание кода для того чтобы это все работало быстро. WH>Ну и без статической типизации никуда. WH>И как следствее остается один немерле.
А кто мешает в рантайме переписывать?
Чето у немерелистов уже настолько взгляд затуманен, что они вообзе плохо видят возможности за пределми того что есть в nemerle.
Re[7]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, VladD2, Вы писали:
VD>Ты просто не писал настоящих компиляторов. Затраты на разработку языка очень высоки! Чем качественнее хочется получить результат, тем сложнее задача.
VD>Языки с паттерн-матчингом и ФВП немного упрощают задачу, но не существенно.
Можно привести такой пример: существуют довольно интересные языки программирования Haxe и Boo. Они во многом похожи, например, строгой статической типизацией и выводом типов. Первый язык реализован преимущественно на OCaml, второй — на C#.
Реализация системы типов в Boo, написанном на C#, занимает более семнадцати тысяч строк кода (более половины мегабайта кода на высокоуровневом языке), размещающихся в ста двадцати двух файлах. При этом представлявший наибольший интерес алгоритм вывода типов надежно декомпозирован на слои и «шаблоны проектирования» и код, который его реализует является вполне идиоматичным для этого класса языков. Задача идентифицировать основной код алгоритма и понять его не выглядела решаемой за разумное время и была оставлена.
Ни одной понятной реализации системы типов и алгоритма выведения на императивных языках найдено не было (были рассмотрены варианты на C#, С++ и даже Perl).
Реализация системы типов в языке Haxe, занимает 4088 строк (127624 байт кода) на OCaml и размещается в трех файлах, при этом интересующий алгоритм идентифицируется сразу же и представляет собой, в основном, свертку списков с применением сопоставления с образцом. Прочитать и понять его было достаточно легко, несмотря на то, что на тот момент опыт разработки и чтения кода, написанного на императивных языках, сильно превосходил аналогичный опыт для функциональных.
Даже со всеми возможными оговорками разница в функциональности систем типов Boo и Haxe гораздо меньше, чем разница в количестве кода, эту функциональность реализующего: 100072 строки (2955595 байт) кода текущей реализации Boo убивали всякую надежду, что подобный проект может вообще быть реализован самостоятельно.
Для сравнения, текущие значения для Бипа: 2592 строки (109780 байт) кода, а время, затраченное на реализацию вместе с рантаймом, не превышает трех человеко-месяцев. Это маленький проект, и сделать его маленьким помог именно выбор OCaml в качестве языка разработки.
Re[3]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, gandjustas, Вы писали:
H>>Вырази конструкцию создания экземпляра анонимного типа ленивой функцией.
G>А что сразу определение функции не спросил?
Ны ты крут! Я еще не видел, чтобы люди сами намеренно участвовали в дискредитации своих же утверждений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, gandjustas, Вы писали:
G>Не знаю как у вас, а в F# coputational expressions рассахариваются именно в вызовы функций.
Ну, дык за чем дело стало? Напиши аналог на C#. Ты же крут!
WH>>>>Ну иди попробуй выразить Nemerle.Peg средствами языка. G>>>Какого языка? WH>>Любого. Только макросы не используй. WH>>Только давай без халтуры. Чтобы производительность была на уровне. G>Ашо это за еврейские замашки сразу на производительность съезжать?
Что опять слил?
G>Или ты хочешь сказать что аналогичная производительность доступна только на Nemerle?
Он хотел сказать, что на макросах можно реализовать как хочешь, в том числе и очень эффективно. А вот когда у тебя нет таких средств, то делают как получится. И обычно получается некрасиво и медленно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, gandjustas, Вы писали:
G>>>Вот только ты не учел что язык — не только способ передачи информации от программиста компьютеру, но и способ передачи информации между программистами. G>>>Вот изменяемая грамматика этому крайне не способствует.
IT>>Откуда такие сведения? Есть конкретный опыт или это всего-лишь измышлизмы?
G>Отлично можно наблюдать при переходе C#2 -> C#3.
А в котором из них изменяемая грамматика?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, gandjustas, Вы писали:
G>Это уже ты придумал про "красиво".
Ну так мы тут не про полноту по Тьюрингу говорим.
G>А кто мешает в рантайме переписывать?
И машинный код сгенерировать,... и получишь ты макросы немерла вид в профиль.
G>Чето у немерелистов уже настолько взгляд затуманен, что они вообзе плохо видят возможности за пределми того что есть в nemerle.
Я вижу все лучше чем ты.
Я прекрасно знаю что можно сделать и что нельзя.
Но в отличии от тебя я прекрасно понимаю что как ни крутись, а для того чтобы получить аналогичное по краткости и производительности решения понадобится механизм похожий на макросы немерла.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, FR, Вы писали:
FR>Это ты просто с билдером не работал
Довелось на его заре. Функционально на тот момент он был ничего. Но глючил страшно. В прочем, все IDE для С++ тогда работали кое-как. В итоге, правда, перешли на VS 6. Там интелисенса почти не было, но редакторо хороший, компилятор приличный... посталиви Томату и забыли про билдер.
VD>>Потому и не используешь, что качество такое у нее.
FR>Нет не из-за этого, просто и проекты маленькие и сам язык железобетонный, отладки не требует
Первое — возможно. Второе — сказки. В IDE отладка не главное. В ней главное возможность контролировать код (типы, ошибки). Для явзыка с выводом типов это очень важно.
FR>Даже если бы OCaIDE был бы по возможностям близок к PyDev больших преимуществ это не принесло бы.
Какая разница как называется IDE? Главное, что она ускоряет работу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, FR, Вы писали:
FR>По сравнению с полноценными макросами конечно легкий.
Полноценные макросы могут быть очень легкими в применении.
FR>Ну и для меня его такого и хватает вполне.
Тем более!
VD>>Ну, камловский препроцессор штука весьма огнаниченная. Плюс и ОКамл и Хаскель распространены чуть больше чем немерле, то есть чуть больше чем никак. А их расширения еще меньше. Может по этому и не востребованы?
FR>Ну все-таки распространены они все-таки намного шире, да и поверхностное знакомство с ними есть у гораздо большего числа программистов из-за ВУЗов.
Программисты из ВУЗ-ов звучит очень смешно. Не находишь?
FR>Но я имел в виду что в мейнстрим так и не прошли даже такие.
Дык, а как они пройдут то когда сами базовые языки (без мета-расширений) в мэйстрим попасть не могут.
FR>По сути Common Lisp с паскалевым синтаксисом, компилятор, язык динамический с опциональной поддержкой типизации:
Ну, а что ты хочешь? Динамика да еще и лиспоподобная. Хотя выглдяит все же по проще чем Лисп.
FR>Там вообще много чего наворочено вплоть до минимальной поддержки зависимых типов http://www.opendylan.org/fragments/limited-types.phtml
Интересно...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, Mystic, Вы писали:
M>Смотря каких паттернов. В общем случае, мне кажется, игра не стоит свеч: на изучение более абстрактной настройки понадобится время, а используется раз в год, два раза на пасху.
Ключевое слово здесь — "кажется".
Паттерны заполоняют код обычных ОО-проектов. Инкапсуляция их в языковые конструкции позволяет сделать код во много раз чище и проще. Одно это упрощает разработку сложных проектов. А мы еще и не заикались о ДСЛ-ях...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Способно ли метапрограммирование заменить отдельные я
Здравствуйте, jazzer, Вы писали:
J>Почему ты все метапрограммирование сводишь к подключаемой грамматике? Это более широкое понятие, охватывающее гораздо больший спектр техник, чем одни только подключаемые грамматики. Те же шаблоны в С++, перегрузка операторов в куче языков, текстовые макросы в Си — это все не подключаемые грамматики, но это вполне себе метапрограммирование.
J>Метапрограммирование — это, фактически, кодогенерация, в том или ином виде. В случае сишных макросов это прямая текстовая кодогенерация, в более продвинутых случаях — кодогенерация прямо в представлении компилятора, но все равно это она и есть.
+1
J>Насчет заменить отдельные языки — смотря какие языки ты имеешь в виду. Если языки, которые используются для внешней кодогенерации — то да, способно, до определенного предела. Но, опять же, оно заменить эти языки только в этой крайне узкой нише.
Это очень узкий взгляд на проблему. На самом деле при наличии качественного и прсотого в использовании МП, да еще и с легко изменяемым синтаксисом становится доступна новая парадигма — языко-ориентированное программирование. Когда прикладаная задача описывается на ДСЛ-е, а макросы (или что-то их заменяющее) обеспечивают реализацию этого ДСЛ-я (создание компилятора или интерпретатора).
J>Если универсальные языки, особенно нативные — так они обычно подразумевают бэкэнд, обычно несовместимый. Т.е. распарсить-то ты может и распарсишь сишный код на немерле, только вот что это тебе даст, когда нет указателей и прочего...
Дык если говорить о эдаком языковом фрэймворке, то под копотом у него могут быть и указатели и все что угодно. Скажем в Н1 (немерле 1.0) нет операторов goto. Но тем не менее при реализации C#-а поверх немерла мы таки реализовали этот самый goto. И в Nemerle.Peg goto для оптимизации (в релизе) используется. Это возможно потому, что goto как примитив присутствует в типизированном АСТ. И макросы могут его использовать. Точно так же может быть с указателями. Так что воспроизвести С++ на немерле очень даже можно. Вопрос только в объеме работы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.