MSElang : обсуждение фишек

[mse]

Still normal pascal code from Delphi, FPC and Lazarus must without any alterations to work and to work in the new language. If any code is not compatible, then the language will have no future.

Please read here: https://gitorious.org/mseide-msegui/pages/Mselang

The Steps

In the beginning MSElang will be the language currently used in MSEgui project, a subset of Delphi 7 and FPC 2.6.2. Later syntax changes are possible.
In order to develop and test the front-end there first will be an intermediate code interpreter which can be used in MSEifi projects and in MSEgui report generator. Most likely there will be not much effort invested to make it fast at runtime but compiletime must be lightning fast.
Later native code back-ends and a simple RTL will be added.

The discussed MSElang syntax will be another mode. I started the Wiki and the threads in mseide-msegui-talk mailing list in order to develop the new compiler with the new syntax in mind already and to test the ideas in public.

For example, I have previously suggested in this thread to enter the integer types, taking into account different order byte interleaving (which is often important in cross-platform development, the preparation of a binary file or network stream from other platforms)

I asked you how you would denote the byte order in type definitions, you didn't answer...

[Лекс Айрин]

Mikhail, с грамматикой я разберусь. Но это иногда вызывает диссонанс.

[alexey38]

Как в новых Дельфях ? Зачем ? Перекодировка символов требуется как правило только при вводе/выводе - а значит нужно ее привязать ко вводу/выводу.

Перекодировку нужно привязать к вводу/выводу, и к типу переменной. Мало ли какие могут быть задачи, для определенных задач нужен свой тип данных. Но ни в коем случае кодировка файла с исходным текстом программы не должна влиять на тип строковых переменных.
Компилятор должен автоматически подставлять функции преобразования, как он это делает с числовыми переменными, чтобы в тексте программы вообще не встречались операторы типа UTF8toOEM, UTF8toSYS и т.п.

А если нет необходимости в RAD средствах? А насчет begin-ов, так их можно просто игнорировать, хотя лично мне они не мешают.

Если Вас устраивает блокнот, то и нет проблем. Просто не нужно из-за упрямства отдельных личностей (упорно игнорирующих полноценные редакторы кода) захламлять язык программирования.
Оператор begin - хорош в полноценной RAD-среде, когда begin/end разного уровня подсвечиваются разными цветами.

Мартин не любит опциональности - потому что они создают неоднозначнсти (необходимости в ненужных "taking in consideration").

Если не любит, значит нужно на 100% сохранять паскалевский/дельфовский синтаксис там, где это только возможно. Значить все begin, for и т.п. - все на 100% должно оставаться как в паскале/дельфях.

А зачем тогда вообще создавать новый язык? Вообще-то, некоторые пишут и новые проекты, некоторым из которых, новый язык подойдет лучше.
Я бы, допустим, хотел видеть язык с развитыми поток/процессорными средствами. Имхо, тогда некоторые вещи намного проще делать.

Вы сами ответили на свой вопрос. Если бы новый язык было более потоко-ориентированным и потоко-безопасным, то я был бы рад. На подобных вещах нужно концентрировать внимание, а не на begin,end,else if.

Добавлено спустя 8 минут 16 секунд:

I asked you how you would denote the byte order in type definitions, you didn't answer...

I'm sorry.

Мое предложение следующее:
общие целочисленные типы: integer,uinteger - где фактическая размерность переменной зависит от конкретного CPU (минимум 16), опитмизация на быстродействие.
дополнительные целочисленные типы повышенной разрядности: integer(16),uinteger(16),integer(32),uinteger(32),integer(64),uinteger(64) - где 16, 32 или 64 - это минимальная точность, а фактическая зависит от платформы, т.е. integer=integer(16)
специальные целочисленные типы: int8,uint8,int16be,int16le,uint16be,uint16le,int32be,int32le,uint32be,uint32le,int64be,int64le,uint64be,uint64le - строгий размер и конкретная очередность байт

конкретные наименование, и типы скобок: круглые (), квадратные [], фигурные {} можно выбрать исходя из общего принципа построения компилятора, например, если предложенные мною круглые скобки в integer(16) создают сложность, то их можно заменить на другие.

[Лекс Айрин]

Если Вас устраивает блокнот, то и нет проблем.

Зачастую, его возможности даже излишни.

На подобных вещах нужно концентрировать внимание, а не на begin,end,else if.

На всем надо концентрироваться. Синтаксис Паскаля не идеален, Даже сам Вирт это понимал. Если делать новый язык, то нужно прикручивать возможности так, чтобы они идеально интегрировались в синтаксис.

[Mirage]

