SOL (Соль) = Simple Objects Language

← →
Vladimir Kladov © (2007-12-27 15:28) [120]

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

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

С циклами, я так понял, возражений нет: параметр цикла в функции может быть только параметром функции и использоваться на чтение, но внутри цикла может быть присвоен тремя способами:
i LOOP = выражение;
CONTINUNUE i LOOP = выражение;
BREAK i LOOP = выражение;

Мой аргумент, что отсутствие необходимости вводить дубликат параметра цикла уменьшает ошибки. А эффективность не страдает - если переменную цикла не менять внутри.

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

← →
Vladimir Kladov © (2007-12-27 18:53) [121]

Меня "вдохновляет" на отказ от объявлений опыт самого успешного языка всех времён - Фортрана. Я сам писал на Фортране, и чесное слово - никаких проблем из-за того, что не надо было объявлять простые переменные (массивы надо было, конечно) - не было вообще. Было только правило присвоения типа переменным по умолчаню: всё, что начинается на I,J,K,L,M,N - целые, прочие - вещественные. Раз у меня таких правил нет, нужны немного другие. Вот я и ввожу - тип переменной - по тому что ей присваивается, какими операциями с ней манипулируют, в каких случаях она используется.

← →
D[u]fa (2007-12-28 13:44) [122]

хоть на СИ и не пишу, но мне в нем нравится что можно объявить переменную и сразу присвоить ее..

← →
Vladimir Kladov © (2007-12-28 16:58) [123]

Если я не ошибаюсь, в чистом C так сделать нельзя всё-таки. Но объявлять можно в блоке, а не только в начале функции. И при этом (что глупо, и точно приводит к ошибкам, создавать новую переменную с таким же именем). Хотя я могу и приврать: давно на С серьёзно не работал.

← →
Vladimir Kladov © (2008-01-02 11:11) [124]

С Новым Годом!
В новой версии описания вводится принцип синтаксического нигилизма: теперь блоки могут оформляться в 4 разных стилях: SOL, Ада-Оберон, Алгол-Паскаль, Си-Ява-Ди. Но это всё синтаксический сахар. Главное: пришлось добавить понятие параметризованного типа. Правда, ограничился одним параметром (тоже типом) Понадобилось чтобы можно было определить List(Data) от произвольного типа Data. Кажется, это называется статический полиморфизм типов. Ну лишь бы работало, как называется - не важно.

Большое описание стало великовато, разбил на 2 части. В принципе, сейчас и краткое вполне подробно, достаточно для основного значкомства:
http://kolmck.net/sf/SOL%20-%20short%20(but%20not%20very%20short)%20description.htm

(в архиве оно тоже есть).

← →
misha_shar © (2008-01-06 16:08) [125]

Хотел высказаться по поводу организации потоков. По моему
принятая в описании схема правильна. Правда в терминах ОС это уже не
потоки а задачи. С моей точки зрения данные в потоке безусловно должны
быть локализованы. Такая схема применяется в MUMPSe и она себя

полностью оправдывает. Там есть команда JOB которая запускает поток.
А необходимые данные передаются как фактические параметры в процедуру.
В MUMPSe запуск потока и вызов процедуры почти ничем не отличаются.

Кстати по моему и локализовать данные можно тем же механизмом что и при
вызове процедуры в стеке. Вот только удобного механизма отладки потоков

я не встречал, а проблема серьезная.

← →
Vladimir Kladov © (2008-01-06 21:19) [126]

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

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

← →
Yhrik! (2008-01-08 13:54) [127]

> Меня "вдохновляет" на отказ от объявлений

я меня пугает...
всё-таки мож добавить хоть какими-нибудь директивами препроцессора (хоть как-нибудь!), и при желании сообщение "не объявленная переменная", пусть даже ошибки не будет возникать.

← →
Vladimir Kladov © (2008-01-08 15:06) [128]

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

← →
Vladimir Kladov © (2008-01-08 17:03) [129]

Вставил ещё кусочек текста.

