On Sunday 05 January 2014 21:26:00 Linuxfan wrote: > Hi folks, > > after 30 years of programming with different languages (basic, pascal, > C, asm, tcl, php, bash...) I come to the conclusion that none of them > is satisfactory for me.
Sounds familiar. :) Although for me Delphi 7 is not so much away for my needs. > I would like a language that needs few strokes > on the keyboard, with little punctuation, but very precise, expressive, > powerful and smart, without hidden features or pitfalls. Yup, mostly the intention of MSElang too, I like to add "readability". ... > To better explain, I > will make two examples on how heretic I am. Let's talk about verbosity: > > var lab1: Tlabel; > lab1 := Tlabel.create; > lab1.left := 10; > lab1.top := 20; > ... > > Here, "lab1" is cited 3 times, not counting the declaration. A WITH > clause would help little: > > lab1 := TLabel.create; > with lab1 do begin > left := 10; > top := 20 > end > > Now lab1 is cited 2 times, but with, begin end have come in. What about > of, instead: > > lab1.: create; left=10; top=20 > > The trick is the colon. It means "repeat from the start of the line, > until the physical line end". What I do not like in this approach is the dependency of semantic by the layout. For MSElang it is a no-go because MSElang is layout independent with some minor exceptions (//-comments for example). In MSEgui with-statements are used often. I know that most Delphi experts preach that "with" is evil, I don't think so. MSElang has the mandatory alias name in with statements in order to avoid overlooked name clashes. In MSElang the example would be written as " lab1:= tlabel.create(); with l:lab1 do l.left:= 10; l.top:= 20; end; " The example makes not much sense because writing " lab1.left:= 10; lab1.right:= 10; " is faster. In MSEgui initializing properties of a classinstance is not used often because the values are streamed and set in object inspector of MSEide. > This is a task for the lexer/parser; the > compiler doesn't see the colon. In this example the compiler, reading > from the parser, reads "lab1", ".", then "create", then ";". A complete > statement. A note about this: "lab1.create" is interpreted as > "lab1 := Tlabel.create" (what else could be this statement: a > constructor invocation without assignment?). This also is against the philosophy of MSElang. Things what happen should be visible in code and they should look always the same. If there is an assignment, write it as assignment. > Then the compiler goes on > for a new statement and, because the parser still has a colon pending, > the compiler reads "lab1.left=10;". Then it reads "lab1.top=20". Then > the physical line ends, so the parser frees the colon. (You also see "=" > instead of ":="). This idea goes even further because the colon can be > implicit: when the compiler expects more tokens, but they are not > there, an implicit colon is assumed: > Against the MSElang design principles too, things should always look the same. In MSElang the ';' for example becomes a mandatory statement terminator. It helps to separate the statements while reading the code. In procedure headers the ';' has been replaced by ',' so in header definition and procedure call parameter separators look similar. > var > // after a "var" keyword, shouldn't be an identifier? > // but there is not: so the compiler tells the parser > // "assume an implied colon" > int x // here the compiler reads "var int x" > int y // and here "var int y" > end // this "end" closes the (implicit) colon > > This paradigm is simpler and more consistent than the normal pascal > way. A pascal compiler, while parsing a var block, must always check > that the next token is not a keyword (procedure, function, type, > absolute, external...). I don't understand the motivation. To solve a fascinating intellectual puzzle? This is another thing I like to avoid in MSElang. Terminating 'var' by 'end' is a possibility I have to think about. I assume same applies to 'const' and 'type'? > At a certain point, freepascal had to forbid > declaring object variables after its methods, just because of that > ambiguity. I don't understand, please explain. > You may ask "why the type specifier stays before the identifier, as in > C?". Because I think it is better, but the explanation is long. > I don't think it is better. When one searches a variable definition in code normally one want to find the variable name to check the type not the opposite. So scanning the name at the left edge of the editor window is easier than to follow the gap between type and name. > Second heretic idea. One of the best things of pascal is its strong > typing system. But it is not strong enough, especially when some kind > of automatic type conversion is desired. Let assume we write a > procedure "print" to output human readable data. We want to print > messages, numbers, and perhaps other kind of data. There are two ways: > write several overloaded versions of print, each accepting a particular > type, or write only one: "print(st: string)". The overloaded version > forces us to write a new version every time a new type is introduced; > taken to the extreme, every time we introduce a new type, we must add > overloaded functions for every thing our program can do (print on > console, set caption of something, writing data to disk, send data over > TCP and so on). The second version, "print(st: string)", is much more > versatile: it can print anything, provided that we convert to string > for it, so the program gets filled of inttostr floattostr > format(blabla) and so on. And here is the heretic idea: a hierarchical > type system with automatic conversions (I would call them "promoters"). Ouch. Another design principle of MSElang is: there are no implicit type conversions... :-) > The most universal type is string: it can describe everything. It is > too generic, too. So let's create a new type "text", which is a string, > but a very precise string - a human readable one; and write the > function print(st: text). Now, when introducing a new type, we write a > promoter for this type, which generates a human readable string. In MSElang one probably would write " sub s(const value: thenewtype): str8; begin := DoTheConversionWithValue; end; ... print(s(TheNewTypeValue)); " > This > way, the single print() can print anything. We can put it in a unit and > forget it. The key for this is: string is a sequence of byte complete > with a length. Strings can be concatenated searched indexed and so on > as usual. Another type "text" *is* a string, and still another one is > UTF8 (derived from text). Each of them are beasts on their own. All the > operators and functions operating on strings can be applied to text and > UTF8, because UTF8 is "text" which is "string", but certain operations > (say, search) can be overloaded/overridden: the function > pos(...) operates in a certain way on string and text, and in another > one on UTF8. This concept is simply inheritation extended to simple > types too. > MSElang supports string8 (utf-8), string16 (utf-16), string32(UCS4) and bytestring which can contain any 8 bit encoding and binary data. There is no automatic or implicit conversion between different string types. There is no string type named "string" in MSElang, the users can define "string" as any of the four or even a self made object. > I have other heretic things in my mind, but for now it should be > enough. Let me know what do you think. > I am curious about more and what you think about the MSElang approach. :-) Martin ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
