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]

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

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