Re[34]: Снова о Nemerle или профанация не пройдет :)
От: WolfHound  
Дата: 21.02.06 15:07
Оценка: +3
Здравствуйте, Oyster, Вы писали:

O>То вот такой код не прокатит:

O>
O>Company1.printer --> 25
O>Company2.printer --> 25
O>

Вобщем разработчикам надо написать чтобы такой вариант прокатывал.
Ну чтобы еще и такой прокатывал
using c1 = Company1;
using c2 = Company2;
c1.printer --> 25
c2.printer --> 25

Тогда и проблемы не будет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 21.02.06 15:16
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Офф-топ: Кстати, обычно под словом "птичий" понимают не язык с гибким синтаксисом, а язык с кучей "птичек" и прочих значков в противовес словам. Значение таких значков невозможно понять, а можно только запомнить. Яркий представитель таких языков — перл.


Совершенно верно.
Re[35]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 21.02.06 15:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тогда и проблемы не будет.


Да. Чего-то подобного надо, наверное. Если тут подводных камней нету, конечно...
Re[36]: Снова о Nemerle или профанация не пройдет :)
От: WolfHound  
Дата: 21.02.06 15:20
Оценка:
Здравствуйте, Oyster, Вы писали:

WH>>Тогда и проблемы не будет.

O>Да. Чего-то подобного надо, наверное. Если тут подводных камней нету, конечно...
Не вижу.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Снова о Nemerle или профанация не пройдет :)
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 21.02.06 15:30
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>К примеру, согласить круто вместо:

VD>
VD>string.Formar("Имя: {0} Фамилия: {0}", name, lastname)
VD>

VD>писать:
VD>
VD>$"Имя: $name Фамилия: $lastname", 
VD>

VD>Причем ошибиться нигде нельзя! Если ты впишешь неверное имя переменной в текст, то тебя остановит компилятор! А в C# ты рискушь получить ошибку во время выполнения (неверный форма или еще что).

Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет. Он всего лишь делает запись короче и не позволяет ошибиться с циферками в скобочках. Всё. После его прохода у компилятора оказывается примерно вот что:.
// До
def a = 5; 
$"var a has value $a, blah-blah-blah";

// После
def a = 5;
def tmp = StringBuilder("var a has value ");
tmp.Append(a.ToString());
tmp.Append(", blah-blah-blah");
tmp.ToString();
--
Re[18]: Снова о Nemerle или профанация не пройдет :)
От: Vermicious Knid  
Дата: 21.02.06 15:40
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет.


Зато спасут макросы из Nemerle.IO: printf, sprintf и fprintf. Естественно эти макросы лишены недостатков своих сишных аналогов. А еще к своему удивлению я только что обнаружил scanf и иже с ним.

Вообще не знаю как для production кода, но для тестовых приложений эти макросы незаменимы.
Re[24]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 21.02.06 17:22
Оценка: 26 (3)
Здравствуйте, eao197, Вы писали:

E>Может не нужно сразу сложную, а проще что-нибудь, знакомое публике? Например, вот эта задача
Автор: AndrewVK
Дата: 13.07.05
.


E>Причем интересно как с парсингом XML-я (может быть даже в compile-time), так и создание специализированного DSL на макросах специально для этой задачи.


В общем, я решил попробовать написать такой макрос. Сильно не пинать — первый опыт, можно сказать.

Макрос генерит класс в compile-time в соответствии с постановкой задачи. Конструктор вот только пока что не создаётся (уже домой бежать надо — завтра, надеюсь...). Используется макрос вот так:

using Oyster;

metaclass TestClass {
    prop1 : int;
    prop2 : string
}

Код макроса (повторяю — писать на Nemerle я пока не умею, так что сильно не ругайте):

using Nemerle.Collections;

