написал макрос для проверки

[assembly: Nemerle.Internal.OperatorAttribute ("DBLib", "|>", false, 120, 121)]
[assembly: Nemerle.Internal.OperatorAttribute ("DBLib", "!>", false, 120, 121)]

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Method)]\
  macro Rule(typeBuilder : TypeBuilder, _ : ClassMember.Function, expr : PExpr)\
  syntax ("Rule", expr)
    _ = expr

и смотрю, что он дает для выражения:

#pragma warning disable 10005
#pragma indent
  
public class Var 

  [DBall] meth()
    5 > z
  
  Rule 5 > z && 10 > z |> r = "" |> r = "6" !> r = "5" //вар 1

  Rule 5 > z && 10 > z |> 
     r = "" |> r = "6" !> r = "5" //вар 2
  
  r : string
  s : double   
  z : int

в варианте 1 AST-рутом оказывается !> что логично.
в варианте 2 — |> . как на это реагировать?

_C_>в варианте 1 AST-рутом оказывается !> что логично.
_C_>в варианте 2 — |> . как на это реагировать?

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

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


_C_>>в варианте 1 AST-рутом оказывается !> что логично.
_C_>>в варианте 2 — |> . как на это реагировать?

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

Поддержка отступов в Nemerle вещь второстепенная.
Нужно улучшать, но вопрос как всегда кто будет делать.

Более того, нужна эвристика чтобы писать поменьше "\" в конце строк.
В случаях атрибутов, macro — syntax и т.п.

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Method)] \
  macro Rule(typeBuilder : TypeBuilder, _ : ClassMember.Function, expr : PExpr) \
 ...

[Record] \
[Serializable] \
...

_NN>Поддержка отступов в Nemerle вещь второстепенная.
_NN>Нужно улучшать, но вопрос как всегда кто будет делать.

Согласен. Мне интересно, такую фичу реально добавить на N1 или парсер не позволит.
имеет ли смысл туда смотреть?

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

_NN>Поддержка отступов в Nemerle вещь второстепенная.

Кстати. А есть у кого мысли о поддержке отступов в Н2?

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

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

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

Пишу сейчас на руби, такой подход очень радует.

Мне кажется, задача универсальной поддержки решаема на пеге. Для поддержки отступов должен генериться отдельный парсер. Для поддержки опциональных скобок, достаточно определить их парность в грамматике. Если они парные, то открывающую делать опциональной, а при отсутствии открывающей контролировать обязательное отсутствие закрывающей. С точкой с запятой в этом режиме поступать тоже просто, если ее надо заменять на правило (";"/"\n")

foreach x in [1, 2, 3]
  WriteLine x

match x
  1 => true
  _ => false

Вероятно, что у меня сейчас глаз "испорчен" ruby, и вас этот код выглядит плохо читаемо, но, уверяю, что попробовав оба стиля, вы не выберете стиль со скобками, блоками {} и обязательной точкой с запятой по своей воле.

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

Z>Вероятно, что у меня сейчас глаз "испорчен" ruby, и вас этот код выглядит плохо читаемо, но, уверяю, что попробовав оба стиля, вы не выберете стиль со скобками, блоками {} и обязательной точкой с запятой по своей воле.

Может тогда проще хранить текст в виде аст и при открытии показывать в соотвествующем стиле?

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

А>Может тогда проще хранить текст в виде аст и при открытии показывать в соотвествующем стиле?

Чем проще? Как хранить? Как читать диффы в vcs? Как хранить исходник, который не является корректным AST?

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

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

_NN>>Поддержка отступов в Nemerle вещь второстепенная.

Z>Кстати. А есть у кого мысли о поддержке отступов в Н2?

Мысли есть, но кто будет заниматься ?

Python-like style в Nemerle — рулёз форева !!!

Автор: VladD2
Дата: 15.11.10

pragma indent в новом парсере

Автор: goosevan
Дата: 08.03.09

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

Z>>Кстати. А есть у кого мысли о поддержке отступов в Н2?

_NN>Мысли есть, но кто будет заниматься ?

_NN>Python-like style в Nemerle — рулёз форева !!!

Автор: VladD2
Дата: 15.11.10

_NN>pragma indent в новом парсере

Автор: goosevan
Дата: 08.03.09

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

Конечно будут неоднозначности, которые надо просто однозначно разрешать.
например

if x y z else 0

конечно писать не стоит, но хотелось бы разбирать его так

if (x) y(z) else 0

в руби, для разрешения этой неоднозначности в однострочном if обязателен then, но мы себе такого позволить не можем. Ибо нет никакого желания затачивать синтаксические макры под два синтаксиса.

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

