![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
SOL (Соль) = Simple Objects Language
Vladimir Kladov © (2007-12-15 22:08:00)http://kolmck.net/sf/SOL=IdealSpade4Programmer.rar
Ну хорошо, пусть будет отдельная ветка.
Сразу ответ D[u]fa на
зачем каждый раз писать do, почему б нельзя объявить массив как arr[... , ..., ...]
Мы же пишем begin, и нормально. Анализ текста значительно упрощается. Дело даже не в компиляторе. Человеку тоже проще, если есть открывающая скобка блока. Есть ведь и эквиваленты, кому само слово DO не нравится (и END).
Массив не надо так объявлять. Я долго думал, почему. Например, во избежание непонимания того, что если есть объявление [3,3,3], то можно обратиться как [i,j] и получить элемент-масив из 3 элементов. Если можно объявлять только [3][3][3], согласитесь, такой проблемы вообще нет. В конце концов, ][ ничем не хуже , ,но видно этот "символ" лучше.
Спрашивайте ещё. Я пока пытаюсь "победить" многозадачность (точнее многонитевость). Изучил адовские рандеву, мониторы модулы-2, активные объекты эктив-оберона - ничего мне не нравится пока. И вообще. Механизм защиты CATCH, который я предложил как черновой, мне самому трашно не нравится. В общем, голову ещё есть над чем поломать.
Vladimir Kladov (2007-12-26 18:20:00) [41]Компиляторы С есть для всех платформ и даже не платформ (FPGA). JIT-код из простого C-кода сделать проще, чем наоборот. Потому что внутри Ява недалеко ушла от Форта. Стековая машина в принципе не подходит для представления кода на не-стековых машинах (хотя обратное верно). Потому и С.
Я знаю, что поддерживается аппаратно. На PC. Но PC - не единственная платформа. Меня не интересует получить код только для PC и заточить компилятор для одной платформы. Пожтому ассемблер даже не рассматривается.
vpbar (2007-12-26 17:29:00) [42]>>Vladimir Kladov © (26.12.07 16:10) [111]
Java :) или Forth.
А вообще поддержка исключений есть в Windows (Linux и прочее вроде тоже) и аппаратно должна поддерживаться. А обернуть это можно хоть на асемблере.
Vladimir Kladov (2007-12-26 16:10:00) [43]Да, обновил про unsafe-маркер, и средние описания. Теперь там про циклы тоже есть.
Думаю, что компиляцию надо делать в простой код на С. Одна беда: поддержки исключений в нём как-то не очень чтобы наблюдается. Надо что-то замутить эдакое, чтобы результат был более-менее платформенно-независимый. Идеи есть (кроме использовать C++)?
Vladimir Kladov (2007-12-26 16:05:00) [44]myvar = 10, в другом mivar = 11
такие вещи решаются просто. Даже если вы используете нотепад вместо редактора, который должен предлагать подсказки. Если после второго присваивания вы так и будете использовать mivar, то ошибки и нет. А если нигде больше не она не упоминается, компилятор предупреждает, что mivar присвоена, и не используется. А если вы употребили неверное имя в выражении а не в левой части присваивания, то это уже не предупреждение, а ошибка: переменная не инициализирована.
По мне, делать где-то там наверху (да даже и в том же блоке) кучу деклараций - бессмысленно. Когда вы читаете текст, туда-сюда не набегаешься. И никто не запрещает переменные "объявлять". Пишете в начале все присваивания начальных значений - вот вам блок объявлений.
homm (2007-12-25 21:39:00) [45]> [108] GMax (25.12.07 21:36)
> в пнях еще кажется для этого даже спец-опкоды ввели, настолько
> удобно.
Ага, ввели и никому не сказали :)
GMax (2007-12-25 21:36:00) [46]а мне непонятна прелесть объявления переменных присвоением.
в одном месте написал myvar = 10, в другом mivar = 11. ошибся типа. и потом столетиями ошибку ищем. или я не так понял ?
да и "Оператор присваивания в выражении" не настолько уж великое зло, как кажется.
почему ж лишать "if (i=somefunc()) ?"
в пнях еще кажется для этого даже спец-опкоды ввели, настолько удобно.
Vladimir Kladov (2007-12-25 20:41:00) [47]И, кстати, я же уже придумал функцию FUNCTION. Значит, всегда можно написать функцию-компилятор с любого языка, хоть С, хоть хаскел, и просто вставлять в код. Самое что ни на есть тесное взаимодействие, вплоть до компиляции во время компиляции самого исходного текста. (А текст на нужном языке вставляется многострочной строковой константой).
--------------
Ещё раз поправил Что-то много в большом тексте осталось устаревших конструкций и описаний, по объявлениям функций прошёлся на этот раз.
Vladimir Kladov (2007-12-25 19:07:00) [48]Это не та простота, которая мне нужна. Я, например, не перевариваю много скобок. После двух вложенных скобок у меня уже глаза разбегаются. Но дело не в скобках. Мне это просто непонятно. Я сдал экзамен по Лиспу лет 15 назад на 4, и уже через месяц забыл всё. И он мне до сих пор не понадобился. Значит, не нужен.
Хотел бы я посмотреть на редактор html, наприсанный на lisp'е. Нет такого? Точно не нужен. Потому и императивность. Иди туда, потом сюда. Если здесь камень, поверни назад, повтори всё сначала. Это то, что я понимаю. И не надо мне никаких Лиспов. Пусть на ФЯ пишут те, кому это надо. По мне, так это вообще write-only код. (Читабельность - нулевая).
Я в курсе, что идеи, заложенные в Хаскел (теория категорий) настолько сложны, что нужно специальное мат. образование, чтобы понять. Проверять не решаюсь, хотя математик по образованию. Бэйсик - вот идеал простоты, а не Лисп. Поймёт любой, напишет каждый второй инженер.
---------------------
Так, я обновил большой текст (насчёт обработки исключений, и про циклы). Средние обновлю завтра уже.
alex (2007-12-25 18:16:00) [49]Вообще-то D - это скорее облагороженный С++, ну да ладно. О вкусах не спорят.
Scheme, Lisp - не являются чистыми функциональными языками. На них можно писать и в императивном, и в функциональном стиле. При этом они (по крайней мере, Схема) хорошо соответствуют принципу простоты.
А почему императивность, кстати? В значительной мере случаев функциональный подход дает более простые и наглядные решения.
И, наконец, эти (и многие другие) языки интересны своими особенностями, независящими от парадигмы. В Хаскеле, к примеру, нет никаких шаблонов, есть статическая типизация и тем не менее нет никакой необходимости делать несколько реализаций одного алгоритма для данных разных типов.
Vladimir Kladov (2007-12-25 15:36:00) [50]С D ознакомился до того как начал: мертворождённый недоСи. Прочие являются функциональными языками программирования и императивному не имеют практически никакого отношения. Сорри.
Теперь о баранах. Вот такая мысль насчёт циклов.
1) Переменную можно менять в цикле. Но синтаксис должен быть особый. 2 варианта:
i LOOP = выражение;
CONTINUE i LOOP = выражение;
Тогда уже точно видно, что программер прекрасно понимает, что он меняет переменную цикла. И компилятор соглашается. Иначе - ошибка.
2) Переменная имеет после выхода из цикла то значение, которое должна иметь. Но использовать её вне цикла можно только 2 способами:
- в выражениях, на чтение,
- для организации следующего цикла (или внутри следующего цикла).
Всё: проблема неверного использования, которой все запрещатели так боялись исключена.
Я обновил таблицу. Поправил там, кое-чего дописал. Если у кого-то есть глубокий опыт возни с Явой или С#, просьба подсказать, что вместо ? ставить напротив (про Аду и PL/1 я уж сам как-нибудь).
alex (2007-12-25 14:36:00) [51]Может стоит сначала познакомиться с другими языками программирования? Те, что представлены в таблице - это малая толика существующих (и успешно применяющихся), а, кроме того, почти все являются близкими родственниками.
D, Scheme, Lisp, Ocaml, Haskell - хотя бы с ними ознакомиться надо.
Vladimir Kladov (2007-12-24 20:52:00) [52]Там же заголовок у таблицы есть Распараллеливание потоков вычислений (процессов)
homm (2007-12-24 20:45:00) [53]> http://kolmck.net/sf/SOL%20vs%20others.htm
Понравился параметр «наличие каких-либо средств в языке» :) Это что? :)
Vladimir Kladov (2007-12-24 20:43:00) [54]А которых (ответов) нету, я буду дописывать. Краткое описание должно превратиться в полную (но не водянистую) спецификацию, в конечном итоге.
Вот ведь странно: сделаешь, чтобы := было, будут Сишники ругать, сделаешь чтобы = - паскалисты. И так, и так чтобы было сделаешь - все недовольны. Форма != (<>) содержанию. Это разные вещи.
Vladimir Kladov (2007-12-24 20:40:00) [55]Есть проверка. Кстати из того, что X=0.4 и Y=1 еще не следует, что Y диапазон меньше (т.е. что оно целое). Тем более, если компилятор видит дальше Y=X, то он прекрасно понимает, что 0.4 так же является допустимым значением для Y, т.е. оно уже дробное. Он должен учесть все присваивания, если нет объявления явного диапазона.
Выложил 15 версию и заодно начало сравнительной таблицы (разумеется, все критерии подобраны специально так, чтобы представить SOL в самом выгодном свете, по сравнению со всеми языками. Моё мнение в принципе не может быть объективным:) ): http://kolmck.net/sf/SOL%20vs%20others.htm
Надо было написать продолжение следует. Ну, и так понятно, в общем.
Дописал в версии 15 про тип "булев". Нет такого типа, есть более строгое правило: запрет на неявное присваивание большего диапазона к меньшему (но чуть чуть сложнее, так что в итоге и булев к вещественному неявно не привести).
Ну мало ли что там в С. В С много вещей, с которых не стоит брать пример. Просто не надо так делать, и всё. Правительство Канады это прекрасно понимает. И я понимаю.
Кстати, ответы на большинство вопросов есть в кратком но не самом кратком описании.
vpbar (2007-12-24 20:35:00) [56]
> homm © (24.12.07 20:24) [97]
Да. Точно. Прошу прощения. Не о том прочитал. :( Просто язык необычен, что такие очевидные весчи не воспринимаются.
homm (2007-12-24 20:24:00) [57]> [95] vpbar © (24.12.07 19:38)
> Допускается присваивать динамическому массиву массив статический
> (но не наоборот).
> А почему бы не присваивать статический массив динамическому?
Чукча либо не писатель, либо не читатель :)
vpbar (2007-12-24 19:44:00) [58]
> Вот придумал, кажется: запрет на приведение типов с меньшим
> диапазонам к большему,
Еще.
Т.е. так нельзя
Y=0.4;
X=1;
...
Y=X;
Оригинально. Обычно наоборот. Если больший диапазон приводится к меньшему- то явно. Дабы понимать что может быть потеря точности (в SOL - ислючение).
vpbar (2007-12-24 19:38:00) [59]IF a*b+c THEN. судя по этому "Арифметические с целыми числами не являются циклическими." работать не должно (или невсегда будет). Хотя было бы интересно, можно было бы упростить и исключить AND и OR
Если Вы все же выложили описание языка для критики, то продолжу.
Цитатах текст их SOL=IdealSpade4Programmer вчерашней версии.
Переменная-массив так же может быть присвоена переменной-
массиву подходящей размерности.
Спроверкой совместимости типов элеметов, разумеется? А как с приведением типов. Есть ли механизм описанния явного приведения типа для элементов массива .
Вы конечно говорите что "8. Приведение типа. Никогда и ни при каких обстоятельствах. Раз уже все атомарные типы данных эквивалентны, и по сути, являются числами с плавающей точкой, то и приведение типа не требуется." но в Vladimir Kladov © (24.12.07 15:31) [92] заново придумаваете запрет на приведение и упоминаете о какой то "преобразующей функции". В этом контексте под приведением понимать преобразующую функци.
Т.е.
TYPE Bit = 0 TO 1;
TYPE Bits = [10]Bit;
TYPE Arr = [10]Integer;
B:String; A:Arr;
....
A=B // так вроде нельзя. Запрет на приведение типов к большему диапазону
Цикл делать?
Допускается присваивать динамическому массиву массив статический (но не наоборот).
А почему бы не присваивать статический массив динамическому? Или придется явно копировать. Опять цикл.
PS. Так есть приведение типов или нет?
vpbar (2007-12-24 19:19:00) [60]
> Vladimir Kladov © (24.12.07 15:31) [92]
> Я для чего проект языка выставил на обозрение
Да кто же Вас знает.
> А что меня за отсутствие типа Boolean не ругает никто
А чего ругать, в С его вот тоже нет. И ничего. А у вас вообще типов всего ничего числа да указатели, так что отсутствие boolean вполне в тему.
Хотя тут вопрос.
x=2;
y=2.5;
IF (x>y)==(x/y) THEN ...
- такое работать будет? Или нужно задавать операцию (функцию) '-' для этих типов.
А такое?
a=0;
b=1;
c=0;
IF a*b+c THEN...