namespace Oyster
{
    macro metaclass(className, body)
    syntax ("metaclass", className, body)
    {
        // Тут я зачем-то вытаскиваю идентификатор, а потом его снова вставляю в AST.
        // Криво (?), но как иначе - не знаю
        def className = match (className) { | <[ $(x : name) ]> => x };
        
        // Разбираем "свойства"
        def props = match (body) {
            | <[ { .. $props } ]> => List.Map(props, fun(prop) { | <[ $(n : name) : $(t : name) ]> => (n, t) })
            | _ => []
        };
        
        // http://nemerle.org/Defining_types_from_inside_macros
        def ctx = Nemerle.Macros.ImplicitCTX();
        def builder = ctx.Env.Define(<[ decl: public class $(className : name) {} ]>);
        
        // Добавляем поля для начала.
        // Если я тут ничего не верну, то компилятор чего-то на меня обидится :(
        List.ForAll(props, fun(n, t) { builder.Define(<[ decl: mutable $(n.NewName("_" + n.Id) : name) : $(t : name) ; ]>); true });
        
        // Добавляем свойства
        List.ForAll(props, fun(n, t) {
            builder.Define(
                <[ decl:
                    public $(n.NewName(n.Id.Substring(0, 1).ToUpper() + n.Id.Substring(1)) : name) : $(t : name)
                    {
                        get { $(n.NewName("_" + n.Id) : name) }
                    };
                ]>);
            true });
            
        // Добавляем конструктор
        // TODO

        builder.Compile();
        <[ () ]>
    }
}
Re[7]: Снова о Nemerle или профанация не пройдет :)
От: WinniePoh  
Дата: 21.02.06 17:42
Оценка: :))
Здравствуйте, IT, Вы писали:

WP>> Программист обязан знать все парадигмы и по одному или лучше по два языка из каждой парадигмы. Иначе не программист он, а кодер. Лабух.


IT>Знать всё невозможно.


Вы меня пугаете. Какое такое всё? Это за пару семестров вдалбливается тривиально. А если человек уже отучился, мозги натренировал, то за пару месяцев.

IT> К сожалению. На это просто не хватит времени.


Время надо было раньше тратить. Когда оно было.

IT> Хотя нет, всё же знать очень много можно, если только тем и заниматься, что постоянно изучать всё новое. Но тогда не останется времени на работу. Если же только и делать что работать, то не будешь ничего знать. Как обычно руль посередине


Как уже тут обсуждалось, работающий студент — пропавший для общества студент. Отработанный материал. Социальный труп...

WP>> Легко: ADT, pattern matching, list comprehensions, annotations (уже есть в примитивном виде — контракты, но грядёт скоро вообще полная щастя), Pi calculus (в свете XBox360 и Cell — мегаактуально, так что скоро всем индусам придётся эту математику изучать), ну и всенародно любимые DSL-и, конечно же. Они и так внедрены, но пока народ не знает, как это называется, и формальными методами не владеет. Скоро завладеют.


IT>Многое из этого уже есть и давно широко используется, кое что появляется (в том же Nemerle) и будет скоро широко использоваться. Но всё это мелочи (кроме пожалуй DSL), техники, на технологии и парадигмы никак не тянут. Мир они не перевернут и даже особенного шороха не наделают.


Перевернут. Всё это вместе убьёт индусов. Кодирование станет настолько простым и автоматизируемым делом, что недоучки из программирования вылетят, улицы подметать пойдут или бигмаками торговать. И это будет радость великая!
Re[17]: Снова о Nemerle или профанация не пройдет :)
От: Programmierer AG  
Дата: 21.02.06 18:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>После этого я понял, что придумать язык типа С++ еще тяжелее, чем реализовать.

+1
А реализовать его практически невозможно.
Можно посмотреть на это с точки зрения проблемы представления знаний. Стандарт насчитывает порядка 700 страниц на английском языке. Воды, понятное дело, в стандарте нет. Даже у экспертов C++ случаются разночтения по поводу некоторых сложных моментов. При этом весь этот объем знаний должен быть отражен в компиляторе, на языке, значительно менее выразительном по сравнению с английским — на C.
Неудивительно, что по хорошему соответствующий стандарту компилятор в природе существует только один (Comeau), да и ему веры нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Снова о Nemerle или профанация не пройдет :)
От: Воронков Василий Россия  
Дата: 21.02.06 18:34
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