У современного поколения программистов отсутствие необходимости объявлять переменные способно вызвать страх уровня фобии. Причина, видимо, в том, что они с самого начала своей программистской карьеры оказались в ситуации чрезвычайно "скользкого паркета". В современных объектных языках вроде Object Pascal (Delphi) или C++ ситуация действительно такова, что стоит убрать правило, заставляющее объявить простые локальные переменные, и "ноги повиснут в пустоте" практически без опоры. Первопричина - в таких правилах определения областей видимости имён переменных, полей структур, при которой из одного только имени нельзя сказать, является ли оно локальной, глобальной переменной, параметром функции, константой, именем процедуры, метода объекта или полем класса (если текущая функция - это метод класса). И ничего нельзя сказать до тех пор, пока не будет обнаружено ближайшее сверху (в области видимости) объявление.

Мы как-то приспособились к этому правилу, и уже не представляем себе, что может быть по-другому. А по-другому может быть, и даже уже было. Язык Фортран, между прочим, существует до сих пор. А в нём не было необходимости объявлять простые переменные, и написано огромное количество программного обеспечения, и оно используется до сих пор. Вся штука (или шутка, как хотите) в том, что правила области видимости придуманы, чтобы быть удобными не для людей, а для компиляторов. И это, по крайней мере, не разумно. Человеку неудобно держать в голове, читая небольшой фрагмент программы, всю "матрёшку" областей видимости, распространяющуюся от этого фрагмента вверх, учитывая при том и все глобальные имена, и все имена полей и методов объекта (когда читается тело метода).

Но стоит в методе устранить всего лишь обращение к полям своего объекта "по умолчанию", и возможность обращаться к глобальным переменным без указания спецификации модуля (в виде МОДУЛЬ.ПЕРЕМЕННАЯ), и запретить опускать скобки при вызове процедуры или функции даже в случае отсутствия фактических параметров ( foo() ), и у нас остаются только именованные константы, локальные переменные и имена параметров, именуемые простыми (а не составными) идентификаторами. Константы легко выделить, например, соглашением об именовании их только в верхнем регистре (например PI, или INVALID_HANDLE_VALUE), у параметров есть описание в начале функции, и остаются только локальные переменные. И зачем нам тогда их предварительно объявлять? "На память" о прошлых фобиях "скользкого пола"?

← →
Vladimir Kladov © (2008-01-08 17:14) [130]

English (new) version of the SOL specification is available at:
http://kolmck.net/sf/SOL-EN-description.htm

← →
D[u]fa (2008-01-08 17:39) [131]

да в принципе пох.. нужно объявлять их или нет.. но как компилятор поймет, что нужен определенный тип переменной?

к примеру сделаю я:

i := 0;
и потом то то типа .....(i, sizeof(i));

и как он поймет что мне надо именно Integer тот что 4 байта?)

или придется отказаться от таких конструкций?

← →
Efir (2008-01-08 19:05) [132]

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

← →
D[u]fa (2008-01-08 19:09) [133]

дык о том речь и идет. что как предлагает Владимир не объявлять локальные переменные. Я то знаю что мне надо, а вот компилятор телепатить будет что ли =)

← →
homm © (2008-01-09 00:11) [134]

> [131] D[u]fa (08.01.08 17:39)
> к примеру сделаю я:
>
> i := 0;
> и потом то то типа .....(i, sizeof(i));
>
> и как он поймет что мне надо именно Integer тот что 4 байта?)

> [77] Vladimir Kladov © (23.12.07 17:46)
> Что такое sizeof, зачем он вообще нужен и с чем его едят
> в языке, в котором размером данных занимается компилятор
> и самый нижний уровень программирования?

← →
D[u]fa (2008-01-09 10:53) [135]

собсно и?)

sizeof это константа, которую компилятор и вычисляет(в делфях я имею ввиду)

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

← →
homm © (2008-01-09 11:42) [136]

> [135] D[u]fa (09.01.08 10:53)
> опять ж как он узнает размер?

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

← →
Vladimir Kladov © (2008-01-09 15:46) [137]

sizeof бывает нужен в языках с адресной арифметикой. В SOL нет адресной арифметики, вообще. Некоторые вещи могут казаться странными. Отсутствие деклации типа данных - это совсем не то же самое, что в JScript, когда переменная принимает тот тип, какой захочется. Это не вариант но формально - что-то вроде него. Казалось бы, могут возникнуть проблемы если одной и той же переменной присваивать и строку, и число. Но - не возникнут. Потому что агрегаты (массивы, структуры) - всё-таки отличаются от простых переменных. И объявлять их (хотя бы размерности массивов или число размернойстей) - придётся. А с числовыми - пусть компилятор выберет лучшее представление. Я вобще думаю для простого варианта компилятора рассмотреть штуки 4 целых форматов (int64, int32, uint8, uint1), и пару-тройку вещественных (flt32, flt64, flt80), и этим обойтись пока. Лучше сделать упор на возможность разрабатывать свои "классы" чисел, чтобы можно было делать программ для нестандартных процессоров (типа 4-битных контроллеров).

