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


Y>>Чем Вам A не параметр? Мне передан параметр A, я потребовал, чтобы он был INTEGER. Хотите узнавать а не требовать? TYPE-OF/CLASS-OF к Вашим услугам. Ы?

_>Нужно:
_>

_>;(mymacro 10) => ok
_>;(mymacro (+ 1 2)) => ok
_>;(mymacro "bla-bal") => error (причем во время распахивания макроса)
_>;(mymacro (substr "bla-bla" :start 0 :end 2)) => error (причем во время распахивания макроса)
_>;(mymacro (cosh (+ 1 2 3 (* 10 20))) => ok
_>;(let ((x 10))
_>;  (declare (type number x))
_>;    (mymacro x))) => ok

_>;(let ((x "bla-bla"))
_>;  (declare (type string x))
_>;    (mymacro x))) => error

_>;

_>Напишешь такое ?

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

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

E>Это не придирки. Это способ показать, что мне не навится предложенное решение.

У меня складывается впечатление, что тебе хочется любым способом сказать, что "фигня этот ваш Немерле". Лучше бы попробовал какую-нибудь реальную проблему в нём найти. Всем бы полезней было.

E>Сам же писал недавно про историю, когда в условиях цейтнота на косяки в конфигурации наткнулись. Хотел бы лично ты в таких условиях враперы для каких-то либ писать?

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

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

IT>У меня складывается впечатление, что тебе хочется любым способом сказать, что "фигня этот ваш Немерле". Лучше бы попробовал какую-нибудь реальную проблему в нём найти. Всем бы полезней было.

Если бы хотел, то сказал. Например, ничего не мешает мне по поводу и без повода говорить "Java must die!".

Я (думаю, как и AVK), понять не могу, в чем же засада. Ну не бывает языков без недостатков. Даже Влад после восхваления C# теперь уже на Nemerle переключился.

Потенциально возможные конфликты синтаксических расширений за проблему не принимаются. :zx:
Ну и ладно. Каждый меряет Nemerle по своим задачам. Тебе было интересно compile-time генерацию посмотреть. Ты для себя проблем не увидел. Вот и здорово.
Я его по своим меркам посмотрел. Получилось пока не так здорово.

E>>Сам же писал недавно про историю, когда в условиях цейтнота на косяки в конфигурации наткнулись. Хотел бы лично ты в таких условиях враперы для каких-то либ писать?

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

И ты считаешь, что это нормально? Язык провоцирует на подобные вещи, а исправлять их должен суппорт конкретного продукта или сам пользователь?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>???. один класс с C#2 итератором полностью сольёт?

Да будет тебе известно, что Nemerle это по большому счету надмножество C# 2.0, за минусом небезопасных конструкций и пары других мелочей. Если не пользоваться дополнительными возможностями и всегда указывать типы, то програма на Nemerle от програмы на C# 2.0 семантически отличается мягко говоря мало.

Приведи мне пример хорошего кода на C# 2.0 с использованием итераторов(ну и дженериков желательно тоже, в общем сложный код) решающий задачу(например задачу представления AST или что-то в этом духе), которую ты имеешь в виду. Тогда посмотрим окажется ли аналогичный(с похожей архитектурой и решающий ту же задачу) код на Nemerle лучше и читабельнее. Пока конкретных предложений я не услышал.

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

E>Я (думаю, как и AVK), понять не могу, в чем же засада. Ну не бывает языков без недостатков. Даже Влад после восхваления C# теперь уже на Nemerle переключился.

Недостатки скорее всего в нём есть. Как же без них? Вопрос перевесят ли его достоинства эти недостатки и недостатки существующих языков.

E>Потенциально возможные конфликты синтаксических расширений за проблему не принимаются. :zx:

Я с этим смогу жить, в плюсах и не с таким жил и как видишь пока жив.

E>Я его по своим меркам посмотрел. Получилось пока не так здорово.

Расскажи нам что не так здорово? Поделись!

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

E>И ты считаешь, что это нормально? Язык провоцирует на подобные вещи,

Я не заметил никаких явных провокаций. Точно так можно сказать что C провоцирует писать функции с одинаковыми именами, а C++ — классы.

E>а исправлять их должен суппорт конкретного продукта или сам пользователь?

Причём тут саппорт вообще? Если я напишу функцию Foo в моём продукте, а ты по случайному недоразумению напишешь такую же, то кому из нас её исправлять?

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

VK>Пока конкретных предложений я не услышал.

Может не нужно сразу сложную, а проще что-нибудь, знакомое публике? Например, вот эта задача

Автор: AndrewVK
Дата: 13.07.05

.

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

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

E>Я (думаю, как и AVK), понять не могу, в чем же засада. Ну не бывает языков без недостатков. Даже Влад после восхваления C# теперь уже на Nemerle переключился.

