Это всего-лишь наброски и что-то будет реализовано, а что-то нет, в зависимости от применяемости.
1) Указатели на функции. Это то что уже было, но не там где нужно )) В AddRegionProc можно передавать указатели на функции и только в этом случае имена функций не воспринимаются как их вызов (это то, о чем я говорил ниже). Пример использования я уже приводил в топике
http://teamx.ru/smf/index.php?topic=402.msg3140#msg31402) Массивы функций. Может случится, что к ф-ии будет удобно обратится по индексу а не по имени. Например:
pocedure foo[3]( var a );
procedure foo[0](var a) begin /*some 0*/ end
procedure foo[1](var a) begin /*some 1*/ end
procedure foo[2](var a) begin /*some 2*/ end
procedure main
begin
call foo[random(0,2)](0);
end
3) Масивы (статические/динамические) и структуры
struct s1
begin
var a;
var b;
end
procedure foo( var a )
begin
var s[5]; // статический
var f[a]; //динамический
s1 aa;
aa.a := 12;
s[3] := 10;
end
4) Ссылки. Исходя из того что планируется введение массивов и структур, и возможность их передачи в ф-ии передавать их по значению будет немного дороговато и лучше передавать их по ссылке. В самом простейшем случае этого можно добится отрицательным аргументом в опкоде O_FETCH. Но для универсальности всетаки прийдется вводить в движок ф-ии чтения/записи в стек по абсолютному а не относительному адресу.
procedure foo1( var &a)
begin
a := 0;
end
procrdure foo2( var a)
begin
a := 0;
end
procedure main
begin
var a := 1;
call foo2(a); // а копируется, после выполнения а == 1
call foo1(a); // а не копируется, после вызова a == 0
end
5) Строгая типизация. Большинство скриптовых ошибок можно отловить на этапе компиляции, тем самым экономя уйму времени на отлаживании кода, который по непонятным причиинам не работает. Отсутствие типизации в SSLC может приводить к множеству проблем:
obj_art_fid( 12 ) не имеет никакого смысла, и это ясно еще на этапе компиляции, но SSLC это проглатывает
obj_art_fid( "мама" ) смысла еще меньше, но опять же никаких вопросов
Вообще никаких гарантий насчет типа SSLC не дает, что есть очень плохо! Никогда нельзя быть уверенным что ты получишь в результате. А статическая проверка типов сможет оградить от таких банальных и опасных ошибок. Так, например в SSLC допустимо:
procedure ten_add( var a)
begin
return a + 10;
end
procedure main
begin
var b[20]; var c;
c := b[ten_add(11)]; //все верно, b == 11
c := b[ten_add("a")]; //все верно, но b == "а10" а это не является допустимым индексом. Будет очень трудно понять, почему что-то не работает
end
С типизацией:
int ten_add( int a)
begin
return a + 10;
end
void main
begin
int b[20]; int c;
c := b[ten_add(11)]; //все верно, b == 11
c := b[ten_add("a")]; //не будет скомпилированно из-за несоответствия типов
end
Прведенный пример достаточно прозрачен, и ошибку вроде-бы достаточно просто выявить, но представте себе, что агрументы протаскиваются через десяток вызовов, или чтото типа этого:
var someverylongname;
var someverylongnena;
someverylongname := 12;
someverylongnena:= self_obj;
destroy(someverylongname ); //непредсказуемое поведение, хотя от этого можно былобы избавится за счсет проверки типов.
6) Оптимизация. Можно легко находить неиспользуемые локальные ф-ии, убирать ненужные продувания стека в функциях без аргументов, не возвращать значения из ф-ий, которые не предпологают возврата оных, отрезание неиспользуемых хвостов ф-ий, статическое выведение значений и т.д.
7) Расширяемость. Дополнительные опкоды можно вводить простым дописыванием их в конфигурационный файлик.
Будет совместимость со старыми скриптами, документацию не нужно будет переписывать, а только добавить пару статей, описывающие новые возможности кодинга.