отнять и поделить

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

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

Автор, вам нужны помощники?

Нужны, конечно.

Што? Шифт+6 перестал работать?

Я забыл причину и неправильно её вспомнил. А всё потому, что черновик документа про синтаксис - не в репозитории и его нет сейчас под рукой. Двоеточие занято под отделитель пакета (пр-ва имён) от собственно имени. Делать его ещё и отделителем типа от имени - более криво, чем перегрузить минус.

И да, они негативно отнесутся хотя бы к тому

Мне рать на твоё мнение. Но не мне, а нас. 1С-у тоже было рать 20 или сколько там лет назад, когда они начинали. Теперь они занимают полквартала на Новослободской. А у тебя есть офис в пределах кольцевой линии метро?

А зачем вообще нужно слово «переменная»?

Это будет С. Паскаль лучше. Его легче парсить, и человеку, и машине. Как это по-умному называется, LL(1) что ли?

А жаль, был бы паскаль-стайл.

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

можна как в коболе -+*/ словами писать

+ и - часто встречаются. А вот * и / - это уже предмет для разговора.

завести здесь всего одну тему «Разработка языка от den73»

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

esrap осиль.

Ты говоришь о технологии написания парсера. Написать парсер абсолютно не является проблемой.

Проблемы совершенно в другом, основная из них - дефицит букв в Русской раскладке.

Ну и хочется, чтобы синтаксис был достаточно приятным на вид, в нём не было ловушек и оставалось место для DSL-ей.

Например, в С++ явно превышена допустимая нагрузка на угловые скобки. Угловые скобки - это сравнения, операторы сдвига и ограничители аргументов шаблона. Такой синтаксис никуда не годится. По сравнению с этим, то, что я перегружаю минус - это просто детская шалость. С амперсандом и звёздочкой тоже не всё славно.

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

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

В 1С вроде всё не так страшно.

Спасибо, что написал это за меня. Плюсую.

переменная А : целое = 5

Чем плохо, кроме непривычности:

переменная А - целая = 5. 

И вот, кстати, а часто ли встречается унарный минус?
В PL/360, например, был neg, и никого это не напрягало.

В объявлении переменных вообще можно обойтись свободным синтаксисом

В C это плохо кончилось.

int *my_very_long_something[5];
int *my_very_long_another(int);

перем my_very_long_something - укль(массив(целое,5));
перем my_very_long_another - укль(фун(цел)->укль(цел));

Я вот понял, что операция деления используется довольно редко. Вот и думаю, не отобрать ли у неё букву и не заменить ли её словом «поделить»?

Зачем? Какая мотивация?

И ещё. Минус у меня получается перегружен, это унарный минус, бинарный минус и операция «это», которая отделяет имя сущности от объявления её типа:

переменная А - целое = 5
С минусом уже есть известная подстава, когда хочешь написать а = б - в, вместо этого пишешь а = -в и компилятор молчит.

То есть унарный минус в идеальном мире должен отличаться от бинарного. К сожалению, здесь ничего сделать нельзя.

Можно. Можно убрать унарный минус. Именно унарный минус нужен крайне редко. А если нужен — всегда можно написать (0 - а). Это отлично читается.

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

Я во всех языках отбиваю знаки арифметических операций пробелами. Но причины такого требования я не понимаю. Ты хочешь использовать дефисы в идентификаторах?

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

Минус унарный можно обозначать подчёркиванием, посмотри на J, там правда _ допускалось только в пределах числа, а '-' был операцией. Ещё можно задействовать юникод, там много математических операторов, ≥ например вместо унылого диграфа.

Спасибо за комментарий! К сожалению, подчёркивание традиционно допустимо в качестве части идентификатора. Юникод...

≠ ≈ ⊕ ʘ ►

Страшновато...

Самое плохое - его непонятно, как набивать на клавиатуре.

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

Вроде основные платформы освоились уже с юникодом. Для бедных можно сделать суррогаты типа &lt. Есть ещё теховский подход, когда пишешь \alpha, а получается α .

Кстати, а может вообще отказаться от ключевых слов? Обозначать всё символами