Ни фига бы не упростило. Если ты единственный чувак на проекте, который может что-то поправить, то твоя ценность как специалиста сильно увеличивается
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[25]: Снова о Nemerle или профанация не пройдет :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.02.06 18:44
Оценка:
Здравствуйте, Oyster, Вы писали:

O>В общем, я решил попробовать написать такой макрос.


Интересно получилось.

Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится. Вспоминаются слова классика
Автор: c-smile
Дата: 21.02.06
:

То что технически грамотно должно быть как минимум красиво.



O>
O>using Oyster;

O>metaclass TestClass {
O>    prop1 : int;
O>    prop2 : string
O>}
O>


Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Снова о Nemerle или профанация не пройдет :)
От: Vermicious Knid  
Дата: 21.02.06 19:03
Оценка: 25 (2)
Здравствуйте, Oyster, Вы писали:

O>В общем, я решил попробовать написать такой макрос. Сильно не пинать — первый опыт, можно сказать.


Очень неплохо для первого опыта. Хотя и не без ляпов конечно. Сразу становится понятно, что Nemerle достаточно простой в освоении язык.

O>Конструктор вот только пока что не создаётся (уже домой бежать надо — завтра, надеюсь...).


С конструктором вообще и параметрами функций там все не так просто. В общем я добавил создание конструктора и упростил/улучшил некоторые моменты. Вот пример того, как это все работает:
using Oyster;
using Nemerle.IO;

metaclass zuper
{
    test : int;
    anotherProperty : string;
}

def z = zuper(1, "crazy test");
printf("%d %s\n", z.Test, z.AnotherProperty);


Вот улучшенный код(комментировать было лень, да и код в общем недалеко ушел):
using Nemerle.Collections;
using Nemerle.Macros;
using PT = Nemerle.Compiler.Parsetree;

namespace Oyster
{
    macro metaclass(className, body)
    syntax ("metaclass", className, body)
    {
        def props = match (body) {
            | <[ { .. $props } ]> =>
                props.Map(fun(_) { | <[ $(n : name) : $(t : name) ]> => (n, t) })
            | _ => []
        };
                
        def ctx = ImplicitCTX();
        def builder = ctx.Env.Define(<[ decl: public class $(className.ToString() : usesite) {} ]>);

        mutable constrParams = [] : list[PT.Fun_parm];
        mutable constrCode = [] : list[PT.PExpr];

        foreach((n, t) in props)
        {
            def prop = n.NewName("_" + n.Id);
            def accessor = n.NewName(n.Id.Substring(0, 1).ToUpper() + n.Id.Substring(1));
            builder.Define(<[ decl: mutable $(prop : name) : $(t : name) ; ]>);
            builder.Define(
                <[ decl:
                    public $(accessor : name) : $(t : name)
                    {
                        get { $(prop : name) }
                    };
                ]>);
            def paramType = ctx.BindType(<[ $(t : name) ]>);

            constrParams = <[ parameter: $(n : name) : $(paramType : typed) ]> :: constrParams;
            constrCode = <[ this.$(prop : name) = $(n : name); ]> :: constrCode;
        }
        builder.Define(
            <[ decl:
                public this(.. $(constrParams.Reverse())) { .. $constrCode }
            ]>);
        builder.Compile();
        <[ () ]>
    }
}
Re[20]: Снова о Nemerle или профанация не пройдет :)
От: Воронков Василий Россия  
Дата: 21.02.06 19:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так что тебе нужно заменить твой ХМЛ на нечто более выразительное. Ты и сам это пыташся сделать делая визуальные средства редактирования ХМЛ-ей для своих ДСЛ-ей.


