roboforum.ru

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

Да в каком месте они простые-то?
типы, объявления,
какой-то странный оператор ":=" (сто пудоф будут по ошибке писать "="),
точно так же как в си частенько пишут "=" вместо "=="
закрывающие слова фактически не несут смысла - только загромождают код
и т.д. и т.п.

Вот на скриптовые язычки стОит посмотреть (хотя бы как на пример). Ну питон тот же, да...

имхо.

Добавлено спустя 4 минуты 17 секунд:
Сколько слов здесь несут смысловую нагрузку

Код: Выделить всё • Развернуть

MODULE HelloWorld;
IMPORT Out;
BEGIN
  Out.String("Hello World!");
  Out.Ln;
END HelloWorld;

Сравните

Код: Выделить всё • Развернуть

# Hello World in Python
print "Hello World"

Отступы будут, скобки или begin/end - совершенно пофигу. Это легко меняется в описании грамматики. Предлагаю обратить внимание на то, какие типы данных поддерживать и как с ними работать - это действительно важно, и влияет как на компилятор, так и на виртуальную машину.

Еще раз замечу - мне не нужен полноценный язык программирования, мне нужен язык, который юзер может быстро освоить и начать использовать, при этом ресурсы, в особенности ОЗУ, сильно ограничены. Если Michael_K посчитает, что это за рамками его темы - перенесу обсуждение в новый топик.

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

Должны быть целое число и строка текста - как (я надеюсь) интуитивно понятные большинству. С числами все просто и понятно. Со строками немного сложнее. Пока мысли такие:

1. Переменные строкового типа объявляются с указанием максимальной длины.
2. Для машины строка - это то же целое, обозначающее адрес переменной.
3. Можно объявлять константные строки, которые будут располагаться в том же адресном пространстве, что и инструкции виртуальной машины.
4. Виртуальная машина поддерживает инструкцию копирующего присваивания строк.

Вопросы:
1. Надо ли позволить юзеру лезть внутрь строк (обращение к отдельным символам)? Сразу встает вопрос о контроле границ.
2. Как реализовать стандартные строковые функции (поиск, выделение подстроки, конкатенация)? На уровне виртуальной машины? Или на уровне нативных функций?

Да в каком месте они простые-то?

Грамматика Питона: http://docs.python.org/release/2.5.2/ref/grammar.txt
Грамматика Оберона: http://www-old.oberon.ethz.ch/EBNF.html

Реализуете Питон? Ждать не буду, думаю, что этого не случится.

Еще одна радость - хочется строки в многобайтных кодировках. Подумываю про utf-16

Добавлено спустя 30 минут 27 секунд:
А вот фиг, бизон utf16 не разжует

Ну пожалуй UTF-16 здесь будет лучшим выбором, т.к. с UTF-8 будут лишние сложности.

А сравнивать EBNF питона с обероном тут странно, реализовывать весь питон будет крайне странно

Добавлено спустя 1 минуту 17 секунд:
Вообще думаю можно все строки делать юникодными

Блин, а ведь ничто же не мешает на входе использовать UTF-8, а компилятором все преобразовывать в UTF-16

1. лично я против UTF-16 внутри ВМ. Практически поголовно все типичные применения
(начиная от дисплеев, кончая терминалками и сетевыми протоколами) потребуют какого-то преобразования, да и память лишней не бывает

2.

blindman писал(а):мне нужен язык, который юзер может быстро освоить и начать использовать, при этом ресурсы, в особенности ОЗУ, сильно ограничены... - юзеру нужно решать его задачу, а не учить язык программирования.

+1
Я бы еще добавил про свести к минимуму неоднозначности и потенциальные ошибки синтаксиса.

структуры там всякие и объекты нафиг

А вот насчет массивов?... штука-то полезная... да и строки так и так лезут...

3.

blindman писал(а):Если Michael_K посчитает, что это за рамками его темы

Задача как раз близкая... а во что компилировать - это вопрос решаемый...

4.

Надо ли позволить юзеру лезть внутрь строк (обращение к отдельным символам)? Сразу встает вопрос о контроле границ.

Эммм... а применение-то какое все ж таки?
То есть если это все про сервы-моторы-светодиоды, то строки явно появятся только либо в ЖКИ (статичные),
либо в несложных протоколах... Тогда можно, видимо, обойтись atoi itoa strcmp итп. И я бы делал их нативными.

Ну а если это скрипт для баз данных или для разбора выражений... ))

1. Типичные - возможно. Вот только то, ради чего я это затеял, требует как раз юникод. Еще подумаю над всеми плюсами и минусами, возможно остановлюсь на однобайтной кодировке и преобразовании в прошивке. Хотя можно сделать и опцию компилятора, а размер символа будет определять реализация машины.
2. Массивы - да.
4.

Michael_K писал(а):Ну а если это скрипт для баз данных или для разбора выражений...

У меня - да. Разбор команд присутствует.

ну если и массивы нужны, то вроде бы ничто не мешает относиться к строке как к массиву?

Только вот сдается мне что можно проблем с этими массивами огрести без контроля границ. Да и контроль не сильно поможет. Короче, и хочется, и колется

Ну, а кто мешает контроль границ организовать?
Просто пойнтеры делать не нужно!
Обращение к элементу массива - это отдельная операция.
Если размеры массива известны на этапе компиляции (то есть динамически не создаются и не меняются),
то можно и проверку сделать, по-моему, без проблем...
(Если неизвестны заранее - тоже можно, но уже сложнее )

Правда объявления сразу нужны.

Надеюсь из "кода" ниже понятно, что, как я вижу можно реализовать. Передачу строк в функции и возврат строк (ну и массивов соответственно) пока не вижу как реализовать без объявления типов параметров

Код: Выделить всё • Развернуть

// numeric constant
const numConst = 12;

// string constant
const stringConst = "abcd";

// string list constant
const stringList = ["abcd", "efgh", "ijkl"];


//numeric global
int gNum;

// numeric array
int aNum[numConst * 2 + 1];

// string global
string gString[10];
string gString2[numConst];


// string arrays -- do we really want them ?


// function 
function f1()
{
   // statements
   return; // return 12;
}

// function  with parameters
function f2(a, b, c)
{
   // statements
}


// function  with parameters and locals
function f3(a, b, c) : d, e, f
{
   // statements
}

// control statements
while gNum < 100 gNum = f1();

while gNum < 100 {
   gNum = f1();
   gNum = f2(gNum, 1, 2);
}

until gNum < 100 gNum = f1();

if gNum < 3 gString = stringList[gNum];

if gNum < 3 gString = stringList[gNum]; else gString = "unknown";

if gNum > 2 {} else gString = stringList[gNum]; // hehe

if gNum > 2 ; else gString = stringList[gNum]; // haha

repeat d from 0 to 2 {
   gString = stringList[d];
   f3(gString, 1, 2);
}

// statements separation

while gNum < 100 {
   gNum = f1(); gNum = f2(gNum, 1, 2)
}

while gNum < 100 {
   gNum = f1()
   gNum = f2(gNum, 1, 2)
   gNum = gNum + 1
}


// string  indexing

gString[0] = gNum;
gString[0] = 'a';
gNum = gString[1];

// array indexing
e = aNum[f];

aNum[e] = gNum;

Ну, что концепция довольно внятная и чистенькая. Вполне...

Лично я бы еще упростил (если про роботов говорить),
но тут конечно от задачи нужно смотреть.
Потому что упрощения дальше уже будут за счет "полноценности" языка.

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