[fpc-pascal] MSElang, the future compiler for MSEide+MSEgui

[Michael Schnell]

On 11/06/2013 09:14 AM, Martin Schreiber wrote:
> if you like to discuss the matter.
IMHO this theme is complex enough to start another mailing list instead 
of discussion it here.

There already has been a (IMHO very interesting) discussion  in the 
"German Lazarus forum" that in fact does have an "mse" section for such 
issues.

For me, there were some some discussion results that seem to be seem 
worth noticing (OS some are just my opinions :-) )
  - Martin wants to beat the compiler speed of D7, which he esteems to 
be 10 times that of fpc. Good luck :-) :-) !
  - IMHO, the archs supported should include X32, X64, ARM32, and ARM64
  - IMHO, the OSes supported should include Windows (Desktop) and Linux. 
(Android would be nice but how to do this ?)

  - There has been a vivid discussion on Unicode support. For me, the 
results are:
  . - There should be no string type (out of the box) called "String" or 
ANSIString or "UnicodeString" (the user can add a "Type" statement if he 
wants such.) String types should be given "honest names.
  . - (Rather) decent Unicode handling can only be done with "code aware 
Strings", which Martin does not want to implement. This of course makes 
mseLang not really "Unicode aware", which is not a severe problem to 
most potential users, and in many cases better than not doing Unicode at 
all.
  . - For optimum practical use the language should have a (raw) 
"ByteString" type and a "UTF16String" type that hold exactly the named 
information.
  . - The appropriate Character Types of course are "Byte" and "UTF16Char"
  . - ByteStrings are not printable and there is no auto-conversion
  . - printable information always is in UTF16Strings.
  . - The string index (including pos(), ...) is counted in (16 bit) 
codewords. There is a decent documentation that shows the implications 
regarding Codepoints > 2^15 and "composed" printable characters.
  .- String (and array) indexes always count from Zero (neither base 1 
(Strings) nor Base whatever Arrays).

I vote for adding Syntax for parallel processing (similar to "parallel 
loop" and "future" in Prism) but this of course is a future nice to have 
add-on.

have fun,
-Michael