Ей-богу это уже религия какая-то. Честно говоря, не вижу особой разницы между:

<EntityName Attribute1="" Attribute2="" />


и

EntityName
{
    Attribute1="";
    Attribute2="";
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Снова о Nemerle или профанация не пройдет :)
От: Воронков Василий Россия  
Дата: 21.02.06 19:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>3. ХСЛТ не полноценный ЯП и если что-то нужно посчитать и т.п., то прийдется делат вставке на другом ЯП, что усложняет процесс.


А XSLT + XPath?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Снова о Nemerle или профанация не пройдет :)
От: Vermicious Knid  
Дата: 21.02.06 20:14
Оценка: 7 (2) +1
E>Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится.

Ну во-первых нет "правильной" подсветки синтаксиса. А во-вторых мне многое в том коде показалось не совсем "красивым", просто потому что человек писал такое впервые. Посмотри лучше мой вариант его кода. А чтобы окончательно не путаться — почитай лучше документацию. Вообще Nemerle как язык это лучше, чем Nemerle как компилятор и библиотека. И первое, и второе на мой взгляд оставляют желать лучшего. И это не в последнюю очередь сказывается на коде. К сожалению я не застал первый компилятор C++, CFront(я в начале восьмидесятых только родился ), но думаю что он был тоже не самого хорошего качества. Если бы он предоставлял коду доступ к своим внутренностям, то я думаю повеситься можно было бы, т.к. ничего приличного написать бы не удалось.

E>

E>То что технически грамотно должно быть как минимум красиво.


Самого "классика"(c-smile) я уважаю, а вот эти его слова не очень. Тогда можно и шаблоны C++ считать технически неграмотными(да и любого неподготовленного к такому зрелищу человека от них просто выворачивает). Да и красота вещь весьма относительная, ни у кого нет единого взгляда на этот вопрос. Вот "классик" считает Форт эталоном красивости и технической грамотности, а по мне так это доисторический мусор и ужасно некрасивый.

Правда на Форте я не писал. Но пробовал писать на его "последователях" — Postscript и Joy, особенно на Postscript. Оба эти языка более высокоуровневые чем Форт, но программирование на них это весьма специфическое занятие, чем-то похожее на программирование на ассемблере. Я вообще ради развлечения люблю попрограммировать на самых разных языках, но за деньги я бы не стал касаться ни одного из вышеперечисленных языков, собственное время дороже.

А вообще "классику" следовало бы поближе познакомиться с Lisp, а еще лучше Rebol, он имхо покрасивее будет. Но все это не имеет никакого отношения к Nemerle. И вот почему.

В Nemerle все усилия приложены к тому, чтобы скомпилировался только такой макрос, который хотя бы генерирует синтаксически и семантически правильный код. Отсюда куча необходимых преобразований кода, явные указания типа для фрагментов AST итд. Все для того, чтобы компилятору не пришлось затрачивать дополнительное время на парсинг и валидацию кода во время исполнения макроса, ведь они могут исполняются по ходу компиляции тысячи, а то и десятки тысяч раз. Конечно можно было "красиво" и по простому — макрос работает как текстуальный. Только вот никаких приличных сообщений об ошибке он вывести не сможет, вывести типы выражений не сможет, в половине случаев будет выдавать абсолютно некорректный код(и выяснить это можно будет только на этапе компиляции самой программы, а не макроса) и все это дело при таком количество встроенных макросов как в Nemerle будет жутко тормозить.

Я больше скажу — не такая уж проблема полностью текстуально генерировать код в Nemerle, а затем парсить его(благо компилятор под боком, может и твиков в его код не придется делать) Тогда код который привел Oyster сократиться раза в два, а его надежность в три.

E>Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?


Хороший вопрос. В Nemerle встроенная поддержка xml документации как и в C#. Я думаю простейшую информацию о сгенерированном типе он в xml скорее всего выводит. С xml комментариями наверное будет проблема, т.к. разработчики об этом даже не думали. Но я внимательно посмотрел исходники компилятора и с ходу придумал как это можно добавить. Так что технически это не проблема.
Re[26]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 21.02.06 20:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Интересно получилось.