Я всё же начинал с того, что хотел сделать клон 1С. 1С поступили мудро - они сделали язык достаточно примитивный, чтобы не нужно было большого ума его понять. Если ты программист - тебе всё привычно. Если ты не программист - быстро освоишься. Я хочу тоже так сделать. Язык не должен сильно отличаться от существующих, иначе будет высокий порог вхождения и раздражение с первой минуты. Глядя на Golang или Rust, видим, что люди боятся отступить даже от синтаксиса C.

Минус унарный можно обозначать подчёркиванием

Ни один учёный, инженер на это не согласится. Да и вообще, по-моему, никто не согласится. Лучше уж писать «минус» вместо -, чем _5 вместо -5.

Именно унарный минус нужен крайне редко

Можно просто скопипастить из экселя ряд. А без унарного минуса нельзя. Очень плохо.

Но причины такого требования я не понимаю. Ты хочешь использовать дефисы в идентификаторах?

Вообще, писать-идентификаторы-через-тире на_порядок_удобнее_чем_обивать_мизинцы_о_шифт. АКашаИзБольшихИМаленькихБуквДовольноПлохоЧитается.

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

Речь идёт пока только о идентификаторах типа каталог/пакет:имя . Если требовать отделять деление с помощью пробела, то можно сохранить деление значком. Вероятность накосячить остаётся, но она изрядно мала. А если отделять деление, то логично и остальное отделять. Мне самому идея отделять не нравится. Я спросил для порядка. Вижу, что она никому не нравится. Хотя если будут разные значки в разных пр-вах имён, всё равно придётся отделять:

печ(2 целочисленная_арифметика:+ 2);
печ(2 плавающая_арифметика:+ 2.0);
печ(₽(100) бухгалтерская_арифметика:* 0.82);

А если нужен — всегда можно написать (0 - а)

Ладно, практически убедил.

https://bitbucket.org/budden/l2/issues/5/

Чисто для трнровки:

Пкзатль		= Отбор.Пкзатль.Знчене;
	Если ЗнченеЗполно(Пказтль) Тогда
		Если Пкзатль.ТипПкзатля <> Прчсленя.ТипыПкзатлйСхемМтваци.СумаПкзатля Тогда
			Оргнзаця = Отбор.Оргнзаця.Знчене;
			ПериодДействя	= Отбор.ПериодДействя.Знчене;
			
			ЗпсатьИтогвеЗапси(Пказтль, Оргнзаця, ПериодДействя);
		КнецЕсли;
	КнецЕсли;

Хм, натолкнул меня на мысль. А что если обязывать либо иметь оба бланка вокруг операторов, либо ни одного. То есть не интерпретировать как мат.операцию «а -б» и «а- б» (второе можно вообще запретить). Тогда твои :ключи -ключи /ключи etc. будут однозначны и не будут пересекаться с арифметикой.

Такое впечатление, что ты создаешь эдакий сербский язык в мире программирования. Почитай про него, может, какие идеи почерпнешь :-). Аргументов для обоснования своего видения — точно.

Надеюсь, я правильно описал тип указателя на функцию

:)

int (*pa)[5];
int *(*pf)(int);

http://cdecl.org

пф, делай язык без деления, че как не Ъ

нормальные посоны его все равно не используют

Поэтому компиляторы С на порядок медленнее компиляторов Паскаля.

Афаик, сишке нужно спарсить все инклуды, а паскаль поднимает уже готовые интерфейсы из бинарных tpu. Сложность парсинга тут ни при чем, т.к. эти сишные вложенности это лишние 5-10 терминалов в стеке парсера, только и всего.

Честно говоря, объектная модель восьмерки это полное говно, и сделана она по энтерпрайзному принципу «все есть, на, отъ***сь». Тупо объекты проброшены из крестов или на чем там ее сейчас пишут, никакого сахара, никакой помощи от языка. По сравнению с семеркой, кода теперь в 2-3 раза больше, все состоит из этих тупых перекладываний из пустой структуры в порожнее соответствие.

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

Может тогда использовать «правильное» тире.

--

Если тебе, конечно, не нужен декремент =)

Самое плохое - его непонятно, как набивать на клавиатуре.

Я бы предпочёл Compose key, а вообще множество способов. От общесистемных IME, до редакторов с автозаменой. Можно повесить нужные операторы на AltGr например.