Не бывает. Я даже уверен, что в Nemerle они есть. Но тех недостатков, на которые ты упорно указываешь, я не вижу.

E>Потенциально возможные конфликты синтаксических расширений за проблему не принимаются. :zx:
E>Ну и ладно. Каждый меряет Nemerle по своим задачам. Тебе было интересно compile-time генерацию посмотреть. Ты для себя проблем не увидел. Вот и здорово.
E>Я его по своим меркам посмотрел. Получилось пока не так здорово.

Напиши код на Nemerle, который, по твоему мнению, может вызвать проблему (проблемы). А то абстрактно все рассуждать мастера, только мало толку. Т.е. я, похоже, не не вижу проблему, а не понимаю, о какой именно проблеме ты постоянно говоришь. О конфликте имён макросов? Так его нет, этого конфликта, — пространства имён всё разрулят

Автор: Oyster
Дата: 20.02.06

.

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

O> О конфликте имён макросов?

Он о конфликте ключевых слов макросов с синтаксическими расширениями. Пространствами имен это можно разрулить, а еще обертками. Но он обертки писать не хочет и оба расширения хочет использовать одновременно.

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

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

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

E>>Я его по своим меркам посмотрел. Получилось пока не так здорово.

IT>Расскажи нам что не так здорово? Поделись!

Игорь, я уже говорил. Но меня здесь на смех поднимают. А роль городского сумашедшего, знаешь ли, не самая для меня привычная.

IT>Я не заметил никаких явных провокаций. Точно так можно сказать что C провоцирует писать функции с одинаковыми именами, а C++ — классы.
IT>Причём тут саппорт вообще? Если я напишу функцию Foo в моём продукте, а ты по случайному недоразумению напишешь такую же, то кому из нас её исправлять?

Это известная проблема в C и раних версиях C++. В C для нее так и не нашли исправления, придумали только workaround в виде префиксования имен функций и макросов (макросы к тому же рекомендуют большими буквами набирать). Но это все рекомендации, соблюдение которых невозможно проконтролировать. И их нарушения, как я проказал в примере с ACE, могут привести к проблемам.
В C++ эту проблему для функций и классов разрешили путем изменения языка -- добавлением пространств имен. Чтобы случился конфликт имен в разных продуктах от разных производителей при использовании пространств имен нужно постараться. Но с макросами проблема осталась. Если в библиотеке libhttp (если не ошибаюсь от W3C) есть макрос LOG_ERR, то он пересекается с моим макросом LOG_ERR и мне приходится вручную в месте каждого конфликта его разрешать какими-то очередными workaround-ами. И не всегда гарантируется, что я вовремя замечу, что пользуюсь не тем макросом.

В Nemerle с синтаксическими расширениями (после соответствующей директивы using) ситуация похожа на ситуацию с макросами в C/C++ -- если встречаются два макроса с одинаковыми именами, то разрешение этого конфликта ложится на плечи того, кто с конфликтом встретился. Но в Nemerle ситуация чуть хуже. В C/C++ макросам даже нужно давать длинные корявые имена, чтобы они сразу бросались в глаза. Поэтому в C++ нормальным именем может быть SOL4_EVENT_WITH_INCIDENT_TYPE. Но при расширении синтаксиса в язык добавляются конструкции, которые по-определению будут использоваться часто (иначе их можно было бы не вводить вообще). Поэтому и использование их должно быть удобным. А это значит, что имена новых ключевых слов должны быть короткими, емкими, лаконичными и, вероятно, общеупотребительными. В таких условиях простое event гораздо предпочтительнее, чем sol4_event_with_incident_type. Но, чем короче и общеупотребительнее имя, тем больше верятность конфликта при совместном расширении синтаксиса разными библиотеками.

Я думаю, что это не нормальная ситуация, для языка, который появился гораздо позже, чем C/C++ и, что самое главное, дает программисту возможность расширять язык. Я так думаю и не требую, чтобы так же думал кто-то еще.

Просто, если я соберусь делать какую-то библиотеку с расширением синтаксиса, я хочу чтобы мои пользователи имели с ней как можно меньше проблем. Введение в синтаксис таких ключевых слов, как agent, subscribe, message, priority, event конфликты с другими библиотеками может спровоцировать. А значит -- доставить проблемы. Вот и все.

При этом я не говорю и не подразумеваю, что Nemerle фуфло -- это время решит, а не я. Но вот наличие непосредственно в языке механизма, который бы просто разруливал такие конфликты мне кажется необходимым (крайне желательным, по меньшей мере). Хотябы в таком виде: в месте конфликта уточнять ключевое слово именем макропакета:

sobjectizer#agent ... sobjectizer#event ... {
  smtp#agent ... smtp#subscribe ...;
} sobjectizer#subscribe ...

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

VK>Но он обертки писать не хочет и оба расширения хочет использовать одновременно.

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

