#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 — |> . как на это реагировать?
этим топиком хочу указать на недоработку — в продвинутых языках, поддерживающих отступы,
если последним в строке идет оператор, то следующая строка, с отступом или нет, — продолжение.
_C_>>в варианте 1 AST-рутом оказывается !> что логично. _C_>>в варианте 2 — |> . как на это реагировать?
_C_>этим топиком хочу указать на недоработку — в продвинутых языках, поддерживающих отступы, _C_>если последним в строке идет оператор, то следующая строка, с отступом или нет, — продолжение.
Поддержка отступов в Nemerle вещь второстепенная.
Нужно улучшать, но вопрос как всегда кто будет делать.
Более того, нужна эвристика чтобы писать поменьше "\" в конце строк.
В случаях атрибутов, macro — syntax и т.п.
Здравствуйте, _NN_, Вы писали:
_NN>Поддержка отступов в Nemerle вещь второстепенная.
Кстати. А есть у кого мысли о поддержке отступов в Н2?
Если препроцессор, то такие проблемы обеспечены. Писать отдельный парсер, в нем не будут работать стандартные синтаскические макры.
Нужна ли поддержка отступов в таком виде как сейчас? Как костыль прикрученный сбоку, требующий отдельной поддержки в интеграции (которой никто не хочет заниматься) и не очень логично работающий.
Вообще, при нормально поддержке, я бы писал на отступах, код сильно чище получается. Особенно если сделать еще и скобки опциональными (то есть их необходимо ставить только в тех случаях, когда без них получается неоднозначность).
Пишу сейчас на руби, такой подход очень радует.
Мне кажется, задача универсальной поддержки решаема на пеге. Для поддержки отступов должен генериться отдельный парсер. Для поддержки опциональных скобок, достаточно определить их парность в грамматике. Если они парные, то открывающую делать опциональной, а при отсутствии открывающей контролировать обязательное отсутствие закрывающей. С точкой с запятой в этом режиме поступать тоже просто, если ее надо заменять на правило (";"/"\n")
foreach x in [1, 2, 3]
WriteLine x
match x
1 => true
_ => false
Вероятно, что у меня сейчас глаз "испорчен" ruby, и вас этот код выглядит плохо читаемо, но, уверяю, что попробовав оба стиля, вы не выберете стиль со скобками, блоками {} и обязательной точкой с запятой по своей воле.
Re[4]: приоритет оператора зависит от переноса
От:
Аноним
Дата:
15.02.12 06:58
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Вероятно, что у меня сейчас глаз "испорчен" ruby, и вас этот код выглядит плохо читаемо, но, уверяю, что попробовав оба стиля, вы не выберете стиль со скобками, блоками {} и обязательной точкой с запятой по своей воле.
Может тогда проще хранить текст в виде аст и при открытии показывать в соотвествующем стиле?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _NN_, Вы писали:
_NN>>Поддержка отступов в Nemerle вещь второстепенная.
Z>Кстати. А есть у кого мысли о поддержке отступов в Н2?
По ссылкам обсуждение такого синтаксиса в Н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 или же вариант с отступами ?
Если второе, то как было замечено, писать два разных макроса на разные синтаксисы не очень хорошая идея.
Здравствуйте, _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?
_C_>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение. _C_>блок — множество выражений.
А разве нельзя сегодня отличить блок от выражения в макросе ?
_C_>>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение. _C_>>блок — множество выражений.
_NN>А разве нельзя сегодня отличить блок от выражения в макросе ?
по моему — нет. из-за этого туда и пролазят скобки, знаки, и прочее, к сути не относящееся.
_C_>>>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение. _C_>>>блок — множество выражений.
_NN>>А разве нельзя сегодня отличить блок от выражения в макросе ?
_C_>по моему — нет. из-за этого туда и пролазят скобки, знаки, и прочее, к сути не относящееся.
В таком случае нужно дать формальное определение "выражению".
Чтобы понять как их отличать.
Z>>Кстати. А есть у кого мысли о поддержке отступов в Н2?
_C_>Повторю, что предлагал раньше. В грамматике должны быть две различимые категории — блок и выражение. _C_>блок — множество выражений.
_C_>тогда, к примеру, если мы условимся писать имена блоков с большой, а выражений с маленькой, макросы будут такими
Совершенно не вижу смысла.
Как это вижу я. Нужна псевдо-грамматика зависящая от контекста:
увеличение отступа обрабатываем как "{" если в данном месте разбор обрывается полным правилом, возвращающим Expr и следующим правилом идет Expr.
увеличение отступа обрабатываем как " " если в данном месте ожидается Expr.
уменьшение отступа обрабатываем как ";" если предыдущее увеличение было по правилу b.
в ином случае уменьшение отступа обрабатываем как "}" и раскрываем получившийся сиквенс если он содержит одно выражение
перевод строки с сохранением отступа обрабатываем как ";"
Только я не вижу способов определить условия в вариантах a и b оставаясь в рамках приоритетного выбора.
Здравствуйте, _Claus_, Вы писали:
_C_>2Wolfhound: что проще, мой вариант, или Ziaw?
А какую задачу решает твой вариант? Места в грамматике, где должен разбираться Expr и так известны. По типу макроса. Соглашения об именовании тут ничего не дают.
Z>А какую задачу решает твой вариант? Места в грамматике, где должен разбираться Expr и так известны. По типу макроса. Соглашения об именовании тут ничего не дают.
Моя концепция универсальна и проста и в использовании, твой подход — ad hoc для конкретной ситуации — и только.
кто-то захочет другие скобки или метки для блоков, даже в N — макроблоки выражений, то придется навернуть еще описания и кода.
внутри квазицитат отступы не работают. со мной заработают
все должно быть универсальным.если возможно. и просто в реализации. в твоем описании не реализуется тема топика, в моем — и вспоминать не надо. я так вижу.
Z>>А какую задачу решает твой вариант? Места в грамматике, где должен разбираться Expr и так известны. По типу макроса. Соглашения об именовании тут ничего не дают.
_C_>Моя концепция универсальна и проста и в использовании, твой подход — ad hoc для конкретной ситуации — и только.
Ты нормально опиши концепцию-то. У тебя дальше выделения блоков тема не раскрыта. Основная проблема не в этом. Почти с таким же успехом можно ориентироваться на выражения. Если не ошибаюсь, блоки всегда идут последним выражением либо выражением перед ключевым словом. Это можно вычислить по идее.
_C_>кто-то захочет другие скобки или метки для блоков, даже в N — макроблоки выражений, то придется навернуть еще описания и кода. _C_>внутри квазицитат отступы не работают. со мной заработают _C_>все должно быть универсальным.если возможно. и просто в реализации. в твоем описании не реализуется тема топика, в моем — и вспоминать не надо. я так вижу.
Твоя концепция конечно проста, только она не делает то, что нужно. Нужно по готовой C-style PEG грамматике генерить python/ruby-style парсер.
Один из минусов твоего решения, в том, что оно специально пишется, чтобы работало под обе грамматики. Этого никто делать не будет.
И вообще, то, что приводишь как пример, это описание синтаксиса в N1. Не PEG.
Z>Ты нормально опиши концепцию-то. У тебя дальше выделения блоков тема не раскрыта.
дальше все как обычно.
Z>Основная проблема не в этом. Почти с таким же успехом можно ориентироваться на выражения. Если не ошибаюсь, блоки всегда идут последним выражением либо выражением перед ключевым словом. Это можно вычислить по идее.
не понимаю как это вычислить. ожидание блока и выражения — совсем разные вещи.
Z>Один из минусов твоего решения, в том, что оно специально пишется, чтобы работало под обе грамматики. Этого никто делать не будет.
я рассчитывал, что декларируемая модификация грамматики позволяет на лету править синтаксис блоков и выражений.
если нет — то парсер не один, конечно. но это будет грустно.
Z>И вообще, то, что приводишь как пример, это описание синтаксиса в N1. Не PEG.
я описал концепцию, которая решает поставленные задачи (-скобки () {} + отступы), при условии, описанном выше. а как ее вписать в PEG, лучше скажет спец по PEG.
мои парсеры работают по старой традиционной схеме (не PEG).
Здравствуйте, _Claus_, Вы писали:
Z>>Ты нормально опиши концепцию-то. У тебя дальше выделения блоков тема не раскрыта.
_C_>дальше все как обычно.
Подробнее.
_C_>не понимаю как это вычислить. ожидание блока и выражения — совсем разные вещи.
Ожидание блока это ожидание выражения если оно последнее в правиле, либо за ним может идти ключевое слово.
_C_>я рассчитывал, что декларируемая модификация грамматики позволяет на лету править синтаксис блоков и выражений. _C_>если нет — то парсер не один, конечно. но это будет грустно.
Эту модификацию должен будет делать (и понимать, что и зачем он делает) каждый программист пишущий макросы. Им и без этого головняков хватает.
_C_>я описал концепцию, которая решает поставленные задачи (-скобки () {} + отступы), при условии, описанном выше. а как ее вписать в PEG, лучше скажет спец по PEG. _C_>мои парсеры работают по старой традиционной схеме (не PEG).
В данной подветке идет обсуждение возможности поддержки отступов в N2. Там точно будет PEG и ничего другого.
Здравствуйте, Ziaw, Вы писали:
Z>В данной подветке идет обсуждение возможности поддержки отступов в N2. Там точно будет PEG и ничего другого.
1)От PEG'а там уже мало что осталось. Алгоритм получился очень сильно другим.
2)Вы оба исходите из неверного предположения, что будет два вида синтаксиса. На скобках и на отступах.
Но бывают и другие виды синтаксиса. Например, XML или оберон. И Н2 обязан их поддерживать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>2)Вы оба исходите из неверного предположения, что будет два вида синтаксиса. На скобках и на отступах. WH>Но бывают и другие виды синтаксиса. Например, XML или оберон. И Н2 обязан их поддерживать.
золотые слова! именно для этого и нужна концепция выделенных блоков и выражений. упрощает она обращение с видами синтаксиса,
скрывая их детали.
спрашивай, не знаю я, что непонятно.
_C_>>не понимаю как это вычислить. ожидание блока и выражения — совсем разные вещи.
Z>Ожидание блока это ожидание выражения если оно последнее в правиле, либо за ним может идти ключевое слово.
если ты прав, то в N1 можно написать if макрос 1 в 1 как в Ruby c отступами. попробуй.
_C_>>я рассчитывал, что декларируемая модификация грамматики позволяет на лету править синтаксис блоков и выражений. _C_>>если нет — то парсер не один, конечно. но это будет грустно.
Z>Эту модификацию должен будет делать (и понимать, что и зачем он делает) каждый программист пишущий макросы. Им и без этого головняков хватает.
в моем противоречивом мире, — то, что может сделать компилятор, не должен делать программист. поэтому, возможно, разница во взглядах у нас определяется идеологией. не логикой.
Z>В данной подветке идет обсуждение возможности поддержки отступов в N2. Там точно будет PEG и ничего другого.
что бы там ни было, — то, что элементарно описывается в N1 не должно ставить в тупик в N2.
я исходил из этого.
Здравствуйте, WolfHound, Вы писали:
WH>1)От PEG'а там уже мало что осталось. Алгоритм получился очень сильно другим.
Вы бы хоть делились, интересно же.
WH>2)Вы оба исходите из неверного предположения, что будет два вида синтаксиса. На скобках и на отступах. WH>Но бывают и другие виды синтаксиса. Например, XML или оберон. И Н2 обязан их поддерживать.
Я лично исхожу из того, что парсер Nemerle на отступах надо не писать отдельно, а как-то генерить. Если конечно, синтаксис на отступах не будет упразднен. Что будет печально, я убежден, что при нормальной поддержке, большинство пишущих сейчас на немерле писали бы на нем.
Почти все популярные OSS языки склоняются к отмене фигурных и прочих скобок, которые являются костылями парсеру Ruby,Python,CoffeScript,Haskell,Ocaml.
Здравствуйте, _Claus_, Вы писали:
_C_>спрашивай, не знаю я, что непонятно.
Да ничего не понятно. Как будут парситься скобки в скобочном синтаксисе, например?
Z>>Ожидание блока это ожидание выражения если оно последнее в правиле, либо за ним может идти ключевое слово. _C_>если ты прав, то в N1 можно написать if макрос 1 в 1 как в Ruby c отступами. попробуй.
Неожиданный вывод. Какое отношение имеют возможности Н1 к обсуждению?
_C_>в моем противоречивом мире, — то, что может сделать компилятор, не должен делать программист. поэтому, возможно, разница во взглядах у нас определяется идеологией. не логикой.
А в моем противоречивом мире не принято есть детей, разница идеологий налицо.
Z>>В данной подветке идет обсуждение возможности поддержки отступов в N2. Там точно будет PEG и ничего другого. _C_>что бы там ни было, — то, что элементарно описывается в N1 не должно ставить в тупик в N2. _C_>я исходил из этого.
Что элементарно описывается-то? В Н1 ничего не описывается, парсер индент синтаксиса работает как препроцессор.