Верно, достаточно умножения на обратный элемент.

Теперь они занимают полквартала на Новослободской. А у тебя есть офис в пределах кольцевой линии метро?

Работать там — большая честь?

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

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

1. У тебя объект от поля отделяется точкой. Точка не может быть в идентификаторе. Зачем тебе принципиально одинарное двоеточие для отделения имени пакета от имени символа. Почему не точка?

Даже если двоеточие для имени пакета можно всё равно использовать для описания типа по критерию: «пакет:символ» или «имя: тип». Если уже речь зашла про значащие пробелы. Для символа первый знак не может быть пробелом.

2. Унарный минус можно аналогично разделять с бинарным. "-2" — унарный "- 2" — ошибка, нет первого аргумента бинарного. К слову, если у бинарного минуса требовать пробел после, то можно нормально использовать имена типа «имя-из-нескольких-слов».

3. Сокращения лучше бы делать про правилам русского языка.

Самое плохое - его непонятно, как набивать на клавиатуре.

Можно как в емаксе — нажимаешь какую-нибудь комбинацию (Ctrl-=, например) и вводишь по имени с автодополнением. Для символов языка можно добавить свои короткие русские имена.

Есть ещё теховский подход, когда пишешь \alpha, а получается α .

Тоже хороший вариант.

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

https://bitbucket.org/budden/l2/issues/6/

Я записал, но слёту кажется, что это будет больше путаницы, чем пользы.

Понял, сербский, болгарский. Можно копать в ту сторону.

Верно, достаточно умножения на обратный элемент.

В программировании правила арифметики не действуют.

Может тогда использовать «правильное» тире.

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

https://bitbucket.org/budden/l2/issues/7/

Во-первых это ОЧЕНЬ не привычно. Во-вторых, без контекста не скажешь, что тут «A - B». А минус Б или А типа Б?

По сравнению с семеркой, кода теперь в 2-3 раза больше, все состоит из этих тупых перекладываний из пустой структуры в порожнее соответствие.

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

Мне рать на твоё мнение. Но не мне, а нас.

Ты забыл принять свои таблетки.

Теперь они занимают полквартала на Новослободской

Макдональдс еще больше занимает и что теперь?

А у тебя есть офис в пределах кольцевой линии метро?

«Сперва добейся»?

Аналогия с макдонольдсом к тому, что если народ жрет какое-то говно, это еще не значит, что оно хорошее. Вспомни что пишут на 1С и кто это пишет. А уж довод «они смогли продать это говно» никак не характеризует их кроме «с маркетингом у них все ок».

От общесистемных IME

http://forum.rudtp.ru/threads/ili-kak-nabirat-neklaviaturnyj-junikod.43962/ - тут как-то не очень жизнерадостно получается.

И вообще, помнить 4 цифры - это мрак.

А есть ли в Линукс типографская раскладка Ильи Бирмана?

Я лично писал кое-что на 7-ке и считаю, что эта программа вполне годная и даже в чём-то хакерская. Мне есть с чем сравнить. В 7-ке есть передача контекста (uplevel из tcl), eval, доработка без перезапуска (#ПрочитатьИзФайла или как оно там пишется), динамическая загрузка кода (через внешние обработки и их программную загрузку). Если чего-то не хватает, всегда можно сделать COM-объект. С помощью COM было нетрудно реализовать для неё RAII, научить обращаться к моей СУБД и моему серверу приложений через сокеты. 1С++ даёт вполне годный эрзац-ООП (записи или структуры, не помню, как они там называются). При этом вполне себе RAD система.

Разрабатывать на ней БД с отчётами и формами получается быстрее, чем на Delphi, пока не попадаешь на задачу, которая не укладывается в их архитектуру БД, которая имеет ограничения. Эти ограничения не от их скудоумия, а это они специально сделали из коммерческих соображений.

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

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

А какая конечная цель? Сделать ЯП который легко читал бы человек?

укль(фун(цел)->укль(цел));

Ага, понятно.

На всякий случай повторюсь - объявление переменных «почти по-русски» не так уж сложно сделать. Вот то что вы написали можно было бы записать в воображаемом ЯП как

моя-переменная указатель на массив целых = 5.
указатель на функцию (целое, указатель на целое) еще-переменная.

Здесь не видно неоднозначностей, единственная сложность в требовании для типов указывать его в разных падежах

Впрочем, в унарном минусе (и унарном плюсе) и разборе операторов без пробелов тоже ничего особо сложного

Тогда зачем ломаешь почти все привычки? Минус как разделитель, >нестандартные сокращения, ...

Странно слышать это от лиспера :)