По поводу названия ключевого слова для процедур - какая разница?
Куда важнее чтобы процедура была процедурой, пусть даже возвращая значение (или несколько), а функция функцией.
Функция должна быть "чистой", без побочных эффектов на состояние. Контролировать должен компилятор - выдавать ошибку на оператор присваивания нелокальным сущностям в такой функции и на вызов процедур. Что-то подобное по-моему даже есть в D.
Что это даст? Да много чего. Например, в цикле такие функции можно смело вызывать параллельно в разных потоках, причем автоматически.

[mse]

Currently MSElang numeric types definition is as follows:
- MSElang language knows subrange numeric types only:

Код: Выделить всё

type 
theBooleanType = $ff;                         //8 bit 
theCardinalType = $00000000..$ffffffff;       //32bit 
theIntegerType = -$8000 to $7fff;             //16 bit 
theCharacterType = #$00 to #$ff;              //8 bit 
theSubrangeType = 5 to 10;                    //8 bit 
theDoublePrecisionType = -1.7e308 to 1.7e308; //64 bit 
theSinglePrecisionSubrangeType = 0.0 to 10.0; //32 bit



- It is possible to define the bit size:

Код: Выделить всё

type 
theNotByteBoundaryType = $0 to $f: 4; 
  //4 bit if bitpacked, 8 bit otherwise, useful as bitfields in controllerregisters for 
  // bitpacked records 
theDoublePrecisionSubrangeType = 0.0 to 10.0: 64; //64 bit 
theOneBitSubrangeType = 123 to 124: 1; //1 bit if bitpacked, 8 bit otherwise


Here the byte order could be defined. How?

- 'low' and 'high' can be used to define full range types:

Код: Выделить всё

type 
boolty = high: 8;             //bool8 
cardty = 0 to high: 8;        //card8 
intty = low to high: 8;       //int8 
charty = #high: 8;            //char8 
floatty = .low to .high: 64;  //flo64 
recordty = object
  b: high: 8;           //bool8 
  c: 0 to high: 8;      //card8 
  i: low to high: 8 ;   //int8 
  ch: #high: 8;         //char8 
  f: .low to .high: 64; //flo64 
end;


- There is a file "systypes.mla" which defines commonly used types, please note, this is *not* part of the language.

Код: Выделить всё

unit systypes;
type
//same on all architectures
bool1 = $1: 1; //1 bit if bitpacked
bool8 = $ff: 8;
bool16 = $ffff: 16;
bool32 = $ffffffff: 32;
card8 = $00 to $ff: 8;
card16 = $0000 to $ffff: 16;
card32 = $00000000 to $ffffffff: 32;
card64 = $0000000000000000 to $ffffffffffffffff: 64;
int8 = -$80 to $70: 8;
int16 = -$8000 to $7fff: 16;
int32 = -$80000000 to $7fffffff: 32;
int64 = -$8000000000000000 to $7fffffffffffffff: 64;
char8 = #$00 to #$ff: 8;
char16 = #$0000 to #$ffff: 16;
char32 = #$00000000 to #$ffffffff: 32;
flo32 = -3.4e38 to 3.4e38: 32;
flo64 = -1.7e308 to 1.7e308: 64;
//architecture dependent, there can be more differentiation for
//different operating systems
//boolean, cardinal, integer and float are the "recommended" types
//card and int have the size of the CPU registers

boolean = bool8;
{$if REGISTERSIZE = 16}
cardinal = card16;
integer = int16;
card = card16;
int = int16;
{$else}
cardinal = card32;
integer = int32;
{$endif}

{$if REGISTERSIZE = 32}
card = card32;
int = int32;
{$else}
{$if REGISTERSIZE = 64}
card = card64;
int = int64;
{$endif}
{$endif}
float = flo64;


The MSElang RTL uses this file.

Posted after 19 minutes 26 seconds:

Function must be "clean", with no side effects on the state.

For me the purpose of a function is to provide a value which can be used in expressions.

[Mikhail]

По поводу названия ключевого слова для процедур - какая разница?
Куда важнее чтобы процедура была процедурой, пусть даже возвращая значение (или несколько), а функция функцией.
Функция должна быть "чистой", без побочных эффектов на состояние. Контролировать должен компилятор - выдавать ошибку на оператор присваивания нелокальным сущностям в такой функции и на вызов процедур. Что-то подобное по-моему даже есть в D.
Что это даст? Да много чего. Например, в цикле такие функции можно смело вызывать параллельно в разных потоках, причем автоматически.

Я уже такое предлагал. В целом есть два подхода, как в Обероне. Т.е. есть только процедуры, в частном случае процедура может возвращать результат и, следовательно, ее можно использовать в выражении.
Либо разделить подпрограммы на процедуры, которые не могут быть использованы в выражениях и функции, чистые в математическом смысле. Использование только чистых функций в выражениях существенно добавит понятности коду, т.к. не будет побочного эффекта.

При первом подходе логичнее использовать procedure, т.к. по смыслу это именно процедура, а не функция.

[debi12345]