VK>Я собственно ему это и сообщил, и примеры давал, просто обсуждение Nemerle слишком разрослось и сложно все сообщения прочитать.

Как раз таки внимательно читаю. Но мое мнение

Автор: eao197
Дата: 21.02.06

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

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

ИМХО, этот постулат противоречит убежденности, например, VladD2

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

Y>Здравствуйте, little_alex, Вы писали:
Y>Скажите, а чем Вам EVAL не угодил?
Ну и как написать mymacro с его помощью?

Здравствуйте, Lazy Cjow Rhrr, Вы поставили:

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

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

FR>>Это не важно, важно то что и форт и лисп и немерли очень гибкие, и эта гибкость очень легко может привести к тому что язык расползется, превратится в кучу трудно совместимых и непонятных непосвященым диалектов.

O>Да нет уж. Я уже тут где-то писал, что у Nemerle есть синтаксис и он позволяет не писать на "птичьем" языке, в то время как Форт с Лиспом буквально требуют этого — вот отличие. И вот почему Nemerle не станет кучкой диалектов — потому что у него уже есть основной диалект, который будет только расширяться.

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

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

E>Просто, если я соберусь делать какую-то библиотеку с расширением синтаксиса, я хочу чтобы мои пользователи имели с ней как можно меньше проблем. Введение в синтаксис таких ключевых слов, как agent, subscribe, message, priority, event конфликты с другими библиотеками может спровоцировать. А значит -- доставить проблемы. Вот и все.

Совершенно верно. Выходов тут пять:

1. Забить и использовать (авось)
   
2. Испугаться и использовать только внутри своих библиотек (или не использовать вообще — в Nemerle вкусностей хватает и без того)
   
3. Использовать макросы-обёртки (как уже предполагалось)
   
4. Договориться о правилах именования first tokens (добавлять какой-нить префикс)
   
5. Создать коммитет по стандартизации расширений языка

Всё решаемо.

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

E>Хотябы в таком виде: в месте конфликта уточнять ключевое слово именем макропакета:

А использование пространства имён тебя устроит?

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

V>Насчет Форта немного не так. У него есть "определяющие" слова, т.е. immediate слова. Эти слова — нечто вроде макросов. Их синтаксис и сложность полностью зависит от функциональности определяющего слова, то бишь тела (алгоритма) макроса. У меня была своя либа на Форте, для программирования этих определяющих слов (макросов), которые производили синтаксический разбор последующего потока, т.е. запросто можно было отходить от польской записи и использовать "обычную". ВСЕ управляющие структуры Форта реализованы как определяющие слова, то бишь макросы, и почти все они — вовсе не "польские" по синтаксису.

Ну и кто будет писать на Форте в таком стиле?

Это уже вопрос идеологии — никто не будет так писать на Форте, так же как никто не будет писать в императивном стиле на Лиспе (LOOP не в счёт — не всем нравится).

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

VD>

VD>[Accessor]
VD>mutable _somePropery : int;

VD>// Эквивалентно следующей конструкции: 
VD>private mutable _somePropery : int;

VD>public SomePropery : int 
VD>{
VD>  get { _somePropery }
VD>  set { _somePropery = value; }
VD>}
VD>

Придерусь к записи. Макрос Accessor по умолчанию создает только геттер. Чтобы заставить его
создать сеттер, надо так и сказать [Accessor(WantSetter = true)] (в названии проперти мог ошибиться)

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

E>>Хотябы в таком виде: в месте конфликта уточнять ключевое слово именем макропакета:

IT>А использование пространства имён тебя устроит?

Можно пример?

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

IT>А использование пространства имён тебя устроит?

Похоже, что имя пространства имён не получится использовать в качестве квалификатора first token-а, к сожалению. Из доки:

The syntax keyword is used here to define a list of elements forming the syntax of the macro call. The first token must always be an unique identifier (from now on it is treated as a special keyword triggering parsing of defined sequence). It is followed by tokens composed of operators or identifiers passed as string literals or names of parameters of macro. Each parameter must occur exactly once.

Также проверено на практике. Т.е. если у нас такие макросы:

namespace Company1
{
    macro printer(n)
    syntax ("printer", "-->", n)
    {
        <[ WriteLine("Company1: " + $n.ToString()) ]>
    }
}

namespace Company2
{
    macro printer(n)
    syntax ("printer", "-->", n)
    {
        <[ WriteLine("Company2: " + $n.ToString()) ]>
    }
}

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

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

Хотя, может, это я просто пишу неправильно?...

Зато можно явно задать префикс для первого токена, т.е. пытаться делать имя макросе уникальным. Очевидное и не очень красивое решение.

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

O>Я уже тут где-то писал, что у Nemerle есть синтаксис и он позволяет не писать на "птичьем" языке, в то время как Форт с Лиспом буквально требуют этого — вот отличие.

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