> aka ©   (09.02.17 23:51) [59]

На соревнованиях по спортивному ориентированию один спортсмен бежал намного быстрее другого спортсмена, но все равно ему проиграл. На недоуменный вопрос "как же могло так получиться?" второй спортсмен ответил: "Ты нарушил главное правило - не беги быстрее, чем думает твоя голова".

А гонщики говорят так: "Нельзя ехать быстрее, чем тебе позволяют твои тормоза".

Понимаете, о чем я?
:o)

> Понимаете, о чем я?
> :o)

Конечно понимаю, но такая тактика тоже оправдана и так я делал не раз. Сначала забегал вперед в "неизвестность" осмысляя основные моменты, а вторым заходом переписывал все на чистовик.

Но что конкретно люди думают по поводу [55],[57], так пока и не услышал

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

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

> aka ©   (10.02.17 09:10) [61]

> Но что конкретно люди думают по поводу [55],[57], так пока
> и не услышал

А между ответ уже был в [56].

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

* А между тем ...

>Юрий Зотов ©   (10.02.17 00:06) [60]

А имеется в природе литература, в которой подробно описан процесс создания именно интерпретаторов? Только полноценных, а не "2+2 работает, а дальше по аналогии". Так чтобы с пользовательскими функциями и т.д. От самого начала и до полного завершения, а не до уровня окончания синтаксического разбора. Вот по компиляторам есть несколько, а по интерпретаторам не встречал.

> Сергей Суровцев ©   (10.02.17 10:03) [65]

Я тоже не встречал.

Сергей Суровцев ©   (10.02.17 10:03) [65]

Начать с того, что по своей сути интерпретатор от компилятор несильно отличается.

У Шилдта был пример разработки интерпретатора Basic.
Герберт Шилдт, Язык программирования С, какое-то очень древнее издание.

> Сергей Суровцев ©   (10.02.17 10:03) [65]


> Вот по компиляторам есть несколько, а по интерпретаторам
> не встречал.

Сильно не интересовался, меня больше компиляторы интересовали.

Не совсем. Есть книга "Практическое программирование на Tcl и Tk" в нём описывается устройство интерпретатора с использованием пользовательских функций и процесс их внесения в интерпретатор. Грамматический анализатор там тоже описан, благодаря простой грамматики он там занимает менее 1000 строк.

Но я вам советую обратить внимание на цикл статей "@tyomitch"
https://habrahabr.ru/users/tyomitch/topics/page5/

>aka ©   (09.02.17 23:11) [55]
По итогу унарный минус должен быть один. Перед выражением.
Игры с "-- = +" до добра не доведут.
Здесь есть момент восприятия:
--х что это
1) префиксный декремент
2) сложение унарных минусов в плюс
3) ошибка ввода

А варианты интерпретации:
---х даже представить страшно

Все операции с изменение знака через умножение на "-1".

А вещи типа: ";;;;" просто проглатывать как пустые строки.
Только помните, что когда выдаете сообщения об ошибке в такой-то строке, пустые строки с переводом строки тоже надо считать.

> [69] Сергей Суровцев ©   (10.02.17 10:26)
> --х что это
> 1) префиксный декремент
> 2) сложение унарных минусов в плюс
> 3) ошибка ввода

Именно 1, если приоритет у него выше, а ниже делать его не надо, чтобы не было ещё много неясностей помимо 2 и 3..

> [69] Сергей Суровцев ©   (10.02.17 10:26)
> А вещи типа: ";;;;" просто проглатывать как пустые строки

Типа отдельно их что ли обрабатывать? Нафига?

Ну и с унарный минус имножением заменять неразумно, к тому же унарный минус у -1*x придётся тоже отдельно обрабатывать? Или в числах не считается - числа исключение?:)

>Inovet ©   (10.02.17 10:54) [70]
>Именно 1,

Естественно это префиксный декремент, если таковой вообще предусмотрен в спецификации данного языка. А если нет? А если, как выясняется: "спецификация потом :)"

>aka ©   (09.02.17 23:11) [55]
>а := --b {что дает плюс}

>Inovet ©   (10.02.17 10:57) [71]
>Типа отдельно их что ли обрабатывать? Нафига?

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

>Ну и с унарный минус имножением заменять неразумно
Естественно неразумно. Поэтому этого никто и не предлагает. Предлагается запрет как таковой на 2 подряд унарные операции.

>Игорь Шевченко ©   (10.02.17 10:16) [67]
>Pavia ©   (10.02.17 10:18) [68]

Спасибо за информацию.

>Игорь Шевченко ©   (10.02.17 10:16) [67]
>Начать с того, что по своей сути интерпретатор от компилятор несильно отличается.

В общем и целом да, до какого-то момента и вообще не отличаются. Но дальше "дьявол в деталях".

>Inovet ©   (10.02.17 10:54) [70]
x = 5;
---x:
--(-x) = -6
-(--x) = -4

----x = ?
---------------------x = ????????????
Конечно, все это можно обрабатывать. Академически. Но нафига? Для нормального языка возможность такой конструкции без ошибки - зло.

> [74] Сергей Суровцев ©   (10.02.17 11:40)
> Для нормального языка возможность такой конструкции без
> ошибки - зло.

Первое не зло, но не надо так делать, 2 и 3 и так ошибки - куда присвоение происходит?
Ну и отдельно
--(-x)
----x
---------------------x
Хоть и не ошибка, но тоже не надо так делать.

>Inovet ©   (10.02.17 12:00) [75]
>2 и 3 и так ошибки - куда присвоение происходит?
Это же не готовый код, а пример вариантов восприятия.

>Хоть и не ошибка, но тоже не надо так делать
А вот это уже не разговор.
"Мы написали язык, в котором вы можете использовать такую вот косячную конструкцию, но убедительно вас просим - не надо так делать"

В языке все должно быть предельно понятно и лаконично. Любая конструкция нужна для определенной цели, прозрачна, однозначна в восприятии и исполнении. Если заранее известно что "не надо так делать", значит не надо давать возможности "так делать".

> В языке все должно быть предельно понятно и лаконично. Любая
> конструкция нужна для определенной цели, прозрачна, однозначна
> в восприятии и исполнении. Если заранее известно что "не
> надо так делать", значит не надо давать возможности "так
> делать".

В чем и вся суть вопроса [55]


> Pavia ©   (10.02.17 09:35) [62]
> Глупости говорите. Вам для разбора выражений нужен автомат
> с магазинной памятью. А там один минус или десять нет никакой
> разницы.

Зачем эти отступления? Все это понятно. Но был конкретный вопрос - разрешать или нет городить ненужный огород из минусов. Разницы автомату нет, но можно ограничится одним, более одного = ошибка.

>--(-x) = -6
>-(--x) = -4
1 минус достаточно (имхо). Неужели есть практика необходимости в большом кол-ве минусов? Ведь всего 2 варианта или минус или нет.

>aka ©   (10.02.17 13:10) [77]

Дело не в минусах. А в операциях. --х судя по Сишному синтаксису интерпретатора тоже предполагается. Как и ++х. Дело в том, чтобы не разрешать 2 и более подряд унарных операций. Кому сильно надо, есть скобки.