E>Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится. Вспоминаются слова классика
Автор: c-smile
Дата: 21.02.06
:

E>

E>То что технически грамотно должно быть как минимум красиво.

E>

Ты прав — о вкусах не спорят. Ну а к <[ и ]> можно привыкнуть — не сильно страшнее скобочек в шаблонах C++. Потом, ты же привык к тому, что надо писать "> > >", а не ">>>", например. Зато оцени, как красиво и элегантно описывается кусок AST — фактически ты пишешь код на Nemerle, только внутри этих самых скобочек. А возможности какие — такое шаблонам и не снилось!

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

  1. Это был мой второй макрос на Nemerle. Первый считал факториал в compile-time, и писал я его тоже около часа
  2. У меня нет никакого опыта функционального программирования — разве что читал на RSDN — поэтому паттерн-матчинг, вывод типов, туплы и списки я юзал чисто интуитивно и прыгая по граблям.
  3. Большую часть времени заняло чтение онлайн-документации и сборок рефлектором, а не написание собственно кода.

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

Вообще у меня впечатления от кодинга остались самые что ни на есть положительные — чувствуется мощь, элегантность и простота чуть ли не в каждой строчке (может и переборщил чуток, но мощь точно). Даже страшно себе представить, как бы выглядел такой код на Reflection.Emit. Точнее, даже представлять не хочется

E>Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?


Да ты просто задокументируй сам макрос — делов то. Всё равно дока будет автоматом сгенерирована и полезной информации в ней будет мало. Мне, кстати, генерация в compile-time гораздо больше нравится — нет никакой возни с поддержкой кода, сгенерированного в precompile-time (класть/не класть в VSS/CVS/SVN, как следить за тем, чтобы никто ничего не модифицировал и т.д.).

Ну а вообще меня в этой связи интересует другой интересный вопрос — а можно ли как-то из куска AST получить код на Nemerle? Типа "распечатать" AST. По идее, даже если стандартная библиотека такой фичи не содержит, это получится дописать самому. Тогда можно в макросе не делать класс, а строить AST класса и выводить его в файл или что-то вроде того. И автокомментарии можно добавить (тут бы не помешало, если бы AST содержал ноды комментариев ).
Re[18]: Снова о Nemerle или профанация не пройдет :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.06 21:02
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:


СТ>Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет. Он всего лишь делает запись короче и не позволяет ошибиться с циферками в скобочках. Всё. После его прохода у компилятора оказывается примерно вот что:.


Как же не спасет, если формата просто нет?! Ты подставляешь имена переменных которые контролируются в во время компиляции. Я кстати, совершенно случайно ошибся когда писал код и мой пример уже неверный!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.06 21:02
Оценка:
Здравствуйте, yrashk, Вы писали:

Y>Скажите, а чем Вам EVAL не угодил?


EVAL и другая интерпретация идет лесом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.06 21:02
Оценка:
Здравствуйте, little_alex, Вы писали:

_>Если не секрет, что там смешного


Таварщи программируют на Блабле и стало быть оценивают другие языки с его уровнея. Это не позволяет им оценить приемущества более мощьного языка (с) орла что успешно продал Яху. Вот мы и дожили когда Блаблом стал Лисп, и лисп-программисты стали блабл-программистами смеющимися над тем, что не в силах понять.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Снова о Nemerle или профанация не пройдет :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.06 21:02
Оценка: -4
Здравствуйте, Andrei N.Sobchuck, Вы писали:

...
ANS>Я не знаю как ты считал строчки кода, но в любом случае, это лучше чем тот кусок спагетти, что привёл ты.

Привел отрывок какой-то хрени и делашь далеко идущие выводы. Человек привел аналогичный код. Ты же хрен знает что.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.