У тебя объект от поля отделяется точкой. Точка не может быть в >идентификаторе. Зачем тебе принципиально одинарное двоеточие для >отделения имени пакета от имени символа. Почему не точка?

Потому что я хочу оставить место для иерархических пакетов. Тогда будет непонятно, что есть а.б.в - а.б:в или а:б.в. В теме Модульность-3 я осознал, что над пакетами (модулями) есть ещё один уровень, который отвечает за «библиотеки» или «системы» (как группы модулей), в т.ч. за их размещение в файловой системе.

Естественно, надо, чтобы можно было опускать текущую библиотеку и текущий пакет. В этом случае совсем непонятно, что такое а.б.в.г - есть ли в нём имя библиотеки, и имя пакета или это просто цепочка полей. Можно сделать библиотека:пакет:имя . Тогда возникает некоторая неоднозначность - что такое а:б - это библиотека:пакет, пакет:имя или, не приведи Бог, библиотека:имя?

Можно не париться, конечно, и считать, что а:б - это всегда пакет:имя, а:б:в - это всегда полное имя, а библиотка:пакет писать как пакет(библиотека,пакет).

Но остаётся какая-то эстетическая неудовлетворённость от такого решения.

Чтобы избавиться от неоднозначности, нужно два _разных_ разделителя:

библиотека/пакет:имя.

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

2. Унарный минус можно аналогично разделять с бинарным.

Значащие пробелы мне не нравятся - их плохо видно.

3. Сокращения лучше бы делать про правилам русского языка.

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

Вот давай не надо. Я сама дочь интегратора, поверьте, не все так однозначно.

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

Что там делать-то?

#define целое int
#define начало main
#define пусто void
#define напечатать printf
#define вернуть return

целое начало(пусто)
{
    напечатать("Привет, мир!\n");
    вернуть 0;
}

А какая конечная цель? Сделать ЯП который легко читал бы человек?

укль(фун(цел)->укль(цел));

Ага, понятно.

Ты некорректно цитируешь. Вторая строчка не является ответом на первую. Я понял твои предложения, но они были отвергнуты в самом начале разработки. Имея возможность сравнить С и Паскаль, я вижу, что Паскаль намного легковеснее. Он читается слева направо и его сообщения об ошибках гораздо понятнее. Это повышает производительность труда.

https://ru.wikipedia.org/wiki/LL(1)

Впрочем, в унарном минусе (и унарном плюсе) и разборе операторов без пробелов тоже ничего особо сложного

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

Всем спасибо за участие. Пора заняться работой, подведу промежуточные итоги: 1. Унарный минус будет только в числовых константах (спасибо ya-betmen и Legioner),

2. Прошу администрацию ввести тег «Кодица» и обязуюсь помечать им свои темы про языка (спасибо Psych218 alexferman).

3. Все операции должны будут отделяться от ближайших идентификаторов разделителями. Если нет иных разделителей - то белым полем(whitespace).

4. Черновик использования юникода:

Допустимыми для идентификаторов из букв являются только буквы кириллицы и латиницы.

Появляется новый вид пакета - пакет «сокращение». Сокращения действуют только при отображении кода на экране и не находятся в исходном тексте. Пакет «сокращение» содержит набор определений сокращения. Каждое сокращение сопоставляет полному имени символа одиночный спецзнак юникода (математический, инженерный, финансовый), с кодом > 256. Правила экспорта и наследования для сокращений - такие же, как для символов. Пакеты сокращений могут наследоваться так же, как обычные и реэкспортирующие. (спасибо Legioner).

5. Операция деления будет обозначаться словом. Знак «/» будет отделять имя библиотеки от остальной части идентификатора.

6. Также спасибо Monk за ссылку на правила сокращения Русского языка.