Z>в руби, для разрешения этой неоднозначности в однострочном if обязателен then, но мы себе такого позволить не можем. Ибо нет никакого желания затачивать синтаксические макры под два синтаксиса.

Вариант второй это обязать круглые скобки в if и тоже проблемы нет.

if (x) y(z) else 0

Лично я не вижу необходимости убирать скобки при вызове функций.

Z>По ссылкам обсуждение такого синтаксиса в Н1. Я же про Н2. Очевидно, что обычный препарсер справляется с задачей на троечку, а закладывать и поддерживать два расширяемых синтаксиса никто не будет. То есть надо уметь строить парсер по обычной, скобочной грамматике.

а разве на лету N2 парсер не может скорректировать деталь своей грамматики? слухи об этом были.

Z>Конечно будут неоднозначности, которые надо просто однозначно разрешать.
Z>например

Z>

Z>if x y z else 0
Z>

Z>конечно писать не стоит, но хотелось бы разбирать его так
Z>[nemerle]
Z>if (x) y(z) else 0

необычное прочтение. может описка и надо так if x(y,z) ..


Z>в руби, для разрешения этой неоднозначности в однострочном if обязателен then, но мы себе такого позволить не можем. Ибо нет никакого желания затачивать синтаксические макры под два синтаксиса.

если в грамматике перенос зависит от того, в каком контексте (в операторе или нет), не надо ни then, ни скобки. очень удобно. живой пример

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

_C_>а разве на лету N2 парсер не может скорректировать деталь своей грамматики? слухи об этом были.

Да должен уметь. В любом случае это из коробки не будет и надо что-то специально придумать для такого случая.

_C_>необычное прочтение. может описка и надо так if x(y,z) ..

тогда что является выражением then

Z>>в руби, для разрешения этой неоднозначности в однострочном if обязателен then, но мы себе такого позволить не можем. Ибо нет никакого желания затачивать синтаксические макры под два синтаксиса.

_C_>если в грамматике перенос зависит от того, в каком контексте (в операторе или нет), не надо ни then, ни скобки. очень удобно. живой пример

в кофескрипте точно такой же синтаксис для if без переноса как и в руби.

if happy and knowsIt
  clapsHands()
  chaChaCha()
else
  showIt()

date = if friday then sue else jill

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

_NN>Лично я не вижу необходимости убирать скобки при вызове функций.

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

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

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

_NN>>Лично я не вижу необходимости убирать скобки при вызове функций.

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

Ну вот в Python не нужны скобки в if, но там есть ":" для отделения от остальной части.
Нужно уточнить до деталей и продумать новый синтаксис, чтобы все было гармонично.

P.S.
Я не совсем понимаю, мы обсуждаем новый синтаксис Nemerle или же вариант с отступами ?
Если второе, то как было замечено, писать два разных макроса на разные синтаксисы не очень хорошая идея.

_C_>>необычное прочтение. может описка и надо так if x(y,z) ..

Z>тогда что является выражением then

для выражения if x y z else n — ничего

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

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

Z>>тогда что является выражением then

_C_>для выражения if x y z else n — ничего

_C_>мысль была такая — последовательно идущие выражения складываются в вызов функции, где все последующие -ее аргументы.
_C_>а иначе скобки, конечно.

если брать пример с руби, то там аргументы разделяются запятыми. То есть x y z это x(y(z)). Для отделения условия от выражения then используется перевод строки или слово then.

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

_NN>Ну вот в Python не нужны скобки в if, но там есть ":" для отделения от остальной части.
_NN>Нужно уточнить до деталей и продумать новый синтаксис, чтобы все было гармонично.

Синтаксис должен отталкиваться от возможности автоматической генерации из стандартного.

_NN>P.S.
_NN>Я не совсем понимаю, мы обсуждаем новый синтаксис Nemerle или же вариант с отступами ?
_NN>Если второе, то как было замечено, писать два разных макроса на разные синтаксисы не очень хорошая идея.

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

Z>Кстати. А есть у кого мысли о поддержке отступов в Н2?

Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение.
блок — множество выражений.

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

 macro @if (cond, e1, e2)
  syntax ("if", cond, E1, "else", E2)
  {
    Internal.IfImpl.Impl(cond, E1, E2)
  }

и вся конкретика, связанная с отступами и скобками будет вынесена из макроса.

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


Z>>Кстати. А есть у кого мысли о поддержке отступов в Н2?

_C_>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение.
_C_>блок — множество выражений.

А разве нельзя сегодня отличить блок от выражения в макросе ?

_C_>>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение.
_C_>>блок — множество выражений.

_NN>А разве нельзя сегодня отличить блок от выражения в макросе ?

по моему — нет. из-за этого туда и пролазят скобки, знаки, и прочее, к сути не относящееся.