Функция должна быть "чистой", без побочных эффектов на состояние. Контролировать должен компилятор - выдавать ошибку на оператор присваивания нелокальным сущностям в такой функции и на вызов процедур. Что-то подобное по-моему даже есть в D.
Что это даст? Да много чего. Например, в цикле такие функции можно смело вызывать параллельно в разных потоках, причем автоматически.

Очень заманчиво ! Но это потребует думать по другому, не по state-machine-ному.
Как Вам HASKELL ? Пробовали на нем писать бизнес-проги ? Конечно же это возможно - после совершения переворота в мозгах

Добавлено спустя 11 минут 6 секунд:

begin,end,else if.

Когда они зазря мусорят или путают код, пряча полезный контент - это реально бесит.

[Mirage]

Зачем мне Haskell? Есть более-менее майнстримная Скала.
А что идея с чистыми функциями императивщикам не понравится, об этом я догадывался.
Нездоровый это консерватизм.

[debi12345]

Компилятор должен автоматически подставлять функции преобразования, как он это делает с числовыми переменными, чтобы в тексте программы вообще не встречались операторы типа UTF8toOEM, UTF8toSYS и т.п.

зачем вводить постоянный рантаймовый оверхэд ради редко требуемого функционала ?

Добавлено спустя 13 минут 16 секунд:
Теперь обсуждается идея ликвидации "return" в функциях- - как опасной (плохо видимой при большой вложенности) прерывающе-завершающей инструкции:

>
The last return is mandatatory and at fix position the others are not. I don't
like that. It should be possible to program without 'return' completely
because 'return' is dangerous if one overlooks it.

"
var
globflag: bool8;

sub test(a: bool8, b: bool8, c: bool8): int32;
var
result: int32;
begin
result:= 0; //initilization
if a then //long deeply nested processing
result:= 123;
else
if b and c then
result:= -100;
else
result:= 88;
end;
end;

globflag:= result > 0; //terminating statement, cleanup

:= result;
end;
"
After some time one needs to fix a bug:
"
begin
result:= 0; //initilization
if a then //long deeply nested processing
result:= 123;
else
if b and c then
result:= -100;
else
if not (a or b) then
return 1000; //aua, the globflag will not be set!
else
result:= 88;
end:
end;
end;

globflag:= result > 0; //terminating statement, cleanup

:= result;
end;
"

So it should be possible to completely work without 'return' statement
(or 'exit' in Delphi). In order to cancel operation it is often better to use
a goto.

"
var
globflag: bool8;

sub test(a: bool8, b: bool8, c: bool8): int32;
var
result: int32;
label
abort;
begin
result:= 0; //initilization
if a then //long deeply nested processing
result:= 123;
else
if c then
goto abort; //abort processing
end;
if b and c then
result:= -100;
else
result:= 88;
end;
end;

abort:
globflag:= result > 0; //terminating statement, cleanup

:= result;
end;
"

[Mikhail]

Теперь обсуждается идея ликвидации "return" в функциях- - как опасной (плохо видимой при большой вложенности) прерывающе-завершающей инструкции:

Это не сильно принципиальный момент. У каждого из подходов есть и сильные и слабые стороны.

Кстати, в FPC поддерживаются оба варианта.

[debi12345]

Функция должна быть "чистой", без побочных эффектов на состояние. Контролировать должен компилятор - выдавать ошибку на оператор присваивания нелокальным сущностям в такой функции и на вызов процедур. Что-то подобное по-моему даже есть в D.
Что это даст? Да много чего. Например, в цикле такие функции можно смело вызывать параллельно в разных потоках, причем автоматически.

А также (одинаковый возврат при одиноковых входных аргументах) - кэширование результатов. Вот на этом можно выиграть о-о-очень много

[Mikhail]

А также (одинаковый возврат при одиноковых входных аргументах) - кэширование результатов. Вот на этом можно выиграть о-о-очень много

Это можно делать и сейчас.

[debi12345]

For me the purpose of a function is to provide a value which can be used in expressions.

As long as pure functions can be decaled with a keyword - "cachable" (like in PostgreSQL), "pure"... These funcs can be safely parallelized, cached,..

Это можно делать и сейчас.

АФАЙК, компилятор сейчас этого не делает - потому что нет механизма пометки такого (не зависящего от сиюминутного глобального контекста) рода функций.

Добавлено спустя 9 минут 25 секунд:

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

Зато дает малоглючные и легко-отлаживаемые проги. Суть использования императивных функций - вызов и таких функций для аргументов НЕ изменяемых в КОДЕ программы для перерасчета текущего состояния программы - вместо проверки глобальных переменных (отражающих глобальное состояние)

[Mikhail]

АФАЙК, компилятор сейчас этого не делает - потому что нет механизма пометки такого (не зависящего от сиюминутного глобального контекста) рода функций.

Это не очень сложно сделать. Введение чистых функций имеет иной смысл.