Сегодня опять "придумал" фишку. На этот - как однозначно "победить" проблемы возможного недопонимания переопределённых операций над структурными типами и массивами. Надо писать A = A [+] B; И всё - проблема исчезла. Вот почему, например, Вирт не хотел в Обероне переопределять арифметику: он не желал получить проблем с двусмысленностью. Всё, двусмысленности нет. (Разумеется я предусматриваю исключение для функций-шаблонов, в которых параметры не доопределены).

Про 4 нотации читали уже? Я сегодня выкладываю новую версию описания. Хорошо, что написание кода синтаксического разбора ещё не очень далеко продвинулось. Ещё кое-что уточняется, мелочи вроде Ptr1 SOLE = LOOP Ptr2; появляются (точная спецификация вида указателя которому и от которого присваивание идёт).

← →
Yhrik! (2008-01-10 21:41) [138]

> Просто вы не писали на Фортране

Ну... на Васике писал, на 1с и т.п.
Ладно, переживём отсутствие предупреждений на не объявленные переменные. В крайнем случае, можно lint написать.
Прочитал описание (пока недостаточно внимательно). Очень неплохо. Хотя немного напрягло большое количество вариантов синтаксиса. Трудно для освоения, но это тоже не беда. :)) Да! кстати, это нарушает правило "50.Не путайте привычность с читаемостью" (Ален И. Голуб. С и С++ Правила программирования М:Бином 1996). Думаю лучше основной синтаксис привести в наиболее читаемый вид. В перспективе подготовить рекомендации по оформлению текстов программ.
А в целом достойно.
Желаю Вам Владимир творческих успехов.

← →
Vladimir Kladov © (2008-01-11 19:42) [139]

Я думаю, вы меня поймёте лучше, если 7 лет подряд будете писать только на С/C++/Java/JScript, потом лет 7 подряд только на Паскале, а потом снова попробуете что-нибудь написать на С/C++. Становится невозможно не только писать, но и прочитать - проблема. Я же не заставляю учить ВСЕ 4 варианта синтаксиса. Наоборот, делается конвертер, и каждый изучает только тот вариант, который ему ближе. Открываете чужой модуль в редакторе, а он автоматически перестроен к вашей любимой нотации.

Я обновляю. Also english version of a comparison SOL vs others available now: http://kolmck.net/sf/SOL_vs_others-EN.htm

Из последних изменений: [+] и другие знаки в квадратных скобках - для операций с массивами, аналогично (+) и т.п. - для переопеределённых операций. Кроме шаблонов функций. Дальше: тип результата :NIL для процедуры, т.е. функция, ничего не возвращающая, описывается явно. Дальше: все перегруженные функции должны иметь номер версии. Не перегруженные тоже могут иметь номер версии.

Да, запретил для безблочных вариантов цикла и IF вариант с пустым оператором. С пустым блоком - можно. И язык переименовал: Safe Objective Language. А то на Simple уже немножко не дотягивает. Но пока достаточно простой всё ещё.

← →
Vladimir Kladov © (2008-01-11 22:25) [140]

Не получилось сразу обновить. Сейчас только обновил.

← →
D[u]fa (2008-01-13 10:42) [141]

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

зы. имхо конечно

← →
Vladimir Kladov © (2008-01-13 17:59) [142]

Сложно потому только что я лично не писал до сих пор полных компиляторов с полных ЯВУ, в основном ассемблерами баловался (правда, один раз в молодости месяца за 3 получился рабочий компилятор с подмножества С в П-код, но это можно объяснить только невероятной наглостью: я же не знал что это так сложно). А так, в принципе, ничего сверх-сложного. Вполне сравнимо с Паскалем и наверняка проще С++. Пока пишу синтаксический анализатор. Даже 4 нотации не так сложны, как можно было бы подумать. Сейчас впереди вижу одну больую сложность: надо как-то реализовывать вычисление константных функций на этапе компиляции, т.е. фактически как бы компилировать код, вызывать его на выполнение, и результат использовать всё ещё в компиляторе. Получается, что эта часть компилятора - сама платформо-зависимая (код ведь должен быть выполнимым на той же платформе где запущен сам компилятор). Для полной платформо-независимости можно сделать свой П-код, специально для этого этапа, и эмулятор П-машины. Это если что.

