Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: > It's a simple fact: > 90% if not more of all pascal code out there is Delphi code. Being able to > compile and > re-use that is FAR more important than changing the fact that begin/end is > required in > pascal. ACK. > You want to make some 'Auto-Maintained' variable support, of the kind: > Autovar > S : TStrings; > > begin > S:=TStringList.Create; > end; // compiler disposes of S. If somebody wants local objects, then he should use Object instead of Class. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> > using them hard or impossible becomes a toy language. > > But it doesn't. The only time they are a problem is when the stuff you > are storing in the tree or list is an *object* and that *object* points > back to either the container or the list that stores it (which is very > rarely done). The most likely case for that is if you added a self > reference - I prefer languages that work, not that most likely work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote:
> Michael Van Canneyt wrote:
>
> > I suggest you create an external preprocessor, and limit yourself to
> > that.
> >
> > I don't consider your construct to be Pascal, so I will fight inclusion
> > of it in the compiler, not even under some {$Mode} construct.
>
> Well all I ask is you wait til I have written it then give it a chance. If you
> still feel bad about it then we can discuss what to do then. If it turns out
> that you all insist on begin..end being mandatory then i will respect your
> wishes and no feelings will be hurt.
Look, it's a matter of principle. I consider ANY language which uses the amount
of whitespace in it's grammar to be inherently badly designed.
> I believe it will help Pascal and breathe
> new life into it especially as its a dying language.
It has lived longer than most languages, so I don't think this is so.
> I also note there is no
> such thing as "Pascal" as such even Delphi has significant syntax differences
> with earlier pascal variants so I hope that's taken into account.
No it is not. The change you suggest is fundamentally different from the
dialects
we have till now; you are changing one of the fundamental principles, namely
whitespace is irrelevant, just as casing is. This is, in my eyes, a different
language - anything BUT pascal.
>
> >
> > The compiler is GPL, so you are free to change it, but that doesn't
> > necessarily mean your changes will make it back in the compiler main
> > sources.
>
> If not I can always maintain a branch that does. (though I would prefer it if
> it is included of course)
Not if I can help it.
I realize this may come over quite hard, but I prefer you would do something
USEFUL
which actually contributes to Free Pascal. Creating yet another obscure dialect
is not
helpful. We are having enough problems getting in Delphi compatibility stuff.
It would
be MUCH more appreciated if you would help with that.
It's a simple fact:
90% if not more of all pascal code out there is Delphi code. Being able to
compile and
re-use that is FAR more important than changing the fact that begin/end is
required in
pascal.
You want to be useful ? Do one of the following:
- Complete Variant support.
- Implement Packages support.
- Overloading for property indexes.
- DISPINTERFACE support, plus OLE automation calls.
- Extend the Optimizer.
You want to make some 'Auto-Maintained' variable support, of the kind:
Autovar
S : TStrings;
begin
S:=TStringList.Create;
end; // compiler disposes of S.
Please, go ahead. Anything that is useful. But not creating another dialect.
I've been on the compiler team for almost 10 years, and we've heard lots of
crazy
offers in that time. We've ignored most of them, and good too, or else we
wouldn't
be where we are today. Yours just happens to be one of them. Sorry.
I prefer to let you know in advance instead of letting you work hard and then
shoot
off your efforts.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| will respect your wishes and no feelings will be hurt. I believe it will | help Pascal and breathe new life into it especially as its a dying | language. I also note there is no such thing as "Pascal" as such even | Delphi has significant syntax differences with earlier pascal variants | so I hope that's taken into account. | Things like smalltalk, tcl.. those are dying according to sourceforge (40 projects or so.. whereas Delphi has hundreds or 1000's. If you want to tell smalltalkers that they are dying because there are only 30 or 50 projects on source forge.. well go to c2.com wiki, there are plenty of them programmers there, doing work for banks and all sorts of places. If you want to tell Borland that Delphi is dying due to dotNet, then just download any popular Delphi application out there like the latest version of totalcommander and you tell me if it has any significant amount of dotNet code in it. What is said to be "dying" is most likely a rumor placed out by foolish of fools like Bryan Kerinighan who even sell books on Pascal themselves. In fact Pascal/Delphi is still one of the most popular languages - at one time I think there were more projects in Pascal than visual basic on source forge.. now VB has slightly more. But it's not as if there are 50 projects in Pascal... like other languages. No there are hundreds, thousands in Pascal/Delphi. I guess the problem is that once you start changing a language, what is it anymore? When does a Mercedes car become no longer a Mercedes car when it has 80 percent your own parts on it? Wouldn't you kill the Mercedes name and call it something else.. a new breed of car? i.e. why would you even call your language Pascal or why would it have anything to do with Pascal in the first place.. why not call it something else, since it is a new breed.. Wouldn't want to carry the Pascal "bad name" anyway, right? Maybe because there is already a compiler and you want to re-use code? I don't know. I think maybe even a better place to start then might be python mailing lists or python compiler sites if there are any. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[moderator] Re: [fpc-devel] Re: [fpc-l] type discussion
On 05 Jun 2005, at 15:22, Jamie McCracken wrote: I believe it will help Pascal and breathe new life into it especially as its a dying language. And with the above insightful and undoubtedly uncontroversial comment I think we can close this thread here. I would therefore like to ask all people who wish to continue this thread to either move to fpc- other, or to continue in private. Thank you. Jonas FPC mailing lists moderator ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
Well all I ask is you wait til I have written it then give it a chance.
If you still feel bad about it then we can discuss what to do then. If
it turns out that you all insist on begin..end being mandatory then i
will respect your wishes and no feelings will be hurt. I believe it will
help Pascal and breathe new life into it especially as its a dying
language. I also note there is no such thing as "Pascal" as such even
Delphi has significant syntax differences with earlier pascal variants
so I hope that's taken into account.
The compiler is GPL, so you are free to change it, but that doesn't necessarily
mean your changes will make it back in the compiler main sources.
If not I can always maintain a branch that does. (though I would prefer
it if it is included of course)
jamie.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote:
> Michael Van Canneyt wrote:
> >
> > On Sun, 5 Jun 2005, Jamie McCracken wrote:
> >
> >
> > > Hans-Peter Diettrich wrote:
> > >
> > >
> > > > > Not at all; I certainly don't indent them, and I'm a fanatical
> > > > > indenter.
> > > >
> > > >
> > > > Agreed. I really can't understand why some people indent like
> > > > this:
> > > > if ...
> > > > then
> > > > begin
> > > > ...
> > > > end
> > > > else
> > > > if
> > > > ...
> > >
> > > lol - thats not what I meant. If you want readable code you indent
> > > inside the
> > > begin..end blocks ergo the begin..end syntax becomes redundant cause
> > > its the
> > > indentation that provides the visual cue.
> >
> >
> > Visual, yes. But not for the compiler: it folds whitespace.
> > The compiler NEEDS the begin...end to check your syntax. How is it
> > supposed to know where a stament block begins/ends ? Based on indendation
> > alone ? That would not be Pascal...
>
> yes you are right it exists for the benefit of the compiler rather than the
> developer.
>
> My plan in the RAD Pascal dialect is to preprocess each line and put back the
> begin/end where the indentation occurs/varies without altering the line
> numbers. The compiler already has an internal preprocessor so I will simply be
> extending that. If the end result is not to your liking then continue using
> other dialects as none of my changes will affect them. Of course there is
> nothing stopping you from continuing to use begin end blocks in RAD Pascal if
> you really want to but they will be optional whereas indenting will be
> compulsory (you will get an error if your indenting is not consistent!)
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
The compiler is GPL, so you are free to change it, but that doesn't necessarily
mean your changes will make it back in the compiler main sources.
Things that are considered constructive, may make it in.
This does not fall under that category, in my opinion.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Op Sun, 5 Jun 2005, schreef Jamie McCracken: yes but isn't it fair to say that such developers that require such structures would be knowledgable enough to make it safe by using weak refs? What is a weak ref? Allows you to make a reference without increasing or affecting the ref count of an object. My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs? I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes using them hard or impossible becomes a toy language. But it doesn't. The only time they are a problem is when the stuff you are storing in the tree or list is an *object* and that *object* points back to either the container or the list that stores it (which is very rarely done). The most likely case for that is if you added a self reference - EG mylist : Tlist; mylist := TList.create; mylist.add (mylist); // now you have a self referencing cycle The above could still be implemented safely in the add method of Tlist by testing for a cycle and using a weak ref to add mylist to mylist. BUt of course why would you ever want to add a self referencing cycle to a TList? Hmmm... Is a double linked list a cycle? I think yes. I dont think so. The list nodes are usally a record/struct not an *object* and whilst they do form a chain, the items pointed to in the list dont point back to that list so no it is not a cycle. Cycles are rare by the nature in objects however they are more common in GUIs where widgets and components link together. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Sun, 5 Jun 2005, schreef Jamie McCracken: > yes but isn't it fair to say that such developers that require such > structures would be knowledgable enough to make it safe by using weak refs? What is a weak ref? > My point is that the everyday structures that most developers (and in > particular the more naive and less knowledgable ones) will use are not > vulnerable to cycles and its only the more obscure and specialised use > cases that will need to use weak refs. In those cases like building a > compiler is it reasonable to assume that they will be smart enough to > handle cycles with weak refs? I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes using them hard or impossible becomes a toy language. Hmmm... Is a double linked list a cycle? I think yes. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
L505 wrote: Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline? of course it is - any formal language will have some "bondage" in their syntax. Indentation and Begin..End are such examples but in my case forcing developers to write properly indented code (which is essential for legibility as im sure you will agree) is not a disadvantage as such if you consider it a neccesity anyhow. I suggest you wait until I have something working then we can discuss the finer points. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Op Sun, 5 Jun 2005, schreef Jamie McCracken: Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that. H... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example. yes but isn't it fair to say that such developers that require such structures would be knowledgable enough to make it safe by using weak refs? My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs? jamie. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| yes you are right it exists for the benefit of the compiler rather than | the developer. incorrect. When reading code I always use the bold begin/end's. Why do you think they are bold? Are they bold because the compiler likes them bold? See, a bold begin and end is a lot easier to see than a parenthesis. Parenthesis is tough to see on a high res monitor. There is a reason begin and end are bold, and that has nothing to do with the compiler. They are useful also for the developer. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Sun, 5 Jun 2005, schreef Jamie McCracken: > Its not a black or white issue IMO its a shade of grey. At the end of > the day you have to make a judgement call based on the facts. Im > asserting that with non-component objects the incidence of cycles is so > rare that provided we have a means of adding weak refs so that > knowledgable developers can overcome them when they do occur then the > issue of cycles can be ignored - after all if the probability of leaks > is based on a one in a million occurance of a cycle (Im not saying thats > an accurate probability!) coupled with an ignorant or naive developer > then thats an acceptable risk to me. If it turns out that cyclic > occurances are far more common than that then yeah that could be a > killer. There are of course workarounds but I dont like any of them - EG > python 2.3 does ref counting but also uses a mark sweep GC to mop up > cicrular refs but I really dont think we need to consider that. H... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| | lol - thats not what I meant. If you want readable code you indent | inside the begin..end blocks ergo the begin..end syntax becomes | redundant cause its the indentation that provides the visual cue. | That's like taking question marks out of sentences that you know are questions. Why have question marks if you know it is a question? If there is a space after the question, and the question always starts with something like "what", "where" "when" why", then -what good- is a question mark? There are plenty of reasons. One is that the human brain doesn't have time to figure out whether or not it is a question.. it is just a extra helper symbol to verify that. The other is that if you are looking specifically for questions and you don't have time to read the entire article, at least you can easily see them ( ¿even easier in spanish?). The other is that when you start deleting words from the sentence, at least the question mark still is there after you've deleted some text. And you know that the structure of words is still supposed to be a question, even if after deleting things. You would have less change of knowing it was a question if there was no question mark.. because after deleting some stuff and reorganizing your article, it may appear as though it is a regular sentence, not a question. Personally I like spanish upside down question mark, because it would help me when I was scanning articles for questions from forward to end. English question marks only help me when I am scanning the article from backward to forward. I've never taken or learned spanish though, so I am not bias. So maybe you think spanish is redundant, but I think even one question mark is sometimes not enough. Start deleting your code without begin end blocks and reorganizing things.. if these visual pointers are not there you may end up putting code in places that are not correct, because you accidentally lost that indentation while hitting delete key, and while the editor wasn't indenting the way you thought it would. If the begin end were there, at least you'd have a secondary opinion from the code telling you.. "hey.. wait, this is supposed to be a begin end block here, even if your indentation is wrong after refactoring." I lost my indentation, but at least I know where it goes, due to the secondary helpers begin and end. Just because my text editor was acting funny with tabs today, all my code is not broken? Because of the secondary savers. begin Ididntindent:= 'yes'; afterrefactor:= true; end; Where does this code go below? I lost my indentation, so where does it go in the code??? Just because my text editor was acting funny with tabs one day all my code is broken now? Ididntindent:= 'yes'; afterrefactor:= true; Personally, I use indenting for other parts of organizing code once in a while.. not just for begin end. So if was to write: othervar:= 'test'; othervar2:= 'test2'; setting1:= true; for i:= 1 to 5 do begin edit1.color:= red; ... ... end; othervar:= 'testa'; othervar2:= 'testb'; setting2:= true; for i:= 1 to 5 do begin edit1.color:= red; ... ... end; See how setting1 and setting2 is tied to the for statement using indentation of the for statement? I do that because the for statement only applies to setting 2. Helps organize code. Helps show that setting2 only really applies to that for statement. So if I had forced indentation on me, that may be illegal and that may initiate a begin end when I didn't even want it to. Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: On Sun, 5 Jun 2005, Jamie McCracken wrote: Hans-Peter Diettrich wrote: Not at all; I certainly don't indent them, and I'm a fanatical indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... lol - thats not what I meant. If you want readable code you indent inside the begin..end blocks ergo the begin..end syntax becomes redundant cause its the indentation that provides the visual cue. Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal... yes you are right it exists for the benefit of the compiler rather than the developer. My plan in the RAD Pascal dialect is to preprocess each line and put back the begin/end where the indentation occurs/varies without altering the line numbers. The compiler already has an internal preprocessor so I will simply be extending that. If the end result is not to your liking then continue using other dialects as none of my changes will affect them. Of course there is nothing stopping you from continuing to use begin end blocks in RAD Pascal if you really want to but they will be optional whereas indenting will be compulsory (you will get an error if your indenting is not consistent!) jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote: > Hans-Peter Diettrich wrote: > > > > Not at all; I certainly don't indent them, and I'm a fanatical > > > indenter. > > > > > > Agreed. I really can't understand why some people indent like this: > > if ... > > then > > begin > > ... > > end > > else > > if > > ... > > lol - thats not what I meant. If you want readable code you indent inside the > begin..end blocks ergo the begin..end syntax becomes redundant cause its the > indentation that provides the visual cue. Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Hans-Peter Diettrich wrote: Not at all; I certainly don't indent them, and I'm a fanatical indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... lol - thats not what I meant. If you want readable code you indent inside the begin..end blocks ergo the begin..end syntax becomes redundant cause its the indentation that provides the visual cue. Two cons for reference counting: - It fails on circular references. Fatal :-( Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > Those lazarus tools are great but they require advance knowledge of > those tools that new users wont have (at least somebody using lazarus > for the first time is not going to know all the keyboard shortcuts). Not > having to rely on hacks around the coding inefficiency of a language > with keyboard shortcuts is always a plus in my book too. Editors with macro capabilities are not hacks, and the shortcuts for macro invocations are not built into the editors. You'll need equivalent macros for maintaining an indentation structure, and, even worse, you're almost lost without such macros, due to the lack of redundancy! DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Angelo Bertolli wrote: > > Begin..End is redundant - you have to indent them to make em readable > > anyways. > > > Not at all; I certainly don't indent them, and I'm a fanatical > indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... > I don't think you're going to convince anyone to change THIS > part of Pascal--it's essential. You change begin and end, and you just > don't have Pascal anymore. Some things could be changed, and have been changed for good reasons, in subsequent designs (Modula, Oberon). When all arbitrary occurrences of statement and statement_sequence in the Pascal grammar are replaced by a unique statement_list, where a statement list is terminated with an "end", the whole language becomes simpler and much clearer. It also will eliminate the "dangling else" ambiguity, that exists in the majority of all existing language designs. You'll notice the difference neither by looking at the code, written according to this syntax, nor by simply looking at the grammars. But you'll notice the difference when you're writing the parsers and find the semantics actually different from the syntax. In many languages the syntactical grammar is a simplified and generalized picture of the semantics, so that the parser has to check for specific cases in many places. In good designs, as provided by Wirth, no difference between syntax and semantics can exist. This unfortunately is no more true for OPL, where optional semicolons must be introduced into to the syntax in very many places. Then only the parser can decide, whether in such places a semicolon is actually mandatory, optional, or illegal, depending on whether a semicolon has already been consumed by some preceding optional occurence. Consequentially the meaning of some code can change dramatically, only depending on the occurence or absence of a semicolon in a specific place! My favorite example: case i of 0: if a then b ; //<--- illegal, optional or required? else c end; > > manual memory management of tobjects is redundant as you can get good > > performance with ref counting tobjects. > > > Oh yes, this old argument. I remember reading this on the list before. > I guess it's still on your mind ;) I really don't know about the pros > and cons for ref counting, so maybe someone can explain it. Two cons for reference counting: - It fails on circular references. Fatal :-( - Counting operations increase with the number of executed statements. Mark/sweep collections, in contrast, increase with the number of object creations, not with the number of object uses. But their execution time depends on the number of existing object references, regardless of whether objects really can be removed. Both kinds of garbage collection can work (reliably) only under specific conditions, which are not satisfied in OPL :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
El Sábado, 4 de Junio de 2005 12:02, Jamie McCracken escribió:
> Nico Aragón wrote:
> > I've been playing with the same concept for years, so I think I do have
> > some advice :-) The preprocessor is the right step to start
>
> Which the compiler's internal preprocessor or your external preprocessor?
Internal, if all you want is to create a new dialect to integrate inside FPC
as {$MODE RADPASCAL} and you are sure your patches will be accepted by core
developers.
External otherwise. I want something more than this kind of arrangement, so I
chose external. YMMV.
--
saludos,
Nico Aragón
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
Nico Aragón wrote: El Sábado, 4 de Junio de 2005 11:00, Jamie McCracken escribió: I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor. See the recent thread "How to manually control debug information" in this list. I asked the very same thing. I admit I hadn't read it before but I already knew an external preprocessor was more a last resort cause of the hacky nature of correlating virtual line numbers to physical line numers. For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar. If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here. I've been playing with the same concept for years, so I think I do have some advice :-) The preprocessor is the right step to start Which the compiler's internal preprocessor or your external preprocessor? I prefer the internal one cause it means no external dependencies but then again if its too dificult to use... . I have a working scanner and the next tasks (conditional "compilation" and expressions) planned in detail. If you're interested, we could share the work. If I get bogged down with the compiler internals then yes I'll be happy to collaborate then. As I said IMO the external stuff is a last resort to me not a first but thanks anyway for the offer - I will be in touch if I need an external one. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
El Sábado, 4 de Junio de 2005 11:00, Jamie McCracken escribió: > > I had thought of that but thats problematic for debugging. IE the > compiler returns line numbers for errors and they will not match if I > use an external preprocessor. See the recent thread "How to manually control debug information" in this list. I asked the very same thing. > For replacing Begin..End blocks with indents in my new dialect I planned > to use the compiler's internal preprocessor in the compiler to put back > the begin/end blocks without affecting the line numbers. I can do > likewise for syntactic sugar. > > If you or anybody else has advise on how best to implement it then > please let me know - I apreciate anything that will help me here. I've been playing with the same concept for years, so I think I do have some advice :-) The preprocessor is the right step to start. I have a working scanner and the next tasks (conditional "compilation" and expressions) planned in detail. If you're interested, we could share the work. -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
Hans-Peter Diettrich wrote: You obviously missed that a compiler does not only consist of scanner and parser, but that optimizers and code generators also have to be implemented. For multiple target platforms and CPU's... The new dialect simply makes the syntax less annoying and verbose - it wont alter functionality as such so altering those shouldn't be on the agenda (I hope!). The new dialect simply requires a multi pass parser. It shouldn't be too hard to adapt the existing one for this purpose. Of course the compiler will only use this if the source file tells it to use Rad Pascal dialect so it wont affect or harm compiler performance of other dialects. I can also totally eliminate circular refs in the multi pass phase (it will require three passes if there are circular refs, otherwise one or two passes will be sufficient). The advantage for the developer here is that only one uses clause ever needs to be used. Looking at the tokens.pas file in the compiler, every token in the parser is specified against which dialect implements it (via the mode switch) so it shouldn't be too difficult to remove any redundant syntax where its not needed. (I emphasize removing not adding syntax here!) The safe approach is to write an preprocessor, that can translate your dialect into any implemented language, so that the compiler code must not be touched. Then you'll find out that your dialect needs code completion and other features, that have to be implemented as well, apart from the compiler. These are fine exercises before you start bothering with the compiler code. I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor. For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar. If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here. Thanks jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > Well I will typically spend about 25% of my development time with > forward declarations, doing loads of try finaly blocks to free memory > and other things instead of implementing my application. Then you may have a bad exception handling model. Try-Finally is required only when there are chances that an exception will abort the current subroutine. Can't you find a less expensive method for steering the regular control flow, besides by throwing exceptions? Do there really exist so many situations, where an action frequently is aborted due to some error, so that such occurences can be considered as "normal operation"? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as > FPC supports multiple dialects it can slip in without affecting existing > code so if people dont like it they dont have to use it. Im quite happy You obviously missed that a compiler does not only consist of scanner and parser, but that optimizers and code generators also have to be implemented. For multiple target platforms and CPU's... > to write it myself but I will need help on where to look and what to > modify in the compiler as im not familliar with the compiler source (I > cant even find the grammar for the language so I take it you dont use a > table driven or auto generated parser like yacc) You'll find an (incomplete) grammar, with railroad diagrams, in the syntax description. In the last version the code resides in the compiler directory, you may have to download the compiler and library sources separately. Another (simpler) parser can be found in fcl\passrc\pparser.pp, but it is not so close to the current FPC parser. And yes, the parser is a handcrafted top-down (recursive descent) parser, easier to maintain, extend, and debug, than bottom-up parsers. Of course you can use CoCo/R for your parser, if you want an parser generator, or lex/yacc if you like, for which also ports with Pascal output are available (dyacclex, tply). BTW, for code completion and other RAD features, a top-down parser is almost the only choice, because it allows to parse specific parts of the code (statements...). In a bottom-up parser you have little chances to find equivalent initial and final states for the parser automaton. The safe approach is to write an preprocessor, that can translate your dialect into any implemented language, so that the compiler code must not be touched. Then you'll find out that your dialect needs code completion and other features, that have to be implemented as well, apart from the compiler. These are fine exercises before you start bothering with the compiler code. Hmm, why don't you start with the Lazarus sources? There you'll find everything related to entering and editing source code, code explorer and other RAD features... If you found the source code, please open another thread for further discussion. Perhaps there exists another mailing list for Lazarus? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: "Hans-Peter Diettrich" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Thursday, June 02, 2005 3:27 PM ... > More important: Unicode literals. But I know that this would require a > very big change to the scanner, and to all code editors and other tools. > Perhaps somebody has another idea how to solve this problem? How should they look like? (example please) Or do you think about writing the programs in Unicode text files? gs ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marc Weustink wrote: -- Class Contracts I like the 'require/ensure' aproach. It makes the code more robust and more debuggable, IMHO I think the checks you can do there are to limited. I also wonder what will happen if a require isn't met. Personally I don't want exeption in my released app. No, these are assertions not as exceptions. OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ? IMO you still need some code which takes proper action You have a point here. That, I suppose could be handled through runtime options. But, a construct something like require [...] otherwise [...] end; ensure [...] otherwise [...] end; would be needed. -- Generics I am not sure if Generics could be done in FPC. There were some discussions about it here and AFAIK some are trying to implement. Any links? http://www.freepascal.org/wiki/index.php/Generics Thanks. -- Virtual Properties and Events The examples given there are not very different of what is possible now. Make SetWith virtual and you have almost the same. What however would be nice is if you could override the getter or setter. Something like property Width write MySetWidth I think you missed a few things here. type TMyClass = class ... property Width: integer read write; virtual; abstract; end; As you can see, getters and setters are not in the picture at all. Which means, you have all the freedom you want in the derived class. Which is allmost the same as a virtual abstract Getter and Setter (almost, read/write from a field isn't covered) Plus, I like the idea that I could have a base class with read-only property that can not be overriden to be read-write later. property Width: integer read; virtual; abstract; That makes some sense (but it would be incompatible with existing code) Why would it. Existing code does not have virtual properties. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Vincent Snijders wrote:
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use
it - stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for the offer, where can I download the patch? I would like to
try this too.
Patience! Its vapour ware at the moment.
Im just familiarising myself with the compiler source at the moment so
give me a few months to implement it. Once I have something I will post
a patch here.
Glad to see some of you are interested in it :)
jamie.
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 16:12, Marco van de Voort wrote: > > > Begin..End is redundant - you have to indent them to make em > > > readable anyways. > > > > No. This makes the code more readable like normal english text. It > > states much more clearly what it intents, at least much more than > > just indenting or putting curly braces around it. > > Not every syntax is about minimizing code or readability. The latter it should. > Some are > also to simply simplify parsing (and that is about compiler > developer, but to make the language more internally consistent) and > avoid long lookaheads. These things combined also improve quality of > error messages a lot. Well, it is still named "begin", "end", not "x0x0x0" "0x0x0x", is it? ;-) And for the compiler: it wouldn't make a difference if you'd parse "begin end" or "curly braces" tokens, would it? > > > Maintenance is easier as their is less redundancy. > > > > It simply depends on the kind of redundancy. > > > > For instance, "type" and "var" keywords are just redundant, the > > compiler could figure it out by itself, still they serve a useful > > purpose. > > See above. Yes, it might make the compiler writer's job easier. But typically you don't design a language around a compiler. And I strongly doubt that Wirth did. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for the offer, where can I download the patch? I would like to
try this too.
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Friday 03 June 2005 10:47, Jamie McCracken wrote: > It makes it more clear IMO not less. having all that interface code > and having to jump between it and the implementation does not aid > legibility. It encourages reading code instead of interface specifications. Often there is a big discrepancy between what the code is supposed to do and what it really does. If a fellow programmer relies on the latter this is known to break sooner or later. Of course, this implies that there *is* a specification. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marc Weustink wrote:
Jamie McCracken wrote:
[snip]
would become under Rad Pascal:
uses
Classes, SysUtils;
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count);
destructor destroy; override;
inherited Destroy;
Notice its at least 50% less code to write.
Hmm less to write... and maintain ?
Go for example to the lazarus project and try to write the controls.pp
unit this way. Do you still think it is a good idea ? When all code is
put in the class header itself, can you still tell what methods a class
has ?
not a problem for an IDE - it can extract the methods and in fact visual
studio does that for c#. And likewise with the code explorer in lazarus.
Besides, when we are at Lazarus (or Delphi), when you have typed
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
destructor destroy; override;
end;
and press ctrl+shift+c it will generate the whole body. Which is already
less typing :)
You have to type even less if you start with
classf
and then press ctrl+j
So what is the point to make the language less clear, while there tools
exist which do most of the annoying typing for you ?
It makes it more clear IMO not less. having all that interface code and
having to jump between it and the implementation does not aid
legibility. Having it all nicely tied up in my proposed Rad Pascal, C#
and python does.
Those lazarus tools are great but they require advance knowledge of
those tools that new users wont have (at least somebody using lazarus
for the first time is not going to know all the keyboard shortcuts). Not
having to rely on hacks around the coding inefficiency of a language
with keyboard shortcuts is always a plus in my book too.
At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
jamie.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
listmember wrote: >>>-- Class Contracts >>>I like the 'require/ensure' aproach. >>> >>>It makes the code more robust and more debuggable, IMHO >> >> I think the checks you can do there are to limited. I also wonder what >> will happen if a require isn't met. Personally I don't want >> exeption in my released app. > >No, these are assertions not as exceptions. OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ? IMO you still need some code which takes proper action >>>-- Generics >>>I am not sure if Generics could be done in FPC. >> >> There were some discussions about it here and AFAIK some are trying to >> implement. > >Any links? http://www.freepascal.org/wiki/index.php/Generics >>>-- Virtual Properties and Events >> The examples given there are not very different of what is >> possible now. >> Make SetWith virtual and you have almost the same. >> >> What however would be nice is if you could override the getter >> or setter. >> Something like >> property Width write MySetWidth > >I think you missed a few things here. > >type > TMyClass = class > ... > property Width: integer read write; virtual; abstract; > end; > >As you can see, getters and setters are not in the picture >at all. Which means, you have all the freedom you want in >the derived class. Which is allmost the same as a virtual abstract Getter and Setter (almost, read/write from a field isn't covered) >Plus, I like the idea that I could have a base class >with read-only property that can not be overriden to be >read-write later. > > property Width: integer read; virtual; abstract; That makes some sense (but it would be incompatible with existing code) >OK, while I like the idea, I can not think of how I would >use it though :-) Can someone help me out here :-) >>>-- Enhanced Multicast Events > >> This is not really new. You can implement it yourself like >> >> property OnChange: TNotifyList; >> >> and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc) > >OK. Nice to be able to do that. Do I have to write my >TNotifyList every time I need it? Not if you have generics ;) >>>Inline variable initializers, such as: >> >> [snip] >> >> >>>var >>> Integer1: Integer = 15; >>> Boolean1: Boolean = False; >>> String1: String = 'SOME TEXT'; >> >> Hmm.. sometimes usefull. You can put it as first lines > > in your constructor/codeblock, but keep it thogheter in > > say large classes can be handy. > >Yes, and it improved the readability, IMHO. Plus, there is >no reason for you to alter that in constructor/codeblock too. Not too. It is still edited at one place. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: [snip] >would become under Rad Pascal: > >uses > Classes, SysUtils; > > TMyObject = class (Tobject) > private > count : integer; > public > constructor create; override; > inherited Create(AnOwner); > inc (count); > > destructor destroy; override; > inherited Destroy; > > >Notice its at least 50% less code to write. Hmm less to write... and maintain ? Go for example to the lazarus project and try to write the controls.pp unit this way. Do you still think it is a good idea ? When all code is put in the class header itself, can you still tell what methods a class has ? Besides, when we are at Lazarus (or Delphi), when you have typed TMyObject = class (Tobject) private count : integer; public constructor create; override; destructor destroy; override; end; and press ctrl+shift+c it will generate the whole body. Which is already less typing :) You have to type even less if you start with classf and then press ctrl+j So what is the point to make the language less clear, while there tools exist which do most of the annoying typing for you ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 15:23, Jamie McCracken wrote: > Vinzent Hoefler wrote: > >>manual memory management of tobjects is redundant as you can get > >> good performance with ref counting tobjects. > > > > That can be a point, yes. But it is somehow not related to any > > syntax. > > It means not having to bother with my pet hate the try..finally..free Well, try/finally is mainly for handling exceptions, not for handling memory. ;-) > > Typing is only a very small part of the development cycle. > > Performance measures indicate that rhe average programmer delivers > > about 2 to 20 lines per code per day (measured over the whole > > development cycles, this of course includes testing, too). > > > > Compare these with the lines of code you *could* write in eight > > hours if you would just write them and you see how much you could > > optimize away there if you'd actually manage to double the > > performance. > > You are referring to an industrial strength development process Basically I'm just talking about being professionell. > taht > is not used by a lot of developers (at least not that I know of > considering Delphi is a RAD tool and is primarily used as such). _Anything_ is used as RAD tool these days. The problem is, it's not so rapid after all. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> P.S.: > BTW: Never heard of anybody doing serious programming in GNU Pascal (and I > know many a programmer doing serious programming in FPC and even VP) As far as I can see (from their maillists), most serious GPC users are academics working with large numeric-related legacy ISO codebases. VP had some serious apps in the BBS time, but nothing serious in the half-decade, except maintenance of those apps. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [fpc-l] type discussion
Forward declarations are redundant - they exist purely for the benefit of the compiler. I agree. I hate prototyping. That's why you use top-down design. What's wrong with that? Begin..End is redundant - you have to indent them to make em readable anyways. Not at all; I certainly don't indent them, and I'm a fanatical indenter. I don't think you're going to convince anyone to change THIS part of Pascal--it's essential. You change begin and end, and you just don't have Pascal anymore. Plus the only reason I love FPC is because it is faithful to older code. If it breaks my code, I'll likely go back to a previous version and I bet there are enough people who feel this way that there will be the beginning of another project based on the older FPC code. manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects. Oh yes, this old argument. I remember reading this on the list before. I guess it's still on your mind ;) I really don't know about the pros and cons for ref counting, so maybe someone can explain it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [fpc-l] type discussion
What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. you are missing the point! Whather you can implement something faster in another language is not the issue. I am arguing for less verbose syntax without decreasing the clarity of the code in delphi/pascal and that is logically gonna improve productivity without taking anything away. This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. I question the correctness of the hypothesis, and I assume, so does Florian... I think the point of this is being lost on me. We're talking about changing things like philosophy (top-down design), and syntax. So are we talking about just creating another new language? I mean that's what it sounds like. Why not take Python or C# and add Pascal syntax or philsophies to it instead of adding these to Pascal? Maybe some people just really don't like Pascal that much. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
> > Well I will typically spend about 25% of my development time with > forward declarations, doing loads of try finaly blocks to free memory > and other things instead of implementing my application. > > jamie. Well, you are quite a machine. If you say so, sure it's so, but that's not the problem. Anyhow there are tools, editors, etc. that can easy that fact if you feel confortable with then. I usually spend under 5% typing my code, I spend a lot longer thinking what I have to type, and I DO spend quite longer debugging and improving my code. And herebye I challenge any C Coder to maintain a program faster and neater than in Pascal (I say C, 'cause your comments about Python and other script language I assume it's a joke). Anyway as Michael would say, a can of worms has been opened and we are not going anywhere. If you want to stick to Python, stick to it, but Pascal is another thing. JMR P.S.: BTW: Never heard of anybody doing serious programming in GNU Pascal (and I know many a programmer doing serious programming in FPC and even VP) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Yes. Too bad it is not possible. One of the problems you can expect is with cyclic units. Normally the interfaces of the units form a tree, which define how they get called. So the compiler can compile the interfaces in the depth first order, then it can do the implementations in any order it wants, cyclic uses in implementations are no longer a problem, as the compiler known how to call the procedures in those units. yes I will need to think about that. Perhaps have two different use clauses... From the good taste department, it breaks the interface/implementation principle. The unit principle guarantees that libraries are being written so that one only needs to look at the interface, not the implementation to know how a library works. It saves a few keystrokes, but makes it a lot harder for the user of the library to understand it. Well thats how c# does it and whilst you have a point its not really a problem in the modern world were introspection or indexing is used by an IDE to get the interface. jamie. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Thu, 2 Jun 2005, schreef Jamie McCracken: > Daniël Mantione wrote: > > > > Op Thu, 2 Jun 2005, schreef Jamie McCracken: > > > > > >>Daniël Mantione wrote: > > > > > > > Ok! We'll be happy to assist anyone doing interresting developments with > > Free Pascal. Keep in mind though that implementing ideas can take "a lot" > > more time that thinking out ideas. > > > > The Free Pascal parser is indeed manual craftmanship. Some experimenting > > was done using yacc in the past but a handwritten parser turned out to be > > the best choice. The parser units start with the letter p, for example > > pexpr.pas is the expression parser. > > You've done it the hard way - no wonder developer's are reluctant to > implement syntax changes! Depends on your definition of "hard way". The parser is fast and flexible. Ask Carl Eric Codere what the exact problems with Yacc were. But it's "been there, done that, didn't work". > > Yes... Because Java often turns out to be the wrong tool and its memory > > management is one of the reasons. We need to be carefull to prevent Pascal > > becoming a wrong tool. However, automated memory management does have some > > advantages. Nobody can deny that. > > Ref counting does not use more memory! (well okay 32 bits extra to store > the ref count for each object). Yes, but it has its own problems. Think of an object having a reference to itself (think of a ringbuffer with 1 object in the ring or so). Welcome in the real world. Perhaps (likely) there is a solution, perhaps (likely) there are more problems. No expert here. > would become under Rad Pascal: > > uses >Classes, SysUtils; > > TMyObject = class (Tobject) > private > count : integer; > public > constructor create; override; > inherited Create(AnOwner); > inc (count); > > destructor destroy; override; > inherited Destroy; > > > Notice its at least 50% less code to write. Yes. Too bad it is not possible. One of the problems you can expect is with cyclic units. Normally the interfaces of the units form a tree, which define how they get called. So the compiler can compile the interfaces in the depth first order, then it can do the implementations in any order it wants, cyclic uses in implementations are no longer a problem, as the compiler known how to call the procedures in those units. From the good taste department, it breaks the interface/implementation principle. The unit principle guarantees that libraries are being written so that one only needs to look at the interface, not the implementation to know how a library works. It saves a few keystrokes, but makes it a lot harder for the user of the library to understand it. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Op Thu, 2 Jun 2005, schreef Jamie McCracken: Daniël Mantione wrote: Ok! We'll be happy to assist anyone doing interresting developments with Free Pascal. Keep in mind though that implementing ideas can take "a lot" more time that thinking out ideas. The Free Pascal parser is indeed manual craftmanship. Some experimenting was done using yacc in the past but a handwritten parser turned out to be the best choice. The parser units start with the letter p, for example pexpr.pas is the expression parser. You've done it the hard way - no wonder developer's are reluctant to implement syntax changes! Yes... Because Java often turns out to be the wrong tool and its memory management is one of the reasons. We need to be carefull to prevent Pascal becoming a wrong tool. However, automated memory management does have some advantages. Nobody can deny that. Ref counting does not use more memory! (well okay 32 bits extra to store the ref count for each object). except were the source is bloated by forward declarations :) Just order your procedures like you should order them, go go!! :) [EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep ';forward;' *.pas browlog.pas:procedure writesymtable(p:Tsymtable);forward; pexpr.pas:function sub_expr(pred_level:Toperator_precedence;accept_equal : boolean):tnode;forward; pstatmnt.pas:function statement : tnode;forward; [EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep '; forward;' *.pas browcol.pas: function GetDefinitionStr(def: tdef): string; forward; scanner.pas:function read_expr : string; forward; [EMAIL PROTECTED]:~/fpc2/fpc/compiler> Wow! 5 forward declarations in the entire compiler source. Yeah, bloat indeed :) its a bit more than that. Forward declarations include the class interfaces too in the type section. EG under delphi : uses Classes, SysUtils; type TMyObject = class (Tobject) private count : integer; public constructor create; override; destructor destroy; override; end; implementation constructor TConfigureBuildLazarusDlg.Create(AnOwner: TComponent); begin inherited Create(AnOwner); inc (count); end; destructor TConfigureBuildLazarusDlg.Destroy; begin inherited Destroy; end; end. would become under Rad Pascal: uses Classes, SysUtils; TMyObject = class (Tobject) private count : integer; public constructor create; override; inherited Create(AnOwner); inc (count); destructor destroy; override; inherited Destroy; Notice its at least 50% less code to write. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Thu, 2 Jun 2005, schreef Jamie McCracken: > Daniël Mantione wrote: > > > > > Granting all those wishes would turn the language in an enourmous > > monster. That doesn't look like a good idea. We've also a limit amount of > > developers whos time needs to be spent well, or we'll get behind. > > > > So, we're very convervative. Good ideas though, that will really benefit > > people, will be read with great interrest. > > > > > okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as > FPC supports multiple dialects it can slip in without affecting existing > code so if people dont like it they dont have to use it. Im quite happy > to write it myself but I will need help on where to look and what to > modify in the compiler as im not familliar with the compiler source (I > cant even find the grammar for the language so I take it you dont use a > table driven or auto generated parser like yacc) Ok! We'll be happy to assist anyone doing interresting developments with Free Pascal. Keep in mind though that implementing ideas can take "a lot" more time that thinking out ideas. The Free Pascal parser is indeed manual craftmanship. Some experimenting was done using yacc in the past but a handwritten parser turned out to be the best choice. The parser units start with the letter p, for example pexpr.pas is the expression parser. As for forward declarations, forget it for the short term, adding a pass is way too complicated for a beginner. Lastly, a good language tries to maximize power while limiting language constructions. Keep that in mind. > > Users like software written in Pascal. They dislike software requiring > > JDK's and .NET runtimes. > > > > So, lets turn the disadvantage in an advantage. Pascal is no replacement > > for Java and C#. It is a replacement for C and C++. > > It is a replacement for java and c# for *desktop* apps. I have rewritten > several java apps into delphi in my previous jobs. Yes... Because Java often turns out to be the wrong tool and its memory management is one of the reasons. We need to be carefull to prevent Pascal becoming a wrong tool. However, automated memory management does have some advantages. Nobody can deny that. > > Now, the majority of software is written in C and C++. Isn't that a great > > potential "market"? > > > > > >>All in all the changes would mean you spend more of your time > >>implementing your application rather than typing loads of redundant > >>code. Maintenance is easier as their is less redundancy. > > > > > > As has already been said, typing is not the problem, maintenance is. > > Pascal does a good job here, saving people a lot of time. > > except were the source is bloated by forward declarations :) Just order your procedures like you should order them, go go!! :) [EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep ';forward;' *.pas browlog.pas:procedure writesymtable(p:Tsymtable);forward; pexpr.pas:function sub_expr(pred_level:Toperator_precedence;accept_equal : boolean):tnode;forward; pstatmnt.pas:function statement : tnode;forward; [EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep '; forward;' *.pas browcol.pas: function GetDefinitionStr(def: tdef): string; forward; scanner.pas:function read_expr : string; forward; [EMAIL PROTECTED]:~/fpc2/fpc/compiler> Wow! 5 forward declarations in the entire compiler source. Yeah, bloat indeed :) > None of my proposed changes should be detrimental to pascal's > maintainability or clarity as I too value that feature. If you want to expiriment, go ahead and we'll be helpfull. That'll be more productive than this discussion. However, your time is propably as valuable as ours, try to make features that'll really help people. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Granting all those wishes would turn the language in an enourmous monster. That doesn't look like a good idea. We've also a limit amount of developers whos time needs to be spent well, or we'll get behind. So, we're very convervative. Good ideas though, that will really benefit people, will be read with great interrest. okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as FPC supports multiple dialects it can slip in without affecting existing code so if people dont like it they dont have to use it. Im quite happy to write it myself but I will need help on where to look and what to modify in the compiler as im not familliar with the compiler source (I cant even find the grammar for the language so I take it you dont use a table driven or auto generated parser like yacc) Forward declarations are redundant - they exist purely for the benefit of the compiler. Here I disagree. I like that I only need to look upward to search a procedure. Even when I program C I order the procedures like I to in Pascal, since it'll save time in the long term. I understand that but its enforced for the convienience of the compiler. A developer should have a choice for how he arranges things especially if hes in a hurry to develop something quick. Such constraints reduce the RAD factor. Begin..End is redundant - you have to indent them to make em readable anyways. Here I agree, however, Pascal was designed this way. If I would design the language I would have likely chosen something shorter. On the other hand, I only need to type alt+B and I have a begin/end combo. Even without it, the begin/end doesn't irritate me. manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects. I agree that automatic memory management eases the programming job. However, Pascal is a manual memory management language. That has advantages, software written in Pascal is fast, perceived fast by people, and uses very little memory. same is true for Delphi but it uses ref counting and parent/child owner for managing memory for most things. However they forgot to do something about tobjects - its just inconsistent to manage some things and not others. With C++ exception handling the try..finally construct has negligible overhead so simple ref counting is fast. In the majority use case where objects are kept local the overhead will be negligible too. I really doubt you will see any significant performance hit this way and memory use is of course hardly affected at all by ref counting (unlike GCs). I do hope the FPC developers will look at this once we have C++ exceptions and see just exactly what is the overhead and if its worth ref counting some more stuff. Users like software written in Pascal. They dislike software requiring JDK's and .NET runtimes. So, lets turn the disadvantage in an advantage. Pascal is no replacement for Java and C#. It is a replacement for C and C++. It is a replacement for java and c# for *desktop* apps. I have rewritten several java apps into delphi in my previous jobs. Now, the majority of software is written in C and C++. Isn't that a great potential "market"? All in all the changes would mean you spend more of your time implementing your application rather than typing loads of redundant code. Maintenance is easier as their is less redundancy. As has already been said, typing is not the problem, maintenance is. Pascal does a good job here, saving people a lot of time. except were the source is bloated by forward declarations :) None of my proposed changes should be detrimental to pascal's maintainability or clarity as I too value that feature. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Thu, 2 Jun 2005, schreef Jamie McCracken: > So am I. My point is not changing the language so that it incurs > additional maintenance or is harder to read or harder to fix bugs or > make bugs more likely. In fact its the complete opposite. > > My point is to to reduce or remove *redundant* syntax that serves no > useful or productive purpose (to the programmer). No, adding syntactic sugar usually does more harm than it is an enrichment. It promotes people to write code that only works on 1 compiler and increases the learning curve for people trying to learn the language. Syntactic sugar can be added *if* it really does have an advantage. However, changing the way constructors are done saves only a few keystrokes, but keeps people away from understanding class references, which, if understood well, can be a very powerfull tool (virtual constructors, calling class methods of class references etc.) So, I very much doubt if this proposal will help. Don't take us wrong, we are very much in favour of modernizing the language. However, we are getting *lots* of proposals like this, only *for* *no* *other* *reason* than to save a few keystrokes. Granting all those wishes would turn the language in an enourmous monster. That doesn't look like a good idea. We've also a limit amount of developers whos time needs to be spent well, or we'll get behind. So, we're very convervative. Good ideas though, that will really benefit people, will be read with great interrest. > Forward declarations are redundant - they exist purely for the benefit > of the compiler. Here I disagree. I like that I only need to look upward to search a procedure. Even when I program C I order the procedures like I to in Pascal, since it'll save time in the long term. > Begin..End is redundant - you have to indent them to make em readable > anyways. Here I agree, however, Pascal was designed this way. If I would design the language I would have likely chosen something shorter. On the other hand, I only need to type alt+B and I have a begin/end combo. Even without it, the begin/end doesn't irritate me. > > manual memory management of tobjects is redundant as you can get good > performance with ref counting tobjects. I agree that automatic memory management eases the programming job. However, Pascal is a manual memory management language. That has advantages, software written in Pascal is fast, perceived fast by people, and uses very little memory. Users like software written in Pascal. They dislike software requiring JDK's and .NET runtimes. So, lets turn the disadvantage in an advantage. Pascal is no replacement for Java and C#. It is a replacement for C and C++. Now, the majority of software is written in C and C++. Isn't that a great potential "market"? > All in all the changes would mean you spend more of your time > implementing your application rather than typing loads of redundant > code. Maintenance is easier as their is less redundancy. As has already been said, typing is not the problem, maintenance is. Pascal does a good job here, saving people a lot of time. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
-- Class Contracts I like the 'require/ensure' aproach. It makes the code more robust and more debuggable, IMHO I think the checks you can do there are to limited. I also wonder what will happen if a require isn't met. Personally I don't want exeption in my released app. No, these are assertions not as exceptions. -- Generics I am not sure if Generics could be done in FPC. There were some discussions about it here and AFAIK some are trying to implement. Any links? -- Virtual Properties and Events The examples given there are not very different of what is possible now. Make SetWith virtual and you have almost the same. What however would be nice is if you could override the getter or setter. Something like property Width write MySetWidth I think you missed a few things here. type TMyClass = class ... property Width: integer read write; virtual; abstract; end; As you can see, getters and setters are not in the picture at all. Which means, you have all the freedom you want in the derived class. Plus, I like the idea that I could have a base class with read-only property that can not be overriden to be read-write later. property Width: integer read; virtual; abstract; OK, while I like the idea, I can not think of how I would use it though :-) Can someone help me out here -- Enhanced Multicast Events This is not really new. You can implement it yourself like property OnChange: TNotifyList; and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc) OK. Nice to be able to do that. Do I have to write my TNotifyList every time I need it? Inline variable initializers, such as: [snip] var Integer1: Integer = 15; Boolean1: Boolean = False; String1: String = 'SOME TEXT'; Hmm.. sometimes usefull. You can put it as first lines > in your constructor/codeblock, but keep it thogheter in > say large classes can be handy. Yes, and it improved the readability, IMHO. Plus, there is no reason for you to alter that in constructor/codeblock too. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
|
| > Begin..End is redundant - you have to indent them to make em readable
| > anyways.
|
| No. This makes the code more readable like normal english text. It
| states much more clearly what it intents, at least much more than just
| indenting or putting curly braces around it.
And when you have a high resolution monitor, or you are reading the code in
small
print, that { could be a (.
It's not always clear.
On very short code blocks in PHP, I found myself always going
{
code
}
Anyways! for clairty. So the whole so called "advantage" of going {code} was
defeated.
Because I figured it could have been (code) too, on a blurry day when I just
woke up.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| Begin..End is redundant - you have to indent them to make em readable
| anyways.
Typing "type" is reduntand to, so is "integer"
You could use "i" instead of integer, you could use "T" instead of type. Draw
the
line. Draw the line. I feel you do not like any part of the Pascal language, so
I
wonder as to your intention or goal here. It seems python or C# is the perfect
fit for
what you are describing.
By the way, remember that you will always convert "{" to "beginning of the code
block".
At least you don't have to type out "beginning of the code block" but rather
"begin".
Draw the line.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > > For me I prefere clarity above less typing (besides if you want to write > > realy short code, you sould use APL) > > > > I totally agree with you in this case - we dont want or need cryptic c > stlye syntax in any version of Pascal. ACK. > However, in general Pascal has poor developer productivity when compared > to modern languages like python and C#. Ironically python is perhaps the > most popular language on Linux and most of its syntax is derived from > object pascal whereas pascal on linux is virtually non-existant. Of > course Python is piss poor in both performance and memory usage but it > does point the way to a revitalised pascal. Adopting less verbose but > still clean and clear syntax ala python is IMHO the way to make Pascal > great again. IMO Python is preferred for its portability. Consider the efforts required to distribute a C project, with autobloat, configure and all that crap. Python in contrast is the modern BASIC, that made programming easy, at the cost of execution speed. And, like BASIC, Python IMO is not such a general (unlimited) programming language as are C or Pascals. > Consider the developer unfirendly nature of pascal/Delphi atm: > > 1) Forward declarations - they sux! Why should the developers have the > burden of making the code totally sequential declaration wise. All other > modern compilers dont need this. Sure your code might take a bit longer > to compile but thats peanuts compare to the time saved in extra typing > and reordering your code I agree that forward declarations and circular unit references suck. If it's only compilation time, according improvements are welcome. But I suspect that the introdution into the compiler would exceed the current manpower :-( > 3) loads of small and pointless additional syntax like EG for creating > an object you should just be able to say: > > myobject.create; > > and not > > myobject := Tobject.create; That conflicts with e.g. someproc(someclass.create); It also is useless with polymorphism, where the type of the variable can differ from the type of the created object. > also Begin..End blocks should IMO be replaced with python's indenting. No, please :-( A single run through an inappropriate editor could irrecoverably damage the indentation! I for my part would prefer a cleaner syntax, closer to Modula or Oberon, with statement_list vs. statement_sequence. The "end"s etc. can be inserted by an appropriate editor, if somebody wants less typing... > Yeah I know this sounds like a hybrid pascal/python but I believe thats > the way to go - marry Delphi's speed and component framework with less > verbose python style syntax and you will have the best RAD language ever > written. I like RAD, but only when paired with the reliability and (type...) safety of Pascal. RAD never should mean: type fast, debug forever - or - press run and cross your fingers :-( Or, as Vinzent pointed out: >> However, in general Pascal has poor developer productivity when >> compared to modern languages like python and C#. > In terms of _written_ or in terms of _working_ lines of code? :-> The careful design of a programming language is not a simple task. What looks nice to the user, may look very different to the compiler writer. It also should be noted that the amount of *helpful* compiler error messages heavily depends on the language design. Unfortunately there exist multiple Pascal compilers, each with different extensions to the original language, reducing the portability of source code. With regards to Python you only can hope that there will never come a second Python system, and that the development of the language and libraries will be continued, once the current implementors leave the project. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
listmember wrote: > Inline variable initializers, such as: ... > function Something(...): Boolean = False; > var >Integer1: Integer = 15; >Boolean1: Boolean = False; >String1: String = 'SOME TEXT'; > begin > end; Such constructs are subject to frequent misinterpretation :-( I assume that you want to have C semantics, where the variables are initialized at every invocation of the subroutine. Other people think that the variables are "static", retaining their values across calls (like writeable constants). In general I prefer an implementation of features that exist in other Pascal compilers, over an implementation of new and incompatible features, whose impact on the overall language (stability, type safety...) are unpredictable. Sometimes I dream of an compiler for both Pascal and C syntax, with simple switching between both languages. But I would not dare to suggest how those C parts should work, i.e. what features and bugs of which C compiler should be implemented, and how the C code should fit together with the Pascal code, with regards to type and operation safety. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| >
| >>
| >> I'am a poor delphi programmer, didn't use it for years, but I bet with
| >> any
| >> python programmer that I create any application faster than him :)
| >
| >
| > You must be a damn fast typer then :)
Sometimes it's which keys are near the home key. I don't care if "{" is shorter
than
begin, because "{" requires the shift key and finger strain. Plus, I always
convert
"{" into "begin of code block" in my mind anyway.
I rarely find that fast typing helps my coding. It sure helps when writing
emails.. or
when doing bulk operations on big amounts of code. But when creating code,
usually you
have to stop and think.. and fast typing is useless. It helps when you are
typing
comments for the code. Pressing things like "End" and the arrow keys takes my
hand off
the home keys, and this cramps up my coding thought. But it's never the typing
speed
that helps my productivity when writing code. Just comments and bulk operations
on
code that was already written, that is now being changed.
What I find that takes more time then the typing, is running to the manual
trying to
figure out what this cryptic thing does, or what parameter goes where. For
example, if
you set(red,edit) how do you know it isn't set(edit,red)? So in php when I was
using a
text editor.. I didn't have code completion and I always had to look things up.
Or,
even with code completion, you still have to look up more detailed descriptions
of
what the parameters are. But it's not the typing that costs me time.
What also takes more time than the typing of code is writing comments for the
code.
Any language requires comments for the code, so there would be no advantage for
any
language there. Comments are comments.
Lars
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
L505 wrote: | Yeah I know this sounds like a hybrid Pascal/python but I believe thats | the way to go - marry Delphi's speed and component framework with less | verbose python style syntax and you will have the best RAD language ever | written. | You are asking to reinvent python. If I were you, I'd just look into finding a python compiler. Everything you say points to the fact that you like the way python is laid out. That's fine, there's nothing wrong with different taste. No not at all. I dont want python but I would like to borrow some of its more concise syntax to make delphi less verbose thats all. Python is way too flawed with its grossly inefficient dynamic typing to ever be good for building general purpose applications. I'll see if I can create a modern dialect and integrate it into FPC... Any documents/info on how the compiler is laid out would be most appreciated. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| However, in general Pascal has poor developer productivity when compared | to modern languages like python and C#. Ironically python is perhaps the I disagree strongly, this is one of the reasons I chose Pascal. The fact that it creates compiled programs in a productive language versus python and C# who are not generally compiled right there and then, was another reason. | most popular language on Linux and most of its syntax is derived from | object Pascal whereas Pascal on linux is virtually non-existant. Of | course Python is piss poor in both performance and memory usage but it Yes, it is. All the linux programs I tried on KDE are extremely slow compared to Windows 2000. A lot of linux apps are made relying on python or perl. i.e. kpackage relies on python, and the KDE CPU monitor program. It's so slow, I found. There was also a "visual php" program of some sort made in python which was about a 450MB download and wouldn't even load up on my pc in ample time. I deleted it before loading it. | does point the way to a revitalised Pascal. Adopting less verbose but | still clean and clear syntax ala python is IMHO the way to make Pascal | great again. You just can't have it both. Perl is shortform. But it's not easy to create a regex for the long term, for other programmers to read.. or even yourself. No matter how clear the regex seems to be for a split second when you first create it initially. | | Consider the developer unfirendly nature of Pascal/Delphi atm: | | 1) Forward declarations - they sux! Why should the developers have the | burden of making the code totally sequential declaration wise. All other | modern compilers dont need this. Sure your code might take a bit longer | to compile but thats peanuts compare to the time saved in extra typing | and reordering your code They don't suck, you just need a proper editor which let's you see your declarations without taking you away from your code editing. A proper IDE should have this. Virtual views of the text file, showing declarations in a little side window or side panel editor, which you can edit at any time. Not just dual view or dual opening of the file, an actual dedicated portion for declarations open at all times in some virtual window. So the editor needs to be improved, IMO. Also, how in the world are you going to find all your declarations scattered across the file? incremental search? or are you going to make notes at the top of the file about where things are? Index it? bookmark them? | | 2) I have touched on manual memory managaement of tobjects before so I | wont rehash it here (in summary ref count tobjects and they should have | good performance with c++ style exception handling). | I don't mind freeing a stringlist, something bigger and something I should feel responsible about. But I do mind freeing a string or an array. So I have no problems. I won't ask you if you've seen a fast and productive language used today with GC. | 3) loads of small and pointless additional syntax like EG for creating | an object you should just be able to say: | | myobject.create; | | and not | | myobject := Tobject.create; This is not a big deal. I found as a beginners it was a big deal. I find its' more clear this way.. You're creating a Tobject after all, not a object. | | also Begin..End blocks should IMO be replaced with python's indenting. You need to use python and forget about Pascal. What you are asking for here is Python! It's obvious. | | Yeah I know this sounds like a hybrid Pascal/python but I believe thats | the way to go - marry Delphi's speed and component framework with less | verbose python style syntax and you will have the best RAD language ever | written. | You are asking to reinvent python. If I were you, I'd just look into finding a python compiler. Everything you say points to the fact that you like the way python is laid out. That's fine, there's nothing wrong with different taste. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> Michael Van Canneyt wrote: > > > > > This is not so easy, and reference counting is always a mess... > > Well you already have the code for ref counting for com objects so its > not like its a ton of work and therefore we dont need to worry about > your four points. Adding C++ style exception handling should make it > fast enough too (ok that is some work). No it won't. The ref counting is expensive. Test e.g. speeds with Decal vs an own implementation on Delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> Michael Van Canneyt wrote: > > This is only 'logical' if the hypothesis > > > > "productivity is inversely related to the syntax verbosity" > > > > is correct. > > And it's not. > > What is correct is "productivity is directly related to the number of > separate language constructs developer has to put in program to acomplish > the task" True. But the problem is that the "task" is not a constant. _If_ you really try to exploit this feature, and increase your programming speed (by not having to track object age and owner), you will have to deal with irregularties in deallocation (GC storms), null pointer exceptions etc. > Or lack of standard libary supplied container > apropriate for a task requires programmer to develop his/her own or to adapt > something less usable. Partially true yes. However the only reasonable solution for that is generics I think. > So here is some little idea which seems to me Pascalish enough to be > considered: > > how about new keyword: local > Class variable declared local will be automatically freed upon every exit > from the scope (i.e. something along the lines of implicit try/finally for > some builtin types). No. Inconsequent. I think you are totally on the wrong track if you want to try to solve this with language. There are only two solutions : 1) go fully automated 2) have only the minimum on base automated types (e.g. strings, I don't count variants, since they are for a specific purpose) Any patchy solutions will only go against this. Most allocations aren't limited to a simple scope anyway. Since not everything is an object, there is a lot less object creation going on. Even dynamic arrays were somewhat doubtfull, but finally mostly added because of Delphi compat. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> > > Begin..End is redundant - you have to indent them to make em readable > > anyways. > > No. This makes the code more readable like normal english text. It > states much more clearly what it intents, at least much more than just > indenting or putting curly braces around it. Not every syntax is about minimizing code or readability. Some are also to simply simplify parsing (and that is about compiler developer, but to make the language more internally consistent) and avoid long lookaheads. These things combined also improve quality of error messages a lot. > > manual memory management of tobjects is redundant as you can get good > > performance with ref counting tobjects. For trivial programs: yes. However FPC is not designed for short scripting programs. > > Maintenance is easier as their is less redundancy. > > It simply depends on the kind of redundancy. > > For instance, "type" and "var" keywords are just redundant, the compiler > could figure it out by itself, still they serve a useful purpose. See above. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marco van de Voort wrote: Also, I simply don't see the use of it. Borland Pascal's have the forward directive for those really few cases where it is annoying. Also, forward declarations mostly mean shitty code / design. Atleast in my case it does. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> On Thursday 02 June 2005 13:38, Jamie McCracken wrote: > > Florian Klaempfl wrote: > > > I'am a poor delphi programmer, didn't use it for years, but I bet > > > with any python programmer that I create any application faster > > > than him :) > > > > You must be a damn fast typer then :) > > No, that's a common misunderstanding (especially amongst C-programmers). > > What matters is designing und understanding the code, not writing it. I > spend less than 10% of my time at work in actually _writing_ code, so > even if someone can type in his/her code twice as fast, the maximum > (s)he would gain would be five percent in overall performance. I doubt you would get that high. A educated typist can get over >120 keys/min (and that is already lowered because of many shifts, with real text it). I don't think the avg line of code is longer than 20 chars. That is 360 lines/hr. SLOC, not code with whitespace, and not counting generated code with codetools. Most of the time of entry is spent in navigating and searching, not code adding. And then data entry is only a small part overall. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> >> fpc-devel maillist - fpc-devel@lists.freepascal.org > >> http://lists.freepascal.org/mailman/listinfo/fpc-devel > >> > > MyObject.Create is impossible with classes on the heap. You need to > > assign MyObject a pointer but you can't do that from within create. > > sorry myobject is the pointer so a better example would be : > > var strlist : Tstringlist; > strlist.create; > > This should be easy as you know the pointer type. Syntactic sugar. Read the faq ;) > > > > Forward declarations are IMHO required because otherwise the compiler > > would have to make additional passes(it does 3 AFAIK). > > They are not required in a multipass compiler. They can be. A multipass compiler doesn't necessarily spend multiple passes in the parser. > If you cant resolve a > symbol on a single pass you can do so on a subsequent one. This limits the amount of stuff you can do in the subsequent pass, since nothing is required to be resolved yet. And passes are expensive, compiletime wise. Also, I simply don't see the use of it. Borland Pascal's have the forward directive for those really few cases where it is annoying. > > Besides, they are seldom enough to be a problem. > > Pain in the arse they are. Its annoying and makes use of the code > explorer a neccsity when dealing with large classes. Its a total waste > of my time. Then improve the code explorer. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> > I totally agree with you in this case - we dont want or need cryptic c > > stlye syntax in any version of Pascal. > > > > However, in general Pascal has poor developer productivity when compared > > to modern languages like python and C#. > > I'am a poor delphi programmer, didn't use it for years, but I bet with any > python programmer that I create any application faster than him :) The opinion that Python is so fast is mainly based on tinkerers. So it is simply true. Trial and error programming is for small programs always faster, and Pascal doesn't help with that. However IMHO is that a problem of Python/C#, not Pascal. Or actually it is a big problem for IT managers ;-) And then people wonder why the avg IT project doesn't make the deadline. > > object pascal whereas pascal > > Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice, > Mozilla etc. use ;), definitively not python ... Python is a usuable scripting > language but nothing more. If I see what python is used for on my system than that is application scripting and distribution-related tools (pkg management etc). Not one really usable app. Python is not a brick in the wall of development, but more like hole filler. > > on linux is virtually non-existant. > > The problem with pascal on linux was/is that there was no good compiler in > the 90s for linux so a lot developers got lost. The educational stigma also hurt pretty bad, even though untrue. This was indeed not helped by the relative late arrival of 32-bit Borland compilers. > > 2) I have touched on manual memory managaement of tobjects before so I > > wont rehash it here (in summary ref count tobjects and they should have > > good performance with c++ style exception handling). This is impossible:-) > Good performance like python ;)? That is doable :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice, > Mozilla etc. use ;), definitively not python ... Python is a usuable scripting > language but nothing more. Well.. you should think so. But parts of Gnome are written in Python. And a lot of the configuration-tools of Fedora are python-based. I thought about it to rewrite some of them in fpc. That would make them a lot faster, and less memory-intensive. But first you need fpc in Fedora-Core offcourse... Joost. signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> Marco van de Voort wrote:
> > Some of these target functionality (specially in the linking section) might
> > require restructures
> > related to
> > * introduction of an internal linker for some core platforms (no more
> > LD)
> > * Rewrite of module (unit) handling
>
> Yes, these would be great, IMHO.
> > For the rest, improve RTL/FCL compability and extend them in general, and
> > of course fixbugs.
> >
> >>Beside of compatibility towards Delphi or MacPascal or others FPC should be
> >>open to other modifications/extensions (maybe Delphi one day copies FC a bt
> >>:-), and not always the other way round)
>
> Maybe a few things should be borrowed from RemObjects Chrome, such as
>
> -- Class Contracts
> http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30D8}
> I like the 'require/ensure' aproach.
Glorified asserts. This is inventing syntax for marketing reasons.
> It makes the code more robust and more debuggable, IMHO
Nope. It just is a limited form of assert with special syntax. Definitely
does not mark the trival syntax test.
> -- Generics
> http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}
> I am not sure if Generics could be done in FPC.
Probably yes, however it will not be easy. IMHO Generics/templates are
definitely on the list, but don't expect it anywhere soon, unless there is
massive help.
> -- Virtual Properties and Events
> http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE99}
Understandable. However lots of performance issues. One could mitigate some
of these by e.g. requiring virtual properties to only use static methods and
adding optimizations.
RemObject/.NET probably either don't care about speed, and/or have some
global optimalisations that makes adding this kind of stuff not to hurtful.
Probably a bit of both.
IMHO not a definite no, it would be either unoptimal, or a lot of work.
> -- Enhanced Multicast Events
> http://www.remobjects.com/page.asp?id={CC9C4828-9E49-4C41-AFD9-0BFFA4E9C3D3}
> Inline variable initializers, such as:
>
> type
>TSomethingElse = class(TSomething)
>private
> FInteger: Integer = 15;
> FBoolean: Boolean = False;
> FString: String = 'SOME TEXT';
> {etc}
>protected
>public
>published
>end;
Can be done otherwise (simply init it). -> Syntactic sugar.
> Similarly, for
>
> function Something(...): Boolean = False;
> var
>Integer1: Integer = 15;
>Boolean1: Boolean = False;
>String1: String = 'SOME TEXT';
> begin
> end;
Useless IMHO. Equal to above (initialising in syntax what can be inited
normally)
> Procedure Something(Out AInteger: Integer = 12; );
> var
>Integer1: Integer = 15;
>Boolean1: Boolean = False;
>String1: String = 'SOME TEXT';
> begin
> end;
Same. Don't even add to productivy
> >>a way to write integer constants in any base, not only
> >>binary/octal/hexadecimal (not so important, but easy to implement)
> >
> > Rarely used. Specially since more than base 36 becomes a notational
> > problem. However it has been brought up before.
>
> If someone contributes the code, why not.
> It does not hurt, IMHO.
Because the more features, the more involved maintainance of the compiler
becomes. So keep that work for features that are worth it.
I don't like this one, but it might already exist (in mac mode), since ISO
Paslla has this.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: But the compiler needs to check many things: 1. Initialize the S with Nil. 2. Check that S is assigned only once during the lifetime of the procedure. This is actually a bigger restriction than you might think, unless you want to introduce reference counting. 3. Put a try/finally block and generate a call to S.Destroy at the end. It must also catch any errors that may occur when s.destroy is called. For classes, this danger is very real; For ansistrings it is not (well, very small) 4. It cannot assign S to anything, since that could mean that the lifetime of S could be prolonged. The alternative is again again ref. counting. This is not so easy, and reference counting is always a mess... Well you already have the code for ref counting for com objects so its not like its a ton of work and therefore we dont need to worry about your four points. Adding C++ style exception handling should make it fast enough too (ok that is some work). jamie. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 15:13, Sebastian Kaliszewski wrote: > So here is some little idea which seems to me Pascalish enough to be > considered: > > how about new keyword: local > Class variable declared local will be automatically freed upon every > exit from the scope (i.e. something along the lines of implicit > try/finally for some builtin types). Oh. You mean a thing I know as "controlled type". Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thu, 2 Jun 2005, Sebastian Kaliszewski wrote: Michael Van Canneyt wrote: This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. And it's not. What is correct is "productivity is directly related to the number of separate language constructs developer has to put in program to acomplish the task" Inversely related, I assume you want to say :-) So, for example, need to put separate finally block to free memory means additional few constructs. Or lack of standard libary supplied container apropriate for a task requires programmer to develop his/her own or to adapt something less usable. Geeintg rid of end in begin / end wont help much (as they can;t be separated, they count as single construct). So here is some little idea which seems to me Pascalish enough to be considered: how about new keyword: local Class variable declared local will be automatically freed upon every exit from the scope (i.e. something along the lines of implicit try/finally for some builtin types). While I can see the use, there are all kinds of problems associated with it. So instead of Var S : TStringList; ManagedVar // or whatever. All that goes here is freed again by the compiler. S : TStringList; begin S:=TStringList.Create; // code here end; // Compiler frees S here. But the compiler needs to check many things: 1. Initialize the S with Nil. 2. Check that S is assigned only once during the lifetime of the procedure. This is actually a bigger restriction than you might think, unless you want to introduce reference counting. 3. Put a try/finally block and generate a call to S.Destroy at the end. It must also catch any errors that may occur when s.destroy is called. For classes, this danger is very real; For ansistrings it is not (well, very small) 4. It cannot assign S to anything, since that could mean that the lifetime of S could be prolonged. The alternative is again again ref. counting. This is not so easy, and reference counting is always a mess... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Vinzent Hoefler wrote: > manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects. That can be a point, yes. But it is somehow not related to any syntax. It means not having to bother with my pet hate the try..finally..free All in all the changes would mean you spend more of your time implementing your application rather than typing loads of redundant code. Typing is only a very small part of the development cycle. Performance measures indicate that rhe average programmer delivers about 2 to 20 lines per code per day (measured over the whole development cycles, this of course includes testing, too). Compare these with the lines of code you *could* write in eight hours if you would just write them and you see how much you could optimize away there if you'd actually manage to double the performance. You are referring to an industrial strength development process taht is not used by a lot of developers (at least not that I know of considering Delphi is a RAD tool and is primarily used as such). Maintenance is easier as their is less redundancy. It simply depends on the kind of redundancy. For instance, "type" and "var" keywords are just redundant, the compiler could figure it out by itself, still they serve a useful purpose. but that harms legibility. I wanna balance that trims the fat but not the legibility. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. And it's not. What is correct is "productivity is directly related to the number of separate language constructs developer has to put in program to acomplish the task" So, for example, need to put separate finally block to free memory means additional few constructs. Or lack of standard libary supplied container apropriate for a task requires programmer to develop his/her own or to adapt something less usable. Geeintg rid of end in begin / end wont help much (as they can;t be separated, they count as single construct). So here is some little idea which seems to me Pascalish enough to be considered: how about new keyword: local Class variable declared local will be automatically freed upon every exit from the scope (i.e. something along the lines of implicit try/finally for some builtin types). And there are possibly few variants of the thing: 1a. var mySth: local TSomething; begin mySth := TSomething.create(); ... end; 1b. var mySth: TSomething local; begin mySth := TSomething.create(); ... end; 2. local mySth: TSomethin; begin mySth := TSomething.create(); ... end; So in 1. local is just a type modifier (in case of 1a it might make sense to allow it also in type declaration, hence allowing allways local classes -- but I'm not convinced it's desirable, and it definiately requires more work on compiler side). 1b. is like some other storage modifiers like absolute (and might be prefered). 2. is substituting local instead of var for local objects -- so such local object declarations stand out more int the code, but it's also further away from standard Pascal. Is it worth something? rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 14:44, Jamie McCracken wrote: > My point is to to reduce or remove *redundant* syntax that serves no > useful or productive purpose (to the programmer). Well applied redundancy is a good thing. > Forward declarations are redundant - they exist purely for the > benefit of the compiler. IBTD. > Begin..End is redundant - you have to indent them to make em readable > anyways. No. This makes the code more readable like normal english text. It states much more clearly what it intents, at least much more than just indenting or putting curly braces around it. > manual memory management of tobjects is redundant as you can get good > performance with ref counting tobjects. That can be a point, yes. But it is somehow not related to any syntax. > All in all the changes would mean you spend more of your time > implementing your application rather than typing loads of redundant > code. Typing is only a very small part of the development cycle. Performance measures indicate that rhe average programmer delivers about 2 to 20 lines per code per day (measured over the whole development cycles, this of course includes testing, too). Compare these with the lines of code you *could* write in eight hours if you would just write them and you see how much you could optimize away there if you'd actually manage to double the performance. > Maintenance is easier as their is less redundancy. It simply depends on the kind of redundancy. For instance, "type" and "var" keywords are just redundant, the compiler could figure it out by itself, still they serve a useful purpose. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 14:01, Jamie McCracken wrote: Vinzent Hoefler wrote: What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. you are missing the point! No, I don't. I'm damn sure what I am talking about. So am I. My point is not changing the language so that it incurs additional maintenance or is harder to read or harder to fix bugs or make bugs more likely. In fact its the complete opposite. My point is to to reduce or remove *redundant* syntax that serves no useful or productive purpose (to the programmer). Forward declarations are redundant - they exist purely for the benefit of the compiler. Begin..End is redundant - you have to indent them to make em readable anyways. manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects. All in all the changes would mean you spend more of your time implementing your application rather than typing loads of redundant code. Maintenance is easier as their is less redundancy. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 14:24, Jamie McCracken wrote: > Well I will typically spend about 25% of my development time with > forward declarations, doing loads of try finaly blocks to free memory > and other things instead of implementing my application. I typically spend 80% of my development time in *thinking* about what I should do, 10% in writing the code, 5% in showing that it works and 5% in drinking coffee to enhance the productivity of the first 80%. Well, of course, this is a slight exaggeration. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 14:01, Jamie McCracken wrote: > Vinzent Hoefler wrote: > > > What matters is designing und understanding the code, not writing > > it. I spend less than 10% of my time at work in actually _writing_ > > code, so even if someone can type in his/her code twice as fast, > > the maximum (s)he would gain would be five percent in overall > > performance. > > you are missing the point! No, I don't. I'm damn sure what I am talking about. > Whather you can implement something faster in another language is not > the issue. Right. The issue is if you can make it work, i.e. how long you have to test and debug it and how long someone needs to understand it when he comes to that code later (that's called maintenance, I think). > I am arguing for less verbose syntax without decreasing > the clarity of the code in delphi/pascal Which is an almost impossible task. Sure you can tweak it here and there, but it would _at best_ simplify the task of writing the code in the first place. You are just missing the remaining 98% of the development cycle of a typical medium to large software project. You won't gain anything there, even if and /only if/ you could manage to simplify some syntax without having *any* impact on understanding the code later. (BTW, Ada is even more verbose than Pascal and for the things I'm doing it is still /more/ productive. I'm talking about error rates and such stuff, not how much time spending in front of the monitor typing something that *may* work, if you just debug it long enough). > and that is logically gonna > improve productivity without taking anything away. It would, if you could actually manage to accomplish that task. But as I tried to point out, those 5% don't matter. You can lose *much* more and much easily on a bad design. 90% of software development costs is testing. And then it is much better to actually be able to _read_ and _understand_ the code instead of writing it. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: I don't consider Ojbect Pascal to be verbose at all, so it's not an issue for me... Well I will typically spend about 25% of my development time with forward declarations, doing loads of try finaly blocks to free memory and other things instead of implementing my application. jamie. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thu, 2 Jun 2005, Jamie McCracken wrote: Vinzent Hoefler wrote: On Thursday 02 June 2005 13:38, Jamie McCracken wrote: Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) No, that's a common misunderstanding (especially amongst C-programmers). What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. you are missing the point! Whather you can implement something faster in another language is not the issue. I am arguing for less verbose syntax without decreasing the clarity of the code in delphi/pascal and that is logically gonna improve productivity without taking anything away. This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. I question the correctness of the hypothesis, and I assume, so does Florian... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thu, 2 Jun 2005, Jamie McCracken wrote: Michael Van Canneyt wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually non-existant. Of course Python is piss poor in both performance and memory usage but it does point the way to a revitalised pascal. Adopting less verbose but still clean and clear syntax ala python is IMHO the way to make Pascal great again. I beg to differ. Recently I rewrote a python program (on linux). The pascal version was shorter and much clearer to understand. The python syntax is a horror as far as I'm concerned. Im not saying make pascal behave like python so if you were doing some weird dynamic stuff with python thats fair enough. The python program wasn't mine. There were errors in it; it was easier to rewrite it in pascal than to try and fix it. ALl im sayting is theres no harm in replacing some of the verbose syntax with less verbose ones provided they dont harm the clarity of the code. I love delphi but find its verbosity a pain in some circumstances. I don't consider Ojbect Pascal to be verbose at all, so it's not an issue for me... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 13:38, Jamie McCracken wrote: Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) No, that's a common misunderstanding (especially amongst C-programmers). What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. you are missing the point! Whather you can implement something faster in another language is not the issue. I am arguing for less verbose syntax without decreasing the clarity of the code in delphi/pascal and that is logically gonna improve productivity without taking anything away. jamie. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Florian Klaempfl wrote: If that were the case then yeah it would sux (however pythons performance is due to bien a bytecode interpreter and dynamic typing neither of which we need in pascal). Ref. counting etc. eats time because you need good garbage collection to detect cycles and other ugly stuff. There should be no cycles on TObjects so we dont need performance sapping code to detect them. TCOmponents are likely to have cycles as they tend to link to each other but then they would not be ref counted as they are parent/child owner managed anyway jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 13:38, Jamie McCracken wrote: > Florian Klaempfl wrote: > > I'am a poor delphi programmer, didn't use it for years, but I bet > > with any python programmer that I create any application faster > > than him :) > > You must be a damn fast typer then :) No, that's a common misunderstanding (especially amongst C-programmers). What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > Florian Klaempfl wrote: > >> >> I'am a poor delphi programmer, didn't use it for years, but I bet with >> any >> python programmer that I create any application faster than him :) > > > You must be a damn fast typer then :) I teached myself typing with 10 fingers, but typing is not the issue with auto completion etc. Show me a python ide which can do the same tricks as lazarus or delphi. >> The problem with pascal on linux was/is that there was no good >> compiler in the >> 90s for linux so a lot developers got lost. > > > Gnu pascal? We were talking about good :) > > >>> 1) Forward declarations - they sux! Why should the developers have the >>> burden of making the code totally sequential declaration wise. All other >>> modern compilers dont need this. >> >> >> >> C++ is still the number one language and it requires it. > > > yes but that aint modern! C# and python do not. Modern doesn't mean necessarily good ... >> Good performance like python ;)? > > > If that were the case then yeah it would sux (however pythons > performance is due to bien a bytecode interpreter and dynamic typing > neither of which we need in pascal). Ref. counting etc. eats time because you need good garbage collection to detect cycles and other ugly stuff. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually non-existant. Of course Python is piss poor in both performance and memory usage but it does point the way to a revitalised pascal. Adopting less verbose but still clean and clear syntax ala python is IMHO the way to make Pascal great again. I beg to differ. Recently I rewrote a python program (on linux). The pascal version was shorter and much clearer to understand. The python syntax is a horror as far as I'm concerned. Im not saying make pascal behave like python so if you were doing some weird dynamic stuff with python thats fair enough. ALl im sayting is theres no harm in replacing some of the verbose syntax with less verbose ones provided they dont harm the clarity of the code. I love delphi but find its verbosity a pain in some circumstances. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice, Mozilla etc. use ;), definitively not python ... Python is a usuable scripting language but nothing more. I agree but nevertheless it has become popular for desktop applications. Ubuntu and Fedora now uses it exclusively for filling in the blanks in their gnome desktops. on linux is virtually non-existant. The problem with pascal on linux was/is that there was no good compiler in the 90s for linux so a lot developers got lost. Gnu pascal? 1) Forward declarations - they sux! Why should the developers have the burden of making the code totally sequential declaration wise. All other modern compilers dont need this. C++ is still the number one language and it requires it. yes but that aint modern! C# and python do not. Sure your code might take a bit longer to compile but thats peanuts compare to the time saved in extra typing and reordering your code Did you ever work in a team? Then you know why ordering declarations is a good practice because reading non sequential declarations is hard. Yes i have worked in small teams and that was never an issue. Of course crazy ordering is harmful but any reasonable ordering is readable. 2) I have touched on manual memory managaement of tobjects before so I wont rehash it here (in summary ref count tobjects and they should have good performance with c++ style exception handling). Good performance like python ;)? If that were the case then yeah it would sux (however pythons performance is due to bien a bytecode interpreter and dynamic typing neither of which we need in pascal). jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thu, 2 Jun 2005, Jamie McCracken wrote:
Marc Weustink wrote:
What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to "decode" a "a := b
:= c := d := 0" line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read them over and
over to see what is going on.
Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me.
This also counts for the proposed c-isms.
For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)
I totally agree with you in this case - we dont want or need cryptic c stlye
syntax in any version of Pascal.
However, in general Pascal has poor developer productivity when compared to
modern languages like python and C#. Ironically python is perhaps the most
popular language on Linux and most of its syntax is derived from object
pascal whereas pascal on linux is virtually non-existant. Of course Python is
piss poor in both performance and memory usage but it does point the way to a
revitalised pascal. Adopting less verbose but still clean and clear syntax
ala python is IMHO the way to make Pascal great again.
I beg to differ.
Recently I rewrote a python program (on linux). The pascal version was
shorter and much clearer to understand. The python syntax is a horror
as far as I'm concerned.
What makes python interesting are the many classes it offers by default
to perform standard tasks, especially in the text treatment department;
regular expression stuff etc.
The same goes for most languages; Mostly it's not the language syntax
that determines the productivity factor; it's the number of standard
available routines.
Quabbling about being able to type
a:=b:=c:=d;
is beside the question. If your productivity depends on that, you're
either in the wrong business, or you are using the wrong kind of editor.
A good IDE/Editor has tools to make typing less cumbersome.
In the company where I work, 4 languages are in use: Delphi, VB, C++
and PHP. In order of descreasing productivity they are rated as follows:
- Delphi
- PHP
- VB
- C++
The order of VB/PHP was the most surprising for me; but that can maybe
be explained by the kind of app the language is used for.
Pascal is a language that allows you to develop in many styles, with as
much or as little optimization as you want, and all along it keeps your
code readable, which is very important when you work in team and you
need to read other people's code frequently. To see what I mean, try
reading this little 'gem':
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
(better yet, run it)
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote: > Useful extensions I would see: > > bigger sets: set of -10..10 (e.g.) Ordinals are positive numbers, and only ordinals can become set elements. In rare cases I missed bigger sets myself, in detail in parser generators and other automatons with many states. > a way to write integer constants in any base, not only > binary/octal/hexadecimal (not so important, but easy to implement) More important: Unicode literals. But I know that this would require a very big change to the scanner, and to all code editors and other tools. Perhaps somebody has another idea how to solve this problem? > more operators which can be overloaded (should follow the ALGOL68 rules) No, please, don't open a can of worms :-( > the C-style operators += etc. should better be written as +:= since C has = > as assignment, Pascal has := as assignment symbol := means "assign to", += means "add to" etc., I cannot find any inconsistency here. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel MyObject.Create is impossible with classes on the heap. You need to assign MyObject a pointer but you can't do that from within create. sorry myobject is the pointer so a better example would be : var strlist : Tstringlist; strlist.create; This should be easy as you know the pointer type. Forward declarations are IMHO required because otherwise the compiler would have to make additional passes(it does 3 AFAIK). They are not required in a multipass compiler. If you cant resolve a symbol on a single pass you can do so on a subsequent one. Besides, they are seldom enough to be a problem. Pain in the arse they are. Its annoying and makes use of the code explorer a neccsity when dealing with large classes. Its a total waste of my time. How does python handle modularity btw? WHat do you mean? Im a Delphi programmer not a python one (though Ive done bits and pieces in python) but I do envy its less verbose syntax as its just as clean and clear. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > Marc Weustink wrote: > >> >> >> What is easier to read is a matter of taste. >> Being a pascal devel for years now, it takes time to "decode" a "a := b >> := c := d := 0" line. There might be a ; inbeween which results in a >> complete different assignment. With such lines I've to read them over and >> over to see what is going on. >> Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me. >> This also counts for the proposed c-isms. >> >> For me I prefere clarity above less typing (besides if you want to write >> realy short code, you sould use APL) >> > > I totally agree with you in this case - we dont want or need cryptic c > stlye syntax in any version of Pascal. > > However, in general Pascal has poor developer productivity when compared > to modern languages like python and C#. I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) > Ironically python is perhaps the > most popular language on Linux and most of its syntax is derived from > object pascal whereas pascal Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice, Mozilla etc. use ;), definitively not python ... Python is a usuable scripting language but nothing more. > on linux is virtually non-existant. The problem with pascal on linux was/is that there was no good compiler in the 90s for linux so a lot developers got lost. > Of > course Python is piss poor in both performance and memory usage but it > does point the way to a revitalised pascal. Adopting less verbose but > still clean and clear syntax ala python is IMHO the way to make Pascal > great again. I wonder if Python couldn't revive Fortran with it's strange formatting rules. > > Consider the developer unfirendly nature of pascal/Delphi atm: > > 1) Forward declarations - they sux! Why should the developers have the > burden of making the code totally sequential declaration wise. All other > modern compilers dont need this. C++ is still the number one language and it requires it. > Sure your code might take a bit longer > to compile but thats peanuts compare to the time saved in extra typing > and reordering your code Did you ever work in a team? Then you know why ordering declarations is a good practice because reading non sequential declarations is hard. > > 2) I have touched on manual memory managaement of tobjects before so I > wont rehash it here (in summary ref count tobjects and they should have > good performance with c++ style exception handling). Good performance like python ;)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read them over and over to see what is going on. Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me. This also counts for the proposed c-isms. For me I prefere clarity above less typing (besides if you want to write realy short code, you sould use APL) I totally agree with you in this case - we dont want or need cryptic c stlye syntax in any version of Pascal. However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually non-existant. Of course Python is piss poor in both performance and memory usage but it does point the way to a revitalised pascal. Adopting less verbose but still clean and clear syntax ala python is IMHO the way to make Pascal great again. Consider the developer unfirendly nature of pascal/Delphi atm: 1) Forward declarations - they sux! Why should the developers have the burden of making the code totally sequential declaration wise. All other modern compilers dont need this. Sure your code might take a bit longer to compile but thats peanuts compare to the time saved in extra typing and reordering your code 2) I have touched on manual memory managaement of tobjects before so I wont rehash it here (in summary ref count tobjects and they should have good performance with c++ style exception handling). 3) loads of small and pointless additional syntax like EG for creating an object you should just be able to say: myobject.create; and not myobject := Tobject.create; also Begin..End blocks should IMO be replaced with python's indenting. Yeah I know this sounds like a hybrid pascal/python but I believe thats the way to go - marry Delphi's speed and component framework with less verbose python style syntax and you will have the best RAD language ever written. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel MyObject.Create is impossible with classes on the heap. You need to assign MyObject a pointer but you can't do that from within create. Forward declarations are IMHO required because otherwise the compiler would have to make additional passes(it does 3 AFAIK). Besides, they are seldom enough to be a problem. How does python handle modularity btw? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read them over and over to see what is going on. Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me. This also counts for the proposed c-isms. For me I prefere clarity above less typing (besides if you want to write realy short code, you sould use APL) I totally agree with you in this case - we dont want or need cryptic c stlye syntax in any version of Pascal. However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually non-existant. Of course Python is piss poor in both performance and memory usage but it does point the way to a revitalised pascal. Adopting less verbose but still clean and clear syntax ala python is IMHO the way to make Pascal great again. Consider the developer unfirendly nature of pascal/Delphi atm: 1) Forward declarations - they sux! Why should the developers have the burden of making the code totally sequential declaration wise. All other modern compilers dont need this. Sure your code might take a bit longer to compile but thats peanuts compare to the time saved in extra typing and reordering your code 2) I have touched on manual memory managaement of tobjects before so I wont rehash it here (in summary ref count tobjects and they should have good performance with c++ style exception handling). 3) loads of small and pointless additional syntax like EG for creating an object you should just be able to say: myobject.create; and not myobject := Tobject.create; also Begin..End blocks should IMO be replaced with python's indenting. Yeah I know this sounds like a hybrid pascal/python but I believe thats the way to go - marry Delphi's speed and component framework with less verbose python style syntax and you will have the best RAD language ever written. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of listmember
>Maybe a few things should be borrowed from RemObjects Chrome, such as
>
>-- Class Contracts
>http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30
D8}
>
>I like the 'require/ensure' aproach.
>
>It makes the code more robust and more debuggable, IMHO
I think the checks you can do there are to limited. I also wonder what
will happen if a require isn't met. Personally I don't want exeption in my
released app.
>-- Generics
>http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E7721
86E}
>
>I am not sure if Generics could be done in FPC.
There were some discussions about it here and AFAIK some are trying to
implement.
>-- Virtual Properties and Events
>http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE
99}
The examples given there are not very different of what is possible now.
Make SetWith virtual and you have almost the same.
What however would be nice is if you could override the getter or setter.
Something like
property Width write MySetWidth
>-- Enhanced Multicast Events
>http://www.remobjects.com/page.asp?id={CC9C4828-9E49-4C41-AFD9-0BFFA4E9C3
D3}
This is not really new. You can implement it yourself like
property OnChange: TNotifyList;
and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc)
>Inline variable initializers, such as:
[snip]
>var
> Integer1: Integer = 15;
> Boolean1: Boolean = False;
> String1: String = 'SOME TEXT';
Hmm.. sometimes usefull. You can put it as first lines in your
constructor/codeblock, but keep it thogheter in say large classes can be
handy.
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
From: Gerhard Scholz Sent: woensdag 1 juni 2005 18:35 >- Original Message - >From: "Marco van de Voort" <[EMAIL PROTECTED]> >To: "FPC developers' list" >Sent: Wednesday, June 01, 2005 1:50 PM >Subject: Re: [fpc-devel] Re: [fpc-l] type discussion [big snip] >> > multiple assignments: >> > >> > a := b := c := d := 0 ; >> > >> > etc. >> >> Same point. Totally useless. > >easier to read, especially in sequencies of variable initializations What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read them over and over to see what is going on. Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me. This also counts for the proposed c-isms. For me I prefere clarity above less typing (besides if you want to write realy short code, you sould use APL) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On 1 jun 2005, at 18:35, Gerhard Scholz wrote: X is just an example, more useful of course it is in situations like anArray[i,j]^ := anArray[i,j]^ * y ; Similar to "inc(x)" compared to "x:=x+1"; in C (and if I remember correct, ALGOL68 also) uses this as a hint for optimization: the reference to anArray[i,j]^ is evaluated only once (similar as it is handled in an WITH statement). In modern compilers all these shorthands from the past only create extra complexity without different results. I checked it with the FPC (nice that there are assembler files as output); the GNU C compiler translates "arr[ii] += 1" better than FPC. GCC will translate "arr[ii] = arr[ii] + 1" to exactly the same code. This has nothing to do with whether or not you support some syntactic sugar, but with how good the optimizer is. GCC's optimizer(s) is (are) definitely more advanced than FPC's. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marco van de Voort wrote:
Some of these target functionality (specially in the linking section) might
require restructures
related to
* introduction of an internal linker for some core platforms (no more LD)
* Rewrite of module (unit) handling
Yes, these would be great, IMHO.
For the rest, improve RTL/FCL compability and extend them in general, and of
course fixbugs.
Beside of compatibility towards Delphi or MacPascal or others FPC should be
open to other modifications/extensions (maybe Delphi one day copies FC a bt
:-), and not always the other way round)
Maybe a few things should be borrowed from RemObjects Chrome, such as
-- Class Contracts
http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30D8}
I like the 'require/ensure' aproach.
It makes the code more robust and more debuggable, IMHO
-- Generics
http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}
I am not sure if Generics could be done in FPC.
-- Virtual Properties and Events
http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE99}
-- Enhanced Multicast Events
http://www.remobjects.com/page.asp?id={CC9C4828-9E49-4C41-AFD9-0BFFA4E9C3D3}
Inline variable initializers, such as:
type
TSomethingElse = class(TSomething)
private
FInteger: Integer = 15;
FBoolean: Boolean = False;
FString: String = 'SOME TEXT';
{etc}
protected
public
published
end;
Similarly, for
function Something(...): Boolean = False;
var
Integer1: Integer = 15;
Boolean1: Boolean = False;
String1: String = 'SOME TEXT';
begin
end;
Procedure Something(Out AInteger: Integer = 12; );
var
Integer1: Integer = 15;
Boolean1: Boolean = False;
String1: String = 'SOME TEXT';
begin
end;
Useful extensions I would see:
bigger sets: set of -10..10 (e.g.)
I'd like that too.
Me too.
a way to write integer constants in any base, not only
binary/octal/hexadecimal (not so important, but easy to implement)
Rarely used. Specially since more than base 36 becomes a notational
> problem. However it has been brought up before.
If someone contributes the code, why not. It does not hurt, IMHO.
writing of enums to text file;
This should be supported, however needs some tricks. (RTTI is available for
enums!)
Yes. Ditto.
more operators which can be overloaded (should follow the ALGOL68 rules)
IMHO this is asking for a mess, and the use is limited.
Again, agreed.
multiple assignments:
a := b := c := d := 0 ;
etc.
Same point. Totally useless.
Not really useful. More like confusing, to me, that is.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
my marks start with :
- Original Message -
From: "Ales Katona" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Wednesday, June 01, 2005 6:52 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
> Gerhard Scholz wrote:
>
> >>> var
> >>> x : type1, y : type2 ;
> >>>
> >>> x *:= y ;
> >>>
> in my humble opinion(IMHO):
thanks for the explanation
>
> := is based on the fact that A: is written normaly in math etc. where it
> means " this is a fact about A "
> So when someone writes A:=5; it means "it's a fact that A equals 5"
fine, but in programming ":=" usually means "becomes"
> Writing A*:= is stupid. If nothing else do it like this:
> A:*=
> But IMHO it's useless in ANY case. Even C people tend to not use it when
> they want readible code(especialy * which is so ambiguos)
the star "*" here just was an an example for any operator, could have
been +, / or AND or whatever
>
> As to the ASM:
>
> in C if you do a+=b; and a is int b is longint it does this actualy:
> a = a + (int)b;
>
> which is stupid and unsafe.
I do not see this is an argument.
var a:integer; b:longint; sb : integer ;
{1} a += b ;
{2} a := a + b ;
{3} sb := b ; a+=sb ;
All three versions produce the same nonsense. To avoid such nonsense I like
the compiler checks (range on, overflow on, stack overflow on, ioerror on).
>
> Just my 0.05 euros
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote: var x : type1, y : type2 ; x *:= y ; in my humble opinion(IMHO): := is based on the fact that A: is written normaly in math etc. where it means " this is a fact about A " So when someone writes A:=5; it means "it's a fact that A equals 5" Writing A*:= is stupid. If nothing else do it like this: A:*= But IMHO it's useless in ANY case. Even C people tend to not use it when they want readible code(especialy * which is so ambiguos) As to the ASM: in C if you do a+=b; and a is int b is longint it does this actualy: a = a + (int)b; which is stupid and unsafe. Just my 0.05 euros ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: "Marco van de Voort" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Wednesday, June 01, 2005 1:50 PM Subject: Re: [fpc-devel] Re: [fpc-l] type discussion >... (shortened) > > > > Useful extensions I would see: > > > > bigger sets: set of -10..10 (e.g.) > > I'd like that too. nice that we agree > > > a way to write integer constants in any base, not only > > binary/octal/hexadecimal (not so important, but easy to implement) > > Rarely used. Specially since more than base 36 becomes a notational problem. > However it has been brought up before. > range 2..36 for the base should be enough. I have a working implementation; notation is: base_digits (the base is in decimal, the digits then the usual 0..9a..z) e.g.: 36_z = 35 seldom used, I admit, but easier to read than these $- and %- notations >... (shortened) > > more operators which can be overloaded (should follow the ALGOL68 rules) > > IMHO this is asking for a mess, and the use is limited. sorry, I'm don't know that abbreviation: IMHO; the use might look limited, but when implemented, people will find their use. ALGOL68 not only allowed operators like + - // etc, but also words/identifiers. > > > should automatically permit constructions like: > > > >var > > x : type1, y : type2 ; > > > >x *:= y ; > > Why to save two characters? The C operators were afaik mostly added to ease > porting critical C code. However IMHO one shouldn't use them in new code, > and there is no need to start adding variations on the C syntax. X is just an example, more useful of course it is in situations like anArray[i,j]^ := anArray[i,j]^ * y ; Similar to "inc(x)" compared to "x:=x+1"; in C (and if I remember correct, ALGOL68 also) uses this as a hint for optimization: the reference to anArray[i,j]^ is evaluated only once (similar as it is handled in an WITH statement). I checked it with the FPC (nice that there are assembler files as output); the GNU C compiler translates "arr[ii] += 1" better than FPC. Specially when C code is ported it is wise to look at the results; they might be different!. Beside, this is not C syntax, but ALGOL68 syntax, which is some years older. > > > multiple assignments: > > > > a := b := c := d := 0 ; > > > > etc. > > Same point. Totally useless. easier to read, especially in sequencies of variable initializations Greetings Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
El Miércoles, 1 de Junio de 2005 13:50, Marco van de Voort escribió: > Main plans short term to my knowledge are: > ... > * improved "packages" and dynamic libraries (PIC!) support in general. Sorry if I've been confused by "improved". Is PIC already supported? -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> I followed this discussion if that construction (see below) should be > allowed or not (I think it should be allowed, but it's possible to live > without it; I can imagine situations where it could make easier to read), > and I'm missing a bit a discussion forum about the future of FPC. It > should > contain what is planned to be implemented, it should contain about ideas > of > what could be implemented. See below > I've read somewhere that Delphi 7 compatibility is planned (since I do not > have it I do not know what that means in detail). > > Beside of compatibility towards Delphi or MacPascal or others FPC should > be > open to other modifications/extensions (maybe Delphi one day copies FC a > bt > :-), and not always the other way round) Don't expect anything. Like assigning values to enumarations we had it already before Delphi did. And also with inlining they added other rules. > Useful extensions I would see: > > bigger sets: set of -10..10 (e.g.) > > a way to write integer constants in any base, not only > binary/octal/hexadecimal (not so important, but easy to implement) You can write your own routine for that. > writing of enums to text file; Enums are like constant numbers. You can already write them to a file using a typecast: writeln(longint(enum)); > more operators which can be overloaded (should follow the ALGOL68 rules) > > the C-style operators += etc. should better be written as +:= since C has > = > as assignment, Pascal has := as assignment symbol This will break existing code. And IMHO it looks very strange with the colon in the middle. > automatic assignment operators: > > operator * ( a : type1 ; b : type2 ) : type1 > > should automatically permit constructions like: > >var > x : type1, y : type2 ; > >x *:= y ; > > multiple assignments: > > a := b := c := d := 0 ; This was in the compiler in the past and caused a lot of trouble and hacks in the parser. > That are just some ideas. Maybe there are more? But are they usefull? Do they add something or only save you typing? THat is why there is no discussion about future on the webpages. Discussion shall take place at the mailing lists. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> I've read somewhere that Delphi 7 compatibility is planned (since I do not > have it I do not know what that means in detail). Main plans short term to my knowledge are: * create/improve the COM/OLE support. This has multiple facets: o COM compat interfaces/vmt o Variants (needed for OLE) o implements style delegation * linking/debug/fileformats related * improve smartlinking (get rid of .a files, less mem use) * improved "packages" and dynamic libraries (PIC!) support in general. * crosslinking (2.0 is actually quite crosslink capable already) * stabs->dwarf crossover. * Some form of Kylix compat resources.(still under discussion) * Support for 64-bit (sized) native filetypes. Some of these target functionality (specially in the linking section) might require restructures related to * introduction of an internal linker for some core platforms (no more LD) * Rewrite of module (unit) handling For the rest, improve RTL/FCL compability and extend them in general, and of course fixbugs. > Beside of compatibility towards Delphi or MacPascal or others FPC should be > open to other modifications/extensions (maybe Delphi one day copies FC a bt > :-), and not always the other way round) > > Useful extensions I would see: > > bigger sets: set of -10..10 (e.g.) I'd like that too. > a way to write integer constants in any base, not only > binary/octal/hexadecimal (not so important, but easy to implement) Rarely used. Specially since more than base 36 becomes a notational problem. However it has been brought up before. > writing of enums to text file; This should be supported, however needs some tricks. (RTTI is available for enums!) > more operators which can be overloaded (should follow the ALGOL68 rules) IMHO this is asking for a mess, and the use is limited. > should automatically permit constructions like: > >var > x : type1, y : type2 ; > >x *:= y ; Why to save two characters? The C operators were afaik mostly added to ease porting critical C code. However IMHO one shouldn't use them in new code, and there is no need to start adding variations on the C syntax. > multiple assignments: > > a := b := c := d := 0 ; > > etc. Same point. Totally useless. > That are just some ideas. Maybe there are more? To judge extensions, it might be smart to check this faq item: http://www.freepascal.org/faq.html#extensionselecthttp://www.freepascal.org/faq.html#extensionselect which is more or less a rough view on how we (or actually more I, since I wrote it) see extensions to the language. Except larger sets and more control about set packing is the only really interesting thing IMHO generics/templates, since it really makes heaps of new behaviour possible, and is not purely syntax that saves typing. The wiki also contains some roadmap info: http://www.freepascal.org/wiki/index.php/Detailed_2.1.0_branch_todo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [fpc-l] type discussion
I followed this discussion if that construction (see below) should be allowed or not (I think it should be allowed, but it's possible to live without it; I can imagine situations where it could make easier to read), and I'm missing a bit a discussion forum about the future of FPC. It should contain what is planned to be implemented, it should contain about ideas of what could be implemented. I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail). Beside of compatibility towards Delphi or MacPascal or others FPC should be open to other modifications/extensions (maybe Delphi one day copies FC a bt :-), and not always the other way round) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) writing of enums to text file; more operators which can be overloaded (should follow the ALGOL68 rules) the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol automatic assignment operators: operator * ( a : type1 ; b : type2 ) : type1 should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; multiple assignments: a := b := c := d := 0 ; etc. That are just some ideas. Maybe there are more? Greetings Gerhard - Original Message - From: "Florian Klaempfl" <[EMAIL PROTECTED]> To: "FPC-Pascal users discussions" Sent: Sunday, May 29, 2005 2:05 PM Subject: Re: [fpc-pascal] Re: ... > > > > type > > pMyRec = ^tMyRec; > > > > type > > tMyRec = Record > > data:pointer; > > next:pMyRec; > > end; > > > > and this: > > > > type > > pMyRec = ^tMyRec; > > > > tMyRec = Record > > data:pointer; > > next:pMyRec; > > end; > > ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
