[MSEide-MSEgui-talk] MSELang heretic ideas
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. 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. So I started to design a new language from scratch, paying attention to not being deviated from existing ones: this is an important point for me. Then I stumbled upon this forum, and found a similar project. After reading a few messages here and there, I am thinking that my ideas are very different and heretic: I started my design knowing that yes, pascal is the better language I know, but this is not a good reason to borrow too much from it because it has several weaknesses. 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". 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?). 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: 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...). At a certain point, freepascal had to forbid declaring object variables after its methods, just because of that ambiguity. 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. 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"). 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. 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
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
lab1.: create; left=10; top=20 It like the TCL, Python etc way. Mainly designed for GUI-progarmming w/o any GUI-designer thus with smaller executables. -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Mon, 6 Jan 2014 02:14:43 +0500
Ivanko B wrote:
> lab1.: create; left=10; top=20
>
> It like the TCL, Python etc way. Mainly designed for GUI-progarmming
> w/o any GUI-designer thus with smaller executables.
I think you missed the point. Real pascal programs
are filled with such things: create an object and set
a few properties, even without any GUI involved.
Some real pascal fragments, from lazarus sources:
lhelpcore.pas:
fServer := TSimpleIPCServer.Create(nil);
fServer.ServerID := fServerName;
fServer.Global := True;
fServer.Active := True;
reglazdaemon.pp:
AProject.AddPackageDependency('FCL');
AProject.AddPackageDependency('LCL');
AProject.AddPackageDependency('LazDaemon');
AProject.Title:='Daemon application';
AProject.LazCompilerOptions.Win32GraphicApp:=False;
AProject.ProjectInfoFile:='project1.lpi';
dbexport/...frmmain.pp:
DBFData.Close;
DBFData.TableName:=AFileName;
DBFData.Open;
printers/...winprinters.inc:
PDev:=TPrinterDevice.Create;
PDev.Name :=PPRINTER_INFO_2(InfoPrt)^.pPrinterName;
PDev.Driver:=PPRINTER_INFO_2(InfoPrt)^.pDriverName;
PDev.Port :=PPRINTER_INFO_2(InfoPrt)^.pPortName;
In all these fragments a WITH clause could have helped, but
I can imagine why it was not used. Besides, pascal is the
only language that implements "with", and many people
criticize it. I don't think so, I like "with", but I have
found another paradigm that in many cases is better.
This "colon repetition" is not limited to "with". See
this other example, a set of declarations:
procedure DoSelectDir(Sender: TObject);
procedure DoSaveLayout(Sender: TObject);
procedure ReadConfig; virtual;
procedure WriteConfig; virtual;
which could be written as:
procedure
DoSelectDir(Sender: TObject);
DoSaveLayout(Sender: TObject);
ReadConfig; virtual;
WriteConfig; virtual;
end
In reality, with the different syntax I think of,
this set of declaration would be written like this:
procedure
DoSelectDir of TObject Sender
DoSaveLayout of TObject Sender
virtual
ReadConfig
WriteConfig
end
end
By reducing repetitions, the syntax pushes
toward a more clean and readable source.
Regards,
linuxfan
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
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 ass
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
In MSElang the example would be written as
"
lab1:= tlabel.create();
with l:lab1 do
l.left:= 10;
l.top:= 20;
end;
==
You probaly don't have TCL experience :
button .btn1 -caption "Exit" -command {exit}
pack .btn1 -padx 5 -pady 5
that's single line per whole definition - reduces definition length
(an important kind of readability) very much.
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Mon, 6 Jan 2014 13:00:02 +0100 Martin Schreiber wrote: > > I would like a language that needs few strokes > > ... precise, expressive, powerful and smart > Yup, mostly the intention of MSElang too, I like to add "readability". Of course. > > verbosity: > > ... > > lab1.: create; left=10; top=20 > > The trick is the colon... > > 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... I think that program sources are text files and always will be. Text files are organized in lines containing words separated by blanks and punctuation, and I stick to it. I don't need to write things like: writeln ; or procedure doit; begin writeln end; procedure again; begin doit end; So, I think that line ends, expressive for the human being, can well be expressive for the compiler too. > 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... No problem, this example is clear, and it shows that me and you have opposite ideas. First, the mandatory "()" for function calls, similar to C. I really don't understand what is its purpose - unless the language allows two identical identifiers in the same scope, "procedure create" and "var create". For C it is different: it is so stupid that I can understand anything. Then your comment cites "overlooked name clashes", and I know the problem. It is a phylosophic concept: should a language assume that the programmer is wrong, or should it assume that the programmer knows what he is doing? I prepend for the second... even if I know that programmers sometimes overlook. But again see: lab1: .create .left = 10 .top = 20 what can be overlooked? Of course, if you open a colon and then write a hundred lines, you can feel a little lost because the code you are writing at line 50 depends heavily on what you wrote on line 1. But program sources are not romantic novels! > > ";". 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. In this case I must say that there is nothing hidden. "Class variable dot constructor" always means "construct that variable", and probably nobody could write such a thing by mistake. It resembles the problem some people have when writing in C: if (a=3) blabla; As you know, this statement is wrong. I arrived from pascal to C about 10 years ago; in ten years, may be I made this error a couple of times; too little to say that it is a serious C problem. > > ... This idea goes even > > further because the colon can be implicit ... > > > 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. Even in my idea they always look the same, if you know the language. But please note that you don't need to use the colon or implicit colon, if you don't want. And about the use of comma and semicolon in order to have the same appearance in declaration and invocation... could be debatable. Declarations and invocations are different things - why they should appear the same? > > > var > > // after a "var" keyword, shouldn't be an > > identifier? // but there is not: so the compiler tells the parser > > // "assume an implied colon" > > This paradigm is simpler and more consistent... > 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'? Perhaps you are missing a little! Of course colon and block termination by "end" applies to everything - not only const var type... - everything. Otherwise, it would not be consistent and useful. Look: // inside a class declaration... procedure DoSelectDir(Sender: TObject); procedure DoSaveLayout(Sender: TObject); procedure ReadConfig; virtual; procedure WriteConfig; virtual; becomes: procedure DoSelectDir of TObject Sender DoSaveLayout of TObject
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Mon, 6 Jan 2014 19:41:22 +0500
Ivanko B wrote:
> In MSElang the example would be written as
> "
> lab1:= tlabel.create();
> with l:lab1 do
>l.left:= 10;
>l.top:= 20;
> end;
> ==
> You probaly don't have TCL experience :
>
> button .btn1 -caption "Exit" -command {exit}
> pack .btn1 -padx 5 -pady 5
>
> that's single line per whole definition - reduces definition length
> (an important kind of readability) very much.
I don't know to whom this comment is directed, because nobody
criticized tcl until now. But to be very precise, these are TWO lines
of code, because without pack the button is useless; while the pascal
source specify geometry with left/top.
Anyway, I find tcl is a very respectable language, and its power goes
far beyond many people think. In designing my language I was inspired
by optional arguments like "-caption", "-command" and so on. Especially
the last one "-command", is concise and pwerful (the power of Tcl!).
Unfortunately it has several defect (but all is debatable...).
Cheers,
linuxfan
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
I don't think it is better... Ouch. Another design principle of MSElang is... [...] === Quite opposite preferentions of two long-time exptrienced programmers. Linuxfan hates typing, Martin (anb me too) hates ambiguity & irregularity :) Less typing means more ambiguity and vie versa. -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Monday 06 January 2014 17:27:32 Ivanko B wrote: > I don't think it is better... > Ouch. Another design principle of MSElang is... > [...] > === > Quite opposite preferentions of two long-time exptrienced programmers. It seems so. :-) 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Monday 06 January 2014 16:34:31 Linuxfan wrote: > > I think that program sources are text files and always will be. > Text files are organized in lines containing words separated by > blanks and punctuation, and I stick to it. I don't need to write things > like: > writeln > ; > > or > > procedure doit; begin writeln end; procedure again; begin > doit end; > > So, I think that line ends, expressive for the human being, can well be > expressive for the compiler too. > I don't agree, sorry. > > 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... > > No problem, this example is clear, and it shows that me and you have > opposite ideas. First, the mandatory "()" for function calls, similar to > C. I really don't understand what is its purpose - unless the language > allows two identical identifiers in the same scope, "procedure create" > and "var create". For C it is different: it is so stupid that I can > understand anything. The purpose is to let a the sub or method call always look the same because of pattern recognition. > Then your comment cites "overlooked name clashes", and I know the > problem. It is a phylosophic concept: should a language assume that the > programmer is wrong, or should it assume that the programmer knows > what he is doing? I prepend for the second... even if I know that > programmers sometimes overlook. But again see: > > lab1: > .create > .left = 10 > .top = 20 > > what can be overlooked? The problem in "with" is if one uses a local variable which is later also added to the "with'ed" class or record. [...] > > look similar. > > Even in my idea they always look the same, if you know the language. > But please note that you don't need to use the colon or implicit colon, > if you don't want. It always should look the same independent if one knows the language well or not. ;-) > And about the use of comma and semicolon in order to have the same > appearance in declaration and invocation... could be debatable. > Declarations and invocations are different things - why they should > appear the same? > A comma in MSElang is a separator, a semicolon is a terminator. And the same look of definition and call also because of pattern recognition. > > > var > > > // after a "var" keyword, shouldn't be an > > > identifier? // but there is not: so the compiler tells the parser > > > // "assume an implied colon" > > > This paradigm is simpler and more consistent... > > > > 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'? > > Perhaps you are missing a little! Of course colon and block termination > by "end" applies to everything - not only const var type... - > everything. Otherwise, it would not be consistent and useful. > Look: > // inside a class declaration... > procedure DoSelectDir(Sender: TObject); > procedure DoSaveLayout(Sender: TObject); > procedure ReadConfig; virtual; > procedure WriteConfig; virtual; > > becomes: > procedure > DoSelectDir of TObject Sender > DoSaveLayout of TObject Sender > virtual > ReadConfig > WriteConfig > end > end > > For my eyes it is cleaner. > This is for me the worst possible indention style, sorry. The whole Free Pascal component library is written in this style, often I need to rewrite a function in my indention style before I can fix bugs in it. It is amazing how different preferences can be. :-) > > > 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. > > Yes. I discovered this, because in more than one point my sources > stopped to work after upgrading freepascal. I don't remember precisely > in which upgrade it happened, perhaps from 2.4.x to 2.6.x. > > Here: > http://www.freepascal.org/docs-html/user/userse62.html > you find: > "Error: Fields cannot appear after a method or property definition, > start a new visibility section first. Once a method or property has been > defined in a class or object, you cannot define any fields afterwards > without starting a new visibility section (such as public, private, > etc.). The reason is that otherwise the source code can appear > ambiguous to the compiler, since it is possible to use modifiers such > as default and register also as field names." > > What
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
print counter+"12" // counter is an integer
===
Is the current "writeln(counter,12)" worse ? Why ?
But "writeln" definetely needs variations with C-style *printf %-formatting:
writeln("%s%d",counter,12);
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Mon, 6 Jan 2014 21:27:32 +0500
Ivanko B wrote:
> I don't think it is better...
> Ouch. Another design principle of MSElang is...
> [...]
> ===
> Quite opposite preferentions of two long-time exptrienced programmers.
> Linuxfan hates typing, Martin (anb me too) hates ambiguity &
> irregularity :) Less typing means more ambiguity and vie versa.
I don't want to speak too much - I will slow down I promise - but less
typing is not necessarily more ambiguity, I think. It depends.
There is no ambiguity when "There is exactly one way to interpret
each program statement syntactically". That's all.
For sure, to fill a language with keywords and punctuation does not
render it less ambiguous; it helps in catching typing errors, probably.
C compilers tend to throw generic errors ("parse error at near...") in
wrong places even if the language itself is not ambiguous. Pascal
instead is very precise in this, and I appreciate it.
>> print counter+"12" // counter is an integer
> Is the current "writeln(counter,12)" worse ? Why?
No no, writeln has nothing wrong. What is wrong is that in pascal you
can't write functions with variable number of arguments, so
write/writeln do violate pascal rules.
> But "writeln" definetely needs variations with C-style *printf
> %-formatting:
> writeln("%s%d",counter,12);
This trick is very handy, especially for international programs, and you
can do it in pascal too using "function(..., [...])" (in theory; in
practice I tried without success).
It also has a big problem, and there is no solution: you can pass
it whatever you want, even without corrispondence to the various "%xx".
When you run a program and you see strange messages like "Error: %s\n",
well, you know they used this trick and something went wrong!
Regards,
linuxfan
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Mon, 6 Jan 2014 18:55:42 +0100 Martin Schreiber wrote: > On Monday 06 January 2014 16:34:31 Linuxfan wrote: > > > > I think that program sources are text files and always will be. > > ... > I don't agree, sorry. Don't be sorry. It is apparent that we have different concepts, stop. > The purpose is to let a the sub or method call always look the same > because of pattern recognition. ...and later... > A comma in MSElang is a separator, a semicolon is a terminator. And > the same look of definition and call also because of pattern > recognition. Pattern recognition... I don't care about it when I *use* a compiler; moreover, I think the compiler should work much more than today's compiler do. It is true that fast compilation is desirable, also. But computers are getting more and more powerful. > The problem in "with" is if one uses a local variable which is later > also added to the "with'ed" class or record. This is a point where we share the same idea! WITH *can* lead to problems, but if the programmer is careful, no problem. > > Even in my idea they always look the same, if you know the language. > It always should look the same independent if one knows the language > well or not. ;-) Hmmm... > > procedure > > DoSelectDir of TObject Sender > > DoSaveLayout of TObject Sender > > virtual > > ReadConfig > > WriteConfig > > end > > end > > > This is for me the worst possible indention style, sorry. Actually the mail program has messed up the indentation, but I understand. Every person has its own tastes. > > "Error: Fields cannot appear after a method or property definition, > > ... > In MSElang modifiers are probably not separated by ";". And this is a good point. > Why should it if it is not necessary? I don't think it is a too big > burden to write > " > f1:= 1.0 + f2 * 2.0; It can be, when not necessary. Who wants to make things clear, can always do, like you. But those that do not want? > > ... converting thenewtype to str8 ... and integer to str8 ... > You always write "s()" because of function overloading. There are no > ambiguities because MSElang has no implicit type conversions. 80% solved. For str8. Then there are utf8, utf16, mcs-4... so you will have su8(), su16(), smcs4()? > > The expectations are 10 times faster compilation times than FPC 2.6.2. > > MSELang is not enough modern. > I don't care. It is a tool mainly for me. Well, what to say. I hope we both succeed in doing our language. With affect, I hope that one day there will be a debate in internet "MSELAng vs Java vs Python vs C# vs Simple"! (Simple is the name I chose for my language). Have a nice evening, regards, linuxfan -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Monday 06 January 2014 20:41:48 Linuxfan wrote: > On Mon, 6 Jan 2014 18:55:42 +0100 > > > > The purpose is to let a the sub or method call always look the same > > because of pattern recognition. > > ...and later... > > > A comma in MSElang is a separator, a semicolon is a terminator. And > > the same look of definition and call also because of pattern > > recognition. > > Pattern recognition... > I don't care about it when I *use* a compiler; moreover, I think the > compiler should work much more than today's compiler do. It is true > that fast compilation is desirable, also. But computers are getting > more and more powerful. > Maybe there is a misunderstanding, I mean pattern recognition by reading the code by a human. :-) I don't know if you read the MSElang Wiki, it is here: https://gitorious.org/mseide-msegui/pages/Mselang The design goals of MSElang: " The design goals Ultimate goal is to build the most productive universal programming environment, usable from programming of microcontrollers to MSEgui projects. I like pragmatic solutions but hate compromises. 1.Simple. Reduce the language concepts one has to learn to the minimum, make them as orthogonal as possible. 2.Readable. MSElang programs should be read like a letter. 3.Easy to learn. Because of 1. and 2. it should be suitable for pupils as first programming language. 4.Powerful Allow to go down to the bare metal, it has pointers and pointer arithmetic. Object orientated high level programming. 5.Fast running State of the art optimizations. 6.Fast compiling While defining the language keep in mind how it can be implemented efficiently. " I don't want to make the language a "fascinating intellectual puzzle" there is enough challenge in finding of best algorithms and architecture of the programs one has to develop... > > The problem in "with" is if one uses a local variable which is later > > also added to the "with'ed" class or record. > > This is a point where we share the same idea! WITH *can* lead to > problems, but if the programmer is careful, no problem. How with Pascal "with" can one be sure that a *newly* added field to a record will not hide a already used variable in an *existing* "with" statement? [...] > > > > ... converting thenewtype to str8 ... and integer to str8 ... > > > > You always write "s()" because of function overloading. There are no > > ambiguities because MSElang has no implicit type conversions. > > 80% solved. For str8. Then there are utf8, utf16, mcs-4... so you will > have su8(), su16(), smcs4()? > If there are no implicit conversions function overloading works for function result types also. I assume the "print()" function uses utf-8? 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
in pascal you can't write functions with variable number of arguments AFAIK, "C uses "va_list" lfor that. And C uses the right-2-left stact order for procedures to handle "va_list" otherwise Pascal uses the left-2-right order making "va_list" handling problematic.Then "writeln" might be implemented as a consequence of single "write"-s for each argument -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Tue, 7 Jan 2014 08:06:45 +0100 Martin Schreiber wrote: > > Pattern recognition... > > I don't care about it when I *use* a compiler... > Maybe there is a misunderstanding, I mean pattern recognition by > reading the code by a human. :-) Yes, there has been. > I don't know if you read the MSElang Wiki, it is here: > https://gitorious.org/mseide-msegui/pages/Mselang Yes I did read it. > The design goals of MSElang: > 1. Simple, 2. Readable. > MSElang programs should be read like a letter. These two points are priorities for me too. This is why: 1. (Simple) I want automatic type conversion, but in a clean context. 2. (Readable like a letter). This is another point. I took inspiration from spoken language, which has little punctuation. Characters like $%&?^| should be avoided if possible, contrary to C. For a human, layout is important, so I make it coincide to the compiler. > 3.Easy to learn ... suitable for pupils Not bad. But very difficult. I have used several languages, and every time I switched, I crashed on pitfalls. Oh, stupid things, but every language has them. There are two types of "pupils": those who don't know programming, and those who know. For the formers, any reasonable language can do, but perhaps little formalism is better (perhaps). For those alreay in programming, may be your idea (a "strict" and polished pascal) could be better at first, but after the first steps productivity would slow down. Don't take it wrong, but after reading your wiki, I had the impression that you make a strong point of formalism (nothing wrong with this), but I don't see the...: > 4.Powerful ... pointers and pointer arithmetic. > Object orientated high level programming. There are two different concepts of "poweful". One, old style: while ((ch=getchar()) != EOF) putchar(ch); ...and assembler is even more powerful, for this. The other style of power is something like: send stream1 every customer.name without pointers, cycles, arithmetics, tests. Of course, nothing forbid to implement pointers in a powerful language: a programmer can decide to use them or not. > I don't want to make the language a "fascinating intellectual puzzle" > there is enough challenge in finding of best algorithms and > architecture of the programs one has to develop... And this is why I want a powerful but simple language! I don't want to always remember that I can't "writeln(myboolean)" because I must explicitly convert it to a str8. And consider that there are not only writelns; consider GTK: it wants utf8, but for some reason (speed? text files? external LCD?) the main program uses ascii, or mcs4 or whatever. Ok, your way to go still works, but I think this can no more be called "power". > > > > The problem in "with" is if one uses a local variable which is > > > later also added to the "with'ed" class or record. This is a very very strong point. In fact, when I first saw php, I was stunned by those variables always referenced with "$", but later I understood. So, we are condamned to be verbose? No, with my colon trick. But even sticking to WITH, the way something else does, there is no problem: with form1 do .caption = caption .left = left ... Why the freepascal team did not change the semantic of WITH? For compatibility? Will you change it? > > 80% solved. For str8. Then there are utf8, utf16, mcs-4... so you > > will have su8(), su16(), smcs4()? > > > If there are no implicit conversions function overloading works for > function result types also. I assume the "print()" function uses > utf-8? This is not clear to me: "overloading works for function resul types also". If you can overload something else than arguments, let me know how do you do it - I am interested (of course, in making it automatic :-) ). Apart from this, I think it is no good to "assume print() uses utf8", because often a program sets captions in GTK, or fields in SQL, or uses external libraries written by someone else. In fact, you say MSELang will support several types of strings, why? To interface with the world, or to burden the language with unnecessary things? I assume all those types are for interfacing with the world, so who know if "external function xx" uses utf8 or EBCDIC. We are criticing each other, but I think this can be useful. I have a question: does MSEIDE support automatic completion? I didn't tried the last version (because of dependency issues); in 2.8.6 a quick try was unsuccessful: if it is there, I don't see it. Regards, linuxfan -- 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?i
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Tue, 7 Jan 2014 12:17:03 +0500
Ivanko B wrote:
> in pascal you can't write functions with variable number of arguments
> AFAIK, "C uses "va_list" lfor that. And C uses the right-2-left stact
> order for procedures to handle "va_list" otherwise Pascal uses the
> left-2-right order making "va_list" handling problematic.Then
> "writeln" might be implemented as a consequence of single "write"-s
> for each argument
No no, freepascal and delphi CAN do that. They have "array of
consts" (or something like that) which you construct with [xx, yy, zz].
The net result is the same as C, and probably more clean.
The problem is that you pass printf() or format() a string and a
handful of arguments:
printf("My name is %s and my age is %d", [myname, myage]);
and there is no check on arguments, and no check on correspondance
between arguments and positional specifiers "%blabla" in the string. In
the example above, the first %s asks for a string, and the second %d for
an integer. If you mistakely pass wrong arguments, or in wrong order
myname and myage, results can be catastrophic!
I tried to use the external function format() in linux libc from
pascal, and I didn't succeed. The problem was that, contrary to what
was stated in the manual, "open array of consts [...]" was not passed
to libc in a working way. I have no problems with delphi, instead; I
often use format() in windows, and every time I do I feel the
deprecating look of Martin behind my shoulders... :-)
Regards,
linuxfan
--
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Tuesday 07 January 2014 09:18:47 Linuxfan wrote:
[...]
>
> This is a very very strong point. In fact, when I first saw php, I was
> stunned by those variables always referenced with "$", but later I
> understood. So, we are condamned to be verbose? No, with my colon
> trick. But even sticking to WITH, the way something else does, there is
> no problem:
>
> with form1 do
> .caption = caption
> .left = left
> ...
>
> Why the freepascal team did not change the semantic of WITH? For
> compatibility? Will you change it?
>
Yes, as showed in the Wiki. MSElang "with" statement is
"
with r: rec1 do
r.field1:= 123;
end;
with r: rec2, s: r.field1 do
r.field1.field1:= 123; //or
s.field1:= 123;
end;
"
> > > 80% solved. For str8. Then there are utf8, utf16, mcs-4... so you
> > > will have su8(), su16(), smcs4()?
> >
> > If there are no implicit conversions function overloading works for
> > function result types also. I assume the "print()" function uses
> > utf-8?
>
> This is not clear to me: "overloading works for function resul types
> also". If you can overload something else than arguments, let me know
> how do you do it - I am interested (of course, in making it
> automatic :-) ).
The type of the function result must match the destination.
> Apart from this, I think it is no good to "assume print() uses utf8",
It is your print() function, you wrote it uses utf-8 IIRC. ;-)
It is not decided up to now if MSElang will have writeln() like procedure or
if that functionality will be moved into the RTL. At the moment I prefer the
latter. Most likely there will be no file functions in the language (reset,
read, write...).
> because often a program sets captions in GTK, or fields in SQL, or uses
> external libraries written by someone else. In fact, you say MSELang
> will support several types of strings, why?
> To interface with the world,
> or to burden the language with unnecessary things? I assume all those
> types are for interfacing with the world, so who know if
> "external function xx" uses utf8 or EBCDIC.
>
For example Lazarus uses utf-8, MSEgui uses utf-16 for GUI and utf-8 for all
external text, often it is necessary to convert to UCS4 for fast code point
access in string manipulation, combining binary data and 8 bit characters in
bytestring is useful too.
> We are criticing each other, but I think this can be useful. I have a
> question: does MSEIDE support automatic completion? I didn't tried the
> last version (because of dependency issues);
What dependency issues? MSEgui solely needs libc and the X11 libraries on
Linux and user32 and gdi32 on Windows.
> in 2.8.6 a quick try was
> unsuccessful: if it is there, I don't see it.
>
There is code completion for classes. There is no Lazarus-style code
completion. That is the first thing I switch off in any IDE. ;-)
What works is code navigation by Ctrl+LeftClick, procedure parameter listing
by Shift+Ctrl+Space after the "(" and header-implementation switch by
Ctrl+Up, Ctrl+Down.
Many years ago I promised to make some efforts for Lazarus-style code
completion in MSEide if the MSE community shows some substantial work on
documentation of MSEide+MSEgui. Nothing happened. Now I don't feel obligated
to keep that promise anymore. :-)
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On Tuesday 07 January 2014 10:07:25 Martin Schreiber wrote:
>
> There is code completion for classes. There is no Lazarus-style code
> completion. That is the first thing I switch off in any IDE. ;-)
> What works is code navigation by Ctrl+LeftClick, procedure parameter
> listing by Shift+Ctrl+Space after the "(" and header-implementation switch
> by Ctrl+Up, Ctrl+Down.
I forgot, there is a sophisticated code template functionality too. I never
use it, that thing I made especially for Graeme. :-)
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
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On 01/06/2014 01:00 PM, Martin Schreiber wrote: > with l:lab1 do l.left:= 10; l.top:= 20; end; " I do like the "quoted with" as same eliminates the ambiguity that is inheritant to with (hiding part of the namespace of outer with, the class and globals). To me with "l:=lab1" would be more logical as it works as if creating a variable of the appropriate type and assigning that value to it. -Michael -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On 01/07/2014 08:17 AM, Ivanko B wrote: > in pascal you can't write functions with variable number of arguments > AFAIK, "C uses "va_list" lfor that. Yep. I use it a lot. (Important for C: there is a corresponding concept and syntax in Macros that supports this. ) In Pascal we have the concept of open arrays with differently typed variables for this, including the possibility to define constants of this type on the fly in function calls. This is at least equivalent. -Michael -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
Am 07.01.2014 12:24, schrieb Michael Schnell: > On 01/06/2014 01:00 PM, Martin Schreiber wrote: >> with l:lab1 do l.left:= 10; l.top:= 20; end; " > I do like the "quoted with" as same eliminates the ambiguity that is > inheritant to with (hiding part of the namespace of outer with, the > class and globals). > > To me with "l:=lab1" would be more logical as it works as if creating a > variable of the appropriate type and assigning that value to it. > The reason why ":" instead of ":=": ":=" is an assignment. "with" is fetching the address of a data structure which is the first step of an assignment. The first step of ":=" is ":". ;-) 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSELang heretic ideas
On 01/07/2014 12:07 PM, Martin Schreiber wrote: > The first step of ":=" is ":". ;-) Nice !:-) :-) :-) -Michael -- 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
