freepascal.ru

alexey38 писал(а):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.

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.

alexey38 писал(а):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)

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

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

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

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

mse писал(а):I asked you how you would denote the byte order in type definitions, you didn't answer...

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

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

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

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 

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;

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;

mirage писал(а):Function must be "clean", with no side effects on the state.

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

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

begin,end,else if.

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

>
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;
"

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

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

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

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

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

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

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