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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

собсно и?)

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

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

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

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

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

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

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

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

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

Я думаю, вы меня поймёте лучше, если 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 уже немножко не дотягивает. Но пока достаточно простой всё ещё.