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 to say. It may be that the programmer at freepascal chose the > wrong way. They could have simply forbidden to create identifiers named > "register" or "default" and so on. Or they may be right. Or pascal > language is flawed from the base. It is difficult to say. I think that > putting optional modifiers *after* the declaration is a bad idea. But > no languages are perfect. In my design, the general form of a > declaration is: > > keyword [modifiers] type identifier > > like: > var global int copies > In MSElang modifiers are probably not separated by ";". [...] > Now a serious discussion; I've read some messages on this list about > types, conversions and so on. I found them very extreme, especially if > you think that every processor has a preferred bit size. I agree that > promoting from number to string should not be implicit; but why not, > under precise rules?. 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; " instead of " f1:= 1 + f2 * 2; " for the benefit that it is always visible what happens independent if one knows the precise rules. > This is why I say that type system is too loose > in almost any language. Because "integer" can signify too many things, > not to say strings. > > > In MSElang one probably would write > > " > > sub s(const value: thenewtype): str8; > > begin > > > > := DoTheConversionWithValue; > > > > end; > > ... > > print(s(TheNewTypeValue)); > > " > > So you must remeber how is the name for converting thenewtype to str8. > And integer to str8, and boolean to str8, and boolean to utf8, and > integer to utf16. And what is worse, you always have to write them each > time you need them. > You always write "s()" because of function overloading. There are no ambiguities because MSElang has no implicit type conversions. [...] > > > 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. :-) > > I think we have nothing to share, until now. You are probably right. > No offence, of course - we > are speaking of different ideas. The MSELang approach seems to me a > worser pascal, and that is all. If you will succeed in writing a > MSELang compiler, it will be 20% faster in compilation, The expectations are 10 times faster compilation times than FPC 2.6.2. > 3% faster in > execution, and users will not want to use it. Of course, there will be > a 2% users, targeted perhaps to embedded systems, which will appreciate > the precision and rigidness, but the 98% will think that MSELang is not > enough modern. I don't care. It is a tool mainly for me. If there are people who like to participate it is OK, if not it is OK too. I must do the whole work myself anyway, same as had to develop MSEide+MSEgui myself because I needed such a tool. I couldn't wait until somebody made it for me. :-) Anyway, thanks that you shared your thoughts with us. 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
