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

H>Разумное зерно в этом в целом есть — например возможность инлайна тел методов (ага суперкомпиляция для бедных .

Это вы тут нашли рациональное зерно, которого скорее всего нету .

Если макрос лексически внутри другого типа, это должно что-то значить. Макросы всегда имеют модификатор public, поэтому внутри класса их как-то скрывать не имеет смысла. Макрос внутри типа должен иметь доступ к private-элементам этого типа, что тоже не имеет смысла, поскольку макрос это всегда точка входа.

Осталась единственная функция объявления макроса внутри класса — помещение в дерево неймспейсов, но это решается неймспейсами.

А если имеются в виду макрометоды или макротипы, то про это надо писать в посте, чтобы не было путаницы.

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

H>Да, это оно (в моем понимании). Вариация на тему extension-ов из шарпа.

Ну так их надо и реализовывать как экстеншены. Отдельно от самого класса.

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

А>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

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

Классы будут восприниматься всеми как классы.

Лучше взять решение из C# — методы расширения. Берем макрос и помечаем первый параметр ключевым словом this. Далее интерпретируем их как псевдо-методы.

Ребята, почему в Немерле нельзя объявить макрос внутри класса?

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

А>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

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

А>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

Если я правильно понял вопрос, то потому, что макрос выполняется до того момента, как класс будет скомпилирован.

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

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

А>>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

Z>Если я правильно понял вопрос, то потому, что макрос выполняется до того момента, как класс будет скомпилирован.

Согласен, но, может, предпринимались попытки специальным образом обработать такой вид объявления макросов? Например, компилировать макрос в лексическом контексте класса, но бинарную реализацию генерировать в статическом классе (или статическим методом). Фича кажется весьма заманчивой, ибо тогда можно будет для макросов использовать инфиксную нотацию вызова. Более подробно вот тут: http://xeno-by.livejournal.com/70984.html. Очень интересны ваши комментарии.

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

XB>Согласен, но, может, предпринимались попытки специальным образом обработать такой вид объявления макросов? Например, компилировать макрос в лексическом контексте класса, но бинарную реализацию генерировать в статическом классе (или статическим методом). Фича кажется весьма заманчивой, ибо тогда можно будет для макросов использовать инфиксную нотацию вызова. Более подробно вот тут: http://xeno-by.livejournal.com/70984.html. Очень интересны ваши комментарии.

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

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

А>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

Потому что это бессмысленно.

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

А>Ребята, почему в Немерле нельзя объявить макрос внутри класса?

Очень просто. Потому что не сделали Идею макро-методов Влад уже как-то высказывал.

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

Z>В том-то и дело, что лексический контекст подразумевает легкое использование типа, полей и методов класса. А сам макрос должен быть скомпилирован до компиляции класса.

Предполагается, что макрос будет использоваться совместно с классом, а не внутри него.

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

C>Потому что это бессмысленно.

Разумное зерно в этом в целом есть — например возможность инлайна тел методов (ага суперкомпиляция для бедных .

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

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

H>>Разумное зерно в этом в целом есть — например возможность инлайна тел методов (ага суперкомпиляция для бедных .

C>Это вы тут нашли рациональное зерно, которого скорее всего нету .

C>Если макрос лексически внутри другого типа, это должно что-то значить. Макросы всегда имеют модификатор public, поэтому внутри класса их как-то скрывать не имеет смысла. Макрос внутри типа должен иметь доступ к private-элементам этого типа, что тоже не имеет смысла, поскольку макрос это всегда точка входа.

C>Осталась единственная функция объявления макроса внутри класса — помещение в дерево неймспейсов, но это решается неймспейсами.

C>А если имеются в виду макрометоды или макротипы, то про это надо писать в посте, чтобы не было путаницы.

Ага, имел ввиду макрометоды. Как я понял, эта идея рассматривалась, но еще не реализована. Интересно, какие с ней было проблемы, особенно интересно, как решали проблему ограничения областей видимости (например то, что в квазицитате можно написать сослаться на this, а из тела макроса нельзя).

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

XB>Ага, имел ввиду макрометоды. Как я понял, эта идея рассматривалась, но еще не реализована. Интересно, какие с ней было проблемы, особенно интересно, как решали проблему ограничения областей видимости (например то, что в квазицитате можно написать сослаться на this, а из тела макроса нельзя).

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

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

C>Здравствуйте, xeno.by, Вы писали:

XB>>Ага, имел ввиду макрометоды. Как я понял, эта идея рассматривалась, но еще не реализована. Интересно, какие с ней было проблемы, особенно интересно, как решали проблему ограничения областей видимости (например то, что в квазицитате можно написать сослаться на this, а из тела макроса нельзя).

C>Мне всегда казалось, что разница между макросом и макрометодом чисто на уровне "входа" — то есть после успешного биндинга и запуска макрометода он разворачивается как самый обычный макрос.

Можешь, пожалуйста, привести пример макрометода? Это то же самое, что я описал у себя в ЖЖ (http://xeno-by.livejournal.com/70984.html)?

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

XB>Можешь, пожалуйста, привести пример макрометода? Это то же самое, что я описал у себя в ЖЖ (http://xeno-by.livejournal.com/70984.html)?

Да, это оно (в моем понимании). Вариация на тему extension-ов из шарпа.

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

Z>Ну так их надо и реализовывать как экстеншены. Отдельно от самого класса.

Согласен, в реализации макросов внутри классов, мало смысла, лучше реализовать полноценные макросы расширения для любых классов или интерфейсов с удобным синтаксическим сахаром, в глобальной области видимости, как все сущности времени компиляции.

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

XB>Ага, имел ввиду макрометоды. Как я понял, эта идея рассматривалась, но еще не реализована. Интересно, какие с ней было проблемы, особенно интересно, как решали проблему ограничения областей видимости (например то, что в квазицитате можно написать сослаться на this, а из тела макроса нельзя).

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

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

H>>Да, это оно (в моем понимании). Вариация на тему extension-ов из шарпа.

Z>Ну так их надо и реализовывать как экстеншены. Отдельно от самого класса.

В яве подобных решений нет. Вот они и пытаются найти решение аналогичное эксеншон-методам.

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

CU>Здравствуйте, xeno.by, Вы писали:

XB>>Ага, имел ввиду макрометоды. Как я понял, эта идея рассматривалась, но еще не реализована. Интересно, какие с ней было проблемы, особенно интересно, как решали проблему ограничения областей видимости (например то, что в квазицитате можно написать сослаться на this, а из тела макроса нельзя).

CU>Ссылаться на содержимое класса, можно в стиле методов расширения, для чего ссылаться на внутренности экземплятов, какое может быть реальное применение этого, можно пример?

Здесь надо учесть две особенности Скалы, т.к. именно в контексте макросов для Скалы и появилось такое желание.

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

Во-вторых, в JVM семантика вложенных классов несколько отличается от семантики вложенных классов в CLR. В JVM такие классы могут видеть this своих внешних классов и ссылаться на их инстанс-поля. Соответственно, икстеншн-методы (которые дают доступ только к своему this) не полностью эмулируют инстанс-методы в JVM.

VD>В яве подобных решений нет. Вот они и пытаются найти решение аналогичное эксеншон-методам.
Аналог экстеншн-методов, причем более мощный, у нас есть. Только вот к макросам он неприменим.

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

VD>>В яве подобных решений нет. Вот они и пытаются найти решение аналогичное эксеншон-методам.
XB>Аналог экстеншн-методов, причем более мощный, у нас есть. Только вот к макросам он неприменим.

Значит это не аналог. Большая мощность тут только вредна. Нужен полный аналог.

macro Select[In, Out, Collection[_]](this instance : Collection[In], convert : In -> Out) : Collection[Out]
{
  if (instance.Type.IsArray)
    <[
       def arr = $instance;
       def result = array(arr.Length);

       for (mutable i = 0; i < arr.Length; i++)
         result[i] = convert(arr[i]);
    ]>
  else if (instance.Type.Equals(listType))
    ...
}

Здесь this указывает, что макрос можно применять как метод (через точку).

При этом не нужны никакие классы. Пользователю так же все будет очевидно.

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

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

Макрометод (можно, я их буду именно так называть?) без конкретного класса... Хороший пример для валидации нашего дизайна, спасибо! На имплиситах тоже можно замутить, причем специально мы об этом юзкейсе не задумывались. Значит, идем в правильном направлении

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

XB>Во-первых, экстеншн-методов у нас нет, вместо них есть имплиситы, которые маппятся на инстанс-методы. Поэтому, реализовать макрометоды при помощи имплиситов не получится по той же причине, по которой не получится их просто объявлять внутри самого класса.

XB>Во-вторых, в JVM семантика вложенных классов несколько отличается от семантики вложенных классов в CLR. В JVM такие классы могут видеть this своих внешних классов и ссылаться на их инстанс-поля. Соответственно, икстеншн-методы (которые дают доступ только к своему this) не полностью эмулируют инстанс-методы в JVM.

Имплиситы — это овердизайн. Еще раз повторяю, что вам нужен полный аналог методов расширений. По крайней мере для реализации маросов расширений. Макросы все равно являются средством времени компиляции и динамический полиморфизм им недоступен. Так что навороты имплиситов просто вредны.

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

XB>Макрометод (можно, я их буду именно так называть?) без конкретного класса... Хороший пример для валидации нашего дизайна, спасибо! На имплиситах тоже можно замутить, причем специально мы об этом юзкейсе не задумывались. Значит, идем в правильном направлении

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

Макро-метод (как ты его называешь) должен резовиться как обычная перегрузка, только вместо вызова должен подставляться кусок АСТ который в последствии приведет к активации макроса.

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

VD>Здравствуйте, xeno.by, Вы писали:

XB>>Во-первых, экстеншн-методов у нас нет, вместо них есть имплиситы, которые маппятся на инстанс-методы. Поэтому, реализовать макрометоды при помощи имплиситов не получится по той же причине, по которой не получится их просто объявлять внутри самого класса.

XB>>Во-вторых, в JVM семантика вложенных классов несколько отличается от семантики вложенных классов в CLR. В JVM такие классы могут видеть this своих внешних классов и ссылаться на их инстанс-поля. Соответственно, икстеншн-методы (которые дают доступ только к своему this) не полностью эмулируют инстанс-методы в JVM.

VD>Имплиситы — это овердизайн. Еще раз повторяю, что вам нужен полный аналог методов расширений. По крайней мере для реализации маросов расширений. Макросы все равно являются средством времени компиляции и динамический полиморфизм им недоступен. Так что навороты имплиситов просто вредны.

Овердизайн или нет — я промолчу, на эту тему уже сломаны миллион копий. А делать икстеншн-методы специально для макросов это как-то не очень.

VD>Макро-метод (как ты его называешь) должен резовиться как обычная перегрузка, только вместо вызова должен подставляться кусок АСТ который в последствии приведет к активации макроса.
Да, примерно так у нас и сделано.

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

XB>Овердизайн или нет — я промолчу, на эту тему уже сломаны миллион копий. А делать икстеншн-методы специально для макросов это как-то не очень.

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

VD>Вам нужно всего лишь синтаксическое решение. Покажи как это может быть выражено на имплиситах (от описания макроса, до его применения), поглядим.

Само по себе синтаксическое решение не привязано к имплиситам:

class Queryable[T] {
  def macro map[U](p: T => U): Queryable[U] = Linq.map
}

object Linq {
  def map[T, U](context: scala.reflect.macro.MacroContext)(U: context.Typ)(_this: context.Exp)(p: context.Exp): context.Exp = ...
}

Имплиситы могут помочь, если тебе надо объявить макрометод для тайп-параметра или тайп-мембера:

class Foo[T] {
  implicit class Wrapper(t: T) {
    def macro bar() = ...
  }
}

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

А>Имплиситы могут помочь, если тебе надо объявить макрометод для тайп-параметра или тайп-мембера:

А>class Foo[T] {
А> implicit class Wrapper(t: T) {
А> def macro bar() = ...
А> }
А>}

Кстати, если я правильно помню дотнет, то аналога последнему примеру вообще нет, т.к. икстеншн-методы можно объявлять только в статических классах.

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

А>Само по себе синтаксическое решение не привязано к имплиситам:

А>class Queryable[T] {
А>  def macro map[U](p: T => U): Queryable[U] = Linq.map
А>}

Это плохое решение. Люди будут путаться и не понимать что здесь мета-сущность, а что часть программы.

А>object Linq {
А> def map[T, U](context: scala.reflect.macro.MacroContext)(U: context.Typ)(_this: context.Exp)(p: context.Exp): context.Exp = ...
А>}
А>[/java]

Можно это все пояснить? Выглядит пугающе.

А>Имплиситы могут помочь, если тебе надо объявить макрометод для тайп-параметра или тайп-мембера:
А>

А>class Foo[T] {
А>  implicit class Wrapper(t: T) {
А>    def macro bar() = ...
А>  }
А>}
А>

Опять таки хорошо бы пояснений по больше дать.

VD>Это плохое решение. Люди будут путаться и не понимать что здесь мета-сущность, а что часть программы.

Согласен, возможно. Как бы ты улучшил эту декларацию без икстеншн-методов, ибо они реально не вариант в нашем случае?

VD>Можно это все пояснить? Выглядит пугающе.

Реализация макроса принимает следующие параметры: 1) контекст aka ImplicitCTX в Немерле, 2) список тайп-аргументов, 3) аргумент, соответствующий this, 4) список аргументов. А почему выглядит пугающе? Сложно, да, со всем сигнатурами и бла-бла, но вроде ничего из песни не выкинешь.

А>>Имплиситы могут помочь, если тебе надо объявить макрометод для тайп-параметра или тайп-мембера:
А>>

А>>class Foo[T] {
А>>  implicit class Wrapper(t: T) {
А>>    def macro bar() = ...
А>>  }
А>>}
А>>

VD>Опять таки хорошо бы пояснений по больше дать.

Последний пример соответствует следующему коду:

class Foo[T] {
  implicit def t2wrapper(t: T) = new Wrapper(t)

  implicit class Wrapper(t: T) {
    def macro bar() = ...
  }
}

Когда внутри класса Foo (т.е. в скоупе действия имплисита t2wrapper), компилер увидит вызов blah.bar(), где blah имеет тип T, этот вызов будет преобразован в t2wrapper(blah).bar(), после чего результат будет подвергнут макро-экспаншну. В параметр _this придет Apply(Ident(newTermName("t2Wrapper")), List(AST of blah)), откуда можно будет достать собственно blah и сделать с ним, что надо.

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

XB>Согласен, возможно. Как бы ты улучшил эту декларацию без икстеншн-методов, ибо они реально не вариант в нашем случае?

Я не понимаю почему они не вариант. Все что надо взять от идеи методов-расширений, это то, что this приделанный к описанию первого параметра позволяет использовать макрос как метод (через точку).

Я плохо знаком со Скалой. Так что вряд ли могу посоветовать решение в духе Скалы. Но если хочется похожести на другие фичи, то возможно нужно копать в строну синтаксиса имплиситов.

VD>>Можно это все пояснить? Выглядит пугающе.

XB>

XB>class Foo[T] {
XB>  implicit def t2wrapper(t: T) = new Wrapper(t)

XB>  implicit class Wrapper(t: T) {
XB>    def macro bar() = ...
XB>  }
XB>}
XB>

XB>Когда внутри класса Foo (т.е. в скоупе действия имплисита t2wrapper), компилер увидит вызов blah.bar(), где blah имеет тип T, этот вызов будет преобразован в t2wrapper(blah).bar(), после чего результат будет подвергнут макро-экспаншну. В параметр _this придет Apply(Ident(newTermName("t2Wrapper")), List(AST of blah)), откуда можно будет достать собственно blah и сделать с ним, что надо.

Остается не ясным зачем тут нужен этот класс Foo. Перемести параметр типа на метод, и будет тоже самое.

VD>Я плохо знаком со Скалой. Так что вряд ли могу посоветовать решение в духе Скалы. Но если хочется похожести на другие фичи, то возможно нужно копать в строну синтаксиса имплиситов.

Ну вот смотри, пример объявления имплисита был выше. Икстеншн-методы в духе Скалы реализуются объявлением враппера, в котором пишут "икстеншн"-метод, и написанием имплисит-конвертера к этому врапперу. Но метод внутри враппера, он все равно не статический, а принадлежит врапперу.

VD>Остается не ясным зачем тут нужен этот класс Foo. Перемести параметр типа на метод, и будет тоже самое.

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

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

XB>Ну вот смотри, пример объявления имплисита был выше. Икстеншн-методы в духе Скалы реализуются объявлением враппера, в котором пишут "икстеншн"-метод, и написанием имплисит-конвертера к этому врапперу.

Мрак. Точнее овердизайн, для этих целей.

XB>Но метод внутри враппера, он все равно не статический, а принадлежит врапперу.

Тогда имплиситы не подойдут.

Думайте над синтаксическим решением. Я бы не стал приплетать сюда классы.

VD>>Остается не ясным зачем тут нужен этот класс Foo. Перемести параметр типа на метод, и будет тоже самое.

XB>Например, ты объявляешь коллекцию от T и хочешь объявить икстеншн-метод для T, который будешь вызывать внутри коллекции. Согласен, не самая частая ситуация, но и не самая редкая. Для похожих ситуаций придуманы и ограничения на генерик параметры и тайпклассы, а имплиситы позволяют все это обобщить.

Ну, я своего мнения об мплиситах не изменил. Решение весьма спорное.


Реализовать на них макро-методы будет сложно (неуклюже).

В общем, если остановитесь на наличии класса, то бы посоветовал для таких классов указывать модификатор "macro" так:

macro class X[T]
{
  def macro M(...) ...
}

Тогда люди хот бы будут понимать, что это не совсем класс.

Кстати, на этот тип с огромной вероятностью придется накладывать ограничения. В том смысле, что это не класс как таковой, а описатель некоторого типа который будет в рантайме. Нечто вроде параметра типов высшего порядка.

Так что лучше все же не делать объявление похожим на объявление типа.

VD>Мрак. Точнее овердизайн, для этих целей.

Да, конкретно для этих целей получается многословно, но, в целом, имплиситы позволяют достичь кучи других вещей, например, заимплементить тайпклассы и пойти еще дальше: http://infoscience.epfl.ch/record/150280/files/TypeClasses.pdf. Если не видел слинкованный текст, зачти — мне в свое время было интересно.

VD>

А>>class Queryable[T] {
А>>  def macro map[U](p: T => U): Queryable[U] = Linq.map
А>>}
VD>

VD>Это плохое решение. Люди будут путаться и не понимать что здесь мета-сущность, а что часть программы.

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

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

VD>>

А>>>class Queryable[T] {
А>>>  def macro map[U](p: T => U): Queryable[U] = Linq.map
А>>>}
VD>>

VD>>Это плохое решение. Люди будут путаться и не понимать что здесь мета-сущность, а что часть программы.

XB>У меня есть надежда на то, что путем выноса тела макроса за пределы класса мы сводим путаницу к минимуму. Все равно не согласен?

Путаница в том, что "class Queryable[T]" будет восприниматься как объявление типа. А это не так. Мы описываем констрэйн на тип для которого надо добавить псевдо-метод.

В общем, я повторюсь, а это глупо.

Делайте как получается. В конце концов кому надо — привыкнут.

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

XB>Да, конкретно для этих целей получается многословно, но, в целом, имплиситы позволяют достичь кучи других вещей, например, заимплементить тайпклассы и пойти еще дальше: http://infoscience.epfl.ch/record/150280/files/TypeClasses.pdf. Если не видел слинкованный текст, зачти — мне в свое время было интересно.

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

Все эти извраты решают проблемы которых просто не было бы, если бы язык педоставлял бы расширяемость и метапрограммирование.
В общем, бритва Оккама рулит. Если есть два решения, выбирай самое простое.

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

VD>Все эти извраты решают проблемы которых просто не было бы, если бы язык педоставлял бы расширяемость и метапрограммирование.

Интересно, как можно при помощи макросов реализовать тайпклассы.

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

VD>Делайте как получается. В конце концов кому надо — привыкнут.

Ты пару раз сказал про то, что люди запутаются. Можешь, пожалуйста, привести пример такой путаницы?

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

VD>>Все эти извраты решают проблемы которых просто не было бы, если бы язык педоставлял бы расширяемость и метапрограммирование.

XB>Интересно, как можно при помощи макросов реализовать тайпклассы.

Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.

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

Любую задачу можно решить на С или Паскале (без классов, перегрузок, классов-типов и прочей мурни). Проблема только в том, что делать это тяжело. Но всегда можно придумать язык на котором конкретная задача предметной области описывается прямым и интуитивно понятным способом. Если мы можем легко описать такой язык и легко же создать преобразователь в более низкоуровневый язык, то для решения задачи нам вообще не нужны языковые навороты.

Возьми к примеру те же парсеры. Да, несомненно, их можно писать на базе функций высшего порядка, как в прочем и на основе классов. Но так же их можно писать и на базе банальных процедур, а то и вообще без них (goto и if хватит за глаза). Вот наши Nemerle.PEG и его новейшая версия основанная на собственных алгоритмах решает эту задачу используя минимум средств. Мы не используем ФВП, используем много goto и других низкоуровневых констуркций и при этом описания парсеров у нас получается в разы более декларативным нежели аналоги на Хаскеле.

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

VD>>Делайте как получается. В конце концов кому надо — привыкнут.

XB>Ты пару раз сказал про то, что люди запутаются.

Запутаются. Но кому надо напрягут мозг и разберутся. Напишете пару метров лишних мануалов, раз не хотите вводить новые конструкции в язык.

XB>Можешь, пожалуйста, привести пример такой путаницы?

Примеры ты и сам приводил. Я уже устал повторять, что люди просто не будут ничего понимать. Для них это будет член класса. Причудливый и непонятный. Они будут думать, что видят перед собой класс экзепляр которого создается в рантайме. А следовательно будут думать, что и методы (в том числе и макро-методы) будут вызваться в рантайме же.

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

VD>Примеры ты и сам приводил. Я уже устал повторять, что люди просто не будут ничего понимать. Для них это будет член класса. Причудливый и непонятный. Они будут думать, что видят перед собой класс экзепляр которого создается в рантайме. А следовательно будут думать, что и методы (в том числе и макро-методы) будут вызваться в рантайме же.

Действительно, это обычный класс, просто некоторые его методы (макрометоды) себя ведут по-другому. В чем подвох? Приведи пример. Я ведь без издевки спрашиваю. Почему бы не поделиться своим опытом?

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

VD>Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.

Если какая-то языковая фича решает достаточно большой класс проблем более выразительно, чем макросы, я голосую за эту фичу. Как бы ты на макросах выразил тот факт, что в некий метод можно передать только объекты, для которых перегружен оператор "+"?

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

VD>>Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.

XB>Если какая-то языковая фича решает достаточно большой класс проблем более выразительно, чем макросы, я голосую за эту фичу. Как бы ты на макросах выразил тот факт, что в некий метод можно передать только объекты, для которых перегружен оператор "+"?

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

А все эти передачи чего-то куда-то — это детали реализации.

Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.

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

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

XB>Действительно, это обычный класс, просто некоторые его методы (макрометоды) себя ведут по-другому. В чем подвох? Приведи пример. Я ведь без издевки спрашиваю. Почему бы не поделиться своим опытом?

Если я в десятый раз повторю одно и то же, вряд ли твое понимание/мнение изменится.

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

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

По сему человек разрабатывающий макрос должен четко это понимать.

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

Кроме того, как я уже показал, типы используемые для описания параметров типизированных макросов по сути не являются типами, а являются эдакими заместителями как в случае с дженерик-параметрами. По сути это не тип, а констрэйны на тип который появится в рантайме.

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

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

VD>В общем, ты мыслишь стереотипами к которым ты привык. Пока ты ты не осознаешь это ты меня не поймешь.

Звучит как-то стремно. Влад, почему ты меня заставляешь доказывать, что я не верблюд? Почему бы просто не рассказать свои идеи, а там уже будет видно, пойму я или нет. Если я что-то не так сказал, и теперь со мной неинтересно общаться — расскажи, что не так.

VD>Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.

Расскажи, если не секрет.

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

VD>Это не фига не обычный класс

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

Пример взят из жизни, но немного упрощен, чтобы не захламлять пост. Есть обычный класс Range, который моделирует диапазон чисел. У него есть мемберы lo и hi, а также перегружен метод toString:

class Range(val lo: Integer, val hi: Integer) {
  def toString = s"range: $from - $to"
}

У этого класса есть метод foreach, который делает понятно что:

class Range(val lo: Integer, val hi: Integer) {
  def toString = s"range: $lo - $hi"

  def foreach(action: Integer => Unit) =
    for (i <- lo to hi) action(i)
}

Теперь можно писать вот так:

new Range(1, 5).foreach(println)
println(" вышел зайчик погулять")

Этот метод явно тормозит по сравнению с обычным циклом while. Юзеры негодуют. Поэтому мы напишем макрос, который уберет замыкания и вызовы функций. Для тебя это, ессно, не новость, но немного терпения:

object Macros {
  def foreach(ctx: MacroContext)(range: ctx.Expr[Range])(action: ctx.Expr[Integer => Unit]) = scala"""
    val i = $range.lo
    while (i < $range.hi) 
     ${substituteClosureArgumentWithReferenceToLocalVariable(action, "i")}
  """
}

А теперь заменим старую реализацию метода foreach на макрос:

class Range(val lo: Integer, val hi: Integer) {
  def toString = s"range: $lo - $hi"

  def foreach(action: Integer => Unit) =
    macro Macros.foreach
}

В итоге: foreach воспринимается пользователями Range как обычный метод, с понятной сигнатурой, интеллисенсом, прозрачным бинарным представлением. В отличие от extension-методов для вызова этого метода ничего не надо импортировать — он с самого начала логически находится в классе. С другой стороны, девелопером класса Range макрос воспринимается как совершенно отдельная от класса Range сущность, т.е. здесь вот, на мой взгляд, путаницы не будет.

Заранее прошу прощения, если я чего-то в очередной раз не понимаю. В таком случае надеюсь, что наше следующее обсуждение будет для тебя более приятным. Спасибо за время и усилия, потраченные в этом треде.

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

XB>Звучит как-то стремно. Влад, почему ты меня заставляешь доказывать, что я не верблюд?

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

XB>Почему бы просто не рассказать свои идеи, а там уже будет видно, пойму я или нет. Если я что-то не так сказал, и теперь со мной неинтересно общаться — расскажи, что не так.

Дык я рассказал. Идея проста как пробка. Вместо того чтобы выписывать программы на универсальном языке, создаем специализированный язык и решаем задачу на нем.

Что тут не понятного то?

VD>>Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.

XB>Расскажи, если не секрет.

Дык уже. И не раз.

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

Все гипер-навороты нужны для обхода ограниченности самого языка. Зачем в ООЯ нужны еще и классы-типов? Это ведь разновидность динамического полиморфизма. В Хасклее других средств полиморфизма просто нет. По сему классы типов оправданы. А в Скале — это дублирование функциональности.

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

У нас же есть механизм позволяющий выражать задачи прямо в терминах предеметрой области и трасформировать ее реализацию во что угодно.

Если нам нужен динамический полиморфизм мы можем использовать классы, виртуальные методы, интерфейсы и ФВП.

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

По сему мое мнение очень простое. Не нужно впихивать в язык всевозможные крутые фичи. Лучше впихнуть в язык одну фичу которая позволит заменить кучу других. И такая фича — расширяемост. Она позволяет делать ДСЛ-и под копотом у которых может быть что угодно. В том числе и код который считается не качественным, если его писать руками.

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

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

VD>Секрет же успеха тут очень прост — мы должны сделать расширяемость языка простой до предела. Дать людям удобные и (главное) простые средства расширения языка. А уже эти люди, сами, реализуют нужные им расширения.

Получается, мы перекладываем проблему дизайна языков на этих людей. Ведь, согласись, не так уж и просто задизайнить язык программирования, чтобы он был согласован сам с собой и не раздражал в использовании. Можно глянуть какой-нибудь end-to-end кейс-стади разработки на Немерле? Например, разработки веб-приложения. PEG действительно впечатляет, согласен, но хочется увидеть что-то более объемное.

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

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

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

Согласен, это всего лишь аналогия, но, надеюсь, она проиллюстрирует ход моих мыслей.

Привет, Влад! Прокомментируешь мои последние две мессаги?