← →
speller (2008-01-14 13:54) [143]

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

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

Нет, не выброшу. Это можно сказать треть всех инноваций. Кстати, я язык переименовал. Хоть я и стремился сделать как можно проще (и надеюсь, что это вышло почти), надёжность дороже. Константные функции дают очень много, в том числе для надёжности. Ведь вычисление происходит (в случае константного аргумента) - во время компиляции, а не во время выполнения Недостаток времени выполнения в том, что до вычисления, при котором всё ломается, во время тестирования, может и не дойти. А если константа - вычислится всегда.

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

← →
DmitrtyAx (2008-01-19 02:54) [147]

Владимир!! Успехов! Очень долго читал, и пока только общие впечатления - настоящая поэма! Правда основание слишком широкое - мультиплатформенность при всех заявленых опциях... Огромное количество библиотек для разных процессоров, отладка на виртуальной машине(ах)... Библиотеки под разные ОС... По сравнению с этим KOL - это совсем небольшой проект.
Вместе с тем, очень надеюсь, что появится первая реализация, которую можно будет поторогать руками.
Завтра продолжу читать, а то у нас тут уже семь утра...

← →
lse (2008-03-21 20:45) [148]

Здравствуйте, Владимир.
Как успехи на поприще разработки нового языка программирования ?

← →
zldo (2008-07-02 14:48) [149]

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

← →
Vladimir Kladov (2008-07-02 15:53) [150]

with способен только запутать, но никак не упростить. Кто видел, тот знает.

← →
zldo (2008-07-07 10:41) [151]

все хорошо в меру, но его отсутствие сделает синтаксис для такой замечательной возможности ООП как инкапсуляция громоздким...
Может быть ввести некоторые ограничения и особую фому записи? Например сделать невозможность вложенности этого оператора, а внутри его тела использовать специальную форму доступа с полям допустим что-то в духе:
LongLongTitle = object field1, field2, и т.д. и обращение with LongLongTitle do begin .field1 = .field2 .field2 = myvariable end;
т.е. не создавать оператором "область видимости" для переменных а дать возможность программисту делать сокращенную запись.

← →
Vladimir Kladov (2008-07-07 16:48) [152]

Сокращать запись - себе дороже. Программу пишут один раз, а исправляют и подправляют, да и читают просто - десятки и сотни раз. Ну и зачем себе сложности устраивать? Посмотрите, как код пишется в C# - все пишется полностью и без никаких with. При этом при наборе текста чаще всего достаточно вообще одну буквц набрать, и наиболее подходящее имя высвечивается туту же, остаётся только enter нажать. Куда уже короче?

Смысл не в самой короткой записи, а в самом надёжном коде (и при том достаточно эффективном - хотя бы за счёт константых функций, т.е. выполнении на этапе компиляции значительной части проверок), я так понимаю. Вот этот фокус со вставкой строк на языках SQL и прочая - ни в каком C# даже близко не лежало. Может, там что другое предлагается, но я пока не нашёл, хотя немножко программировать на нём попробовал.

← →
Vladimir Kladov (2008-07-07 16:56) [153]

Я ещё посмотрел (спустя полгода), и в отличие от предыдущих набросков, изменений практически нет. Единственное, что надо бы выкинуть слово PUBLIC (всё публичное по умолчанию), и оставить HIDDEN, и писать его всё-таки перед каждым объявлением чего-либо скрытого. И вернуться к варианту, когда легальный доступ к скрытому идёт через составное имя HIDDEN. Типа MyObject.HIDDEN.Field1. Немножко меняется IMPORT, всё остальное пока так же. Еще есть смысл для конкатенации строк использовать оператор ",", а не ||. Или как вариант, или всегда. А так - в общем мне самому понравилось. Специально надолго отложить, чтобы самому этот сумбур попытаться воспринять как с листа.

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

SOL (Соль) = Simple Objects Language Найти похожие ветки