Re: [fpc-pascal] for .. in loop implementation
Jürgen Hestermann wrote: Mantra: First make it work, then make it fast. In general that's true from the programmer's viewpoint. But this does not apply to adding language details because there is no 'first make it work'. Why obscure important implementation details if the only benefit is saving some writing? I won't judge on the "only save some writing" here, but generally it *does* apply to language features: If a particular language feature helps you writing correct code faster (by supporting you to make it work instead of relying on your abilities to use the debugger), then it does apply. The real question is if the (or any other) proposal is "good enough" to do just that, or if it's really some syntactic sweetener (not even sugar, sugar at least contains energy). That's something to discuss. Let me take a rather extreme point of view: After all, all those for-, while-, and repeat-until-loops are only there to save you from some typing work[0], because Pascal already has a perfectly good loop-construct with which you can do all that: goto. Would you agree here? Probably not. > BTW, any performance differences in the example above highly depends > on the work done in the loop body anyway, so whining about possible > performance issues is quite a bit premature here. ;) Maybe, but you started talking about performance. ;-) Nono, you did: "Everything that obscures what's going on under the hood has the potential to generate performance problems." IMO, almost every language construct of a modern language (modern as in "invented about 30 years ago") has the potential to just do that. Loops may hide costly branches, string concatenations may hide costly memory copy operations (not even talking about AnsiStrings here, where an additional overhead of memory allocation/deallocation may occur), costly lookups and indirect calls are hidden by virtual methods that may look like simple procedure calls, or the worst: operator overloading enables the programmer to hide practically anything inside a simple "+" (nothing stops you from doing "c = a + b" where "a" and "b" are pulled from an internet daabase and "c" is stored back there, all hidden in a simple addition), etc. pp. Even in C (which is a language widely accepted as one where nothing is hidden from the programmer[1]) you can assign structs to each other which - depending on the size and layout of the structure - may result in rather costly memory copy operations. So to get to the point, finally: The argument that some particular language construct has the potential to generate performance problems is NIL. IMNSHO. Vinzent. [0] By removing the need for labels. [1] Nothing but bugs, hehe. :-> SCNR. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
P.S. Honestly, Pascal (and especially ObjectPascal) already hides quite some stuff from the programmer. Properties, for example, can hide potentially costly procedure calls in simple assignment statements. That's true. But I am not happy about that approach. In the last years lots of things were added to Pascal that are no longer clear and simple. And most of them are of little use (for the programmer). They only bloated the so small and easy to learn language. Mantra: First make it work, then make it fast. In general that's true from the programmer's viewpoint. But this does not apply to adding language details because there is no 'first make it work'. Why obscure important implementation details if the only benefit is saving some writing? > BTW, any performance differences in the example above highly depends > on the work done in the loop body anyway, so whining about possible > performance issues is quite a bit premature here. ;) Maybe, but you started talking about performance. ;-) Jürgen Hestermann. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Library Project raises Linker Error Hints at -fPIC option
Hi Jonas, I posted bug with source. Here is a link http://bugs.freepascal.org/view.php?id=12940 Thanks, -Andy On Wed, Jan 7, 2009 at 6:09 AM, Jonas Maebe wrote: > > On 07 Jan 2009, at 03:46, Andrew Brunner wrote: > >> Can anyone tell me why this would be a problem or what I need to do to >> get FPC to build or LD to link properly? > > It sounds like a bug in the code generator. Please submit a bug report with > a compilable library that demonstrates the program. > > > Jonas > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing a compiler
> 3. Handwritten > Question: Need some references other than Jack Crenshaw's book > Pros: Easier to maintain (someone said, but no prove) > Cons: I don't have any practical background on this I have written a very simple Pascal to Java-bytecode compiler. It compiles a very simplified Pascal. I did it handwritten because that's what the professor wanted. It's documented in portuguese, but here is the link in case it helps: http://p-tools.svn.sourceforge.net/viewvc/p-tools/fpjava/ My professor uses Wirth notation for the gramatics -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
the nice thing about pascal, is that compile support different code
compilers syntax: {$mode ...}
if anyone likes, he/she can implement additional {$mode} for the
compiler, right? this new {$mode} can be included into compiler
packages, and if necesssary anyone can rebuild the compiler to support
this new mode!
there're a lot of threads talking about "it's so cool to have this
feature...". But fpc is open source, so feel free to implement it your
own modes :)
anyway, about topic:
type
TDays: (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday);
TDaySet: set of TDays;
var
d: TDaySet;
begin
for d in [Monday,Wednesday,Friday] do ;
// versus
for d:=Low(TDaySet) to High(TDaySet) do
if d in [Monday,Wednesday,Friday] then ;
end;
here's another nice way to implement this without overhead: open-arrays!
procedure DayLoop(const Days: array of TDays);
var
i : integer;
begin
for i := 0 to length(Days) - 1 do
Days[i]...
end;
...
DayLoop( [Monday,Wednesday,Friday] );
..
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
Jürgen Hestermann wrote: I disagree with any statement saying that for .. in loop is only a type-saver. It's a good language extension and should be included (since Delphi already have this, it will also be a good idea). Consider the following example: for d in [Monday,Wednesday,Friday] do ; // versus for d:=Low(TDaySet) to High(TDaySet) do if d in [Monday,Wednesday,Friday] then ; The latter one has iteration overheads, while the former can be optimized to loop as many as needed. I'm not saying I'm the best Pascal programmer, but in case there's a (better) solution to this (rather than extending the language) please tell me. I think there will be no performance difference because internaly the compiler has to generate something like the first for-loop anyway. No. It could unroll the loop, and then use constants throughout the three copied loop-bodies instead. Of course, a smart compiler could end up with the same approach after analyzing the code, so indeed: There should be no performance difference. It will only be hidden from the programmer and I am not sure whether this a good thing. Everything that obscures what's going on under the hood has the potential to generate performance problems. Yes, that's what I hear from C-enthusiasts all the time. And that's also why everything should be written in assembler these days, because then performance problems would jump right at you when reading the code. (In case anyone wonders, yes, the last sentence above is 100% sarcasm.) > In your example, you may not be aware that at the end all possible members have to be checked for beeing part of the set. If you only read for d in [Monday,Wednesday,Friday] do ; you may think that the loop is run through only 3 times, but internally there are much more iterations (to check the "if d in [Monday,Wednesday,Friday]"). Indeed. But there could even be no loop at all, even if there's a loop expression in the source code. Vinzent. P.S. Honestly, Pascal (and especially ObjectPascal) already hides quite some stuff from the programmer. Properties, for example, can hide potentially costly procedure calls in simple assignment statements. Things like SomeStringList['Name'] := 'Value'; might be a relatively cheap O(1) operation if implemented with a hash table, it could be an O(log n) operation if the list is sorted and a binary search is done, or it could even be a O(n) operation if implemented by a simple linear search, but who knows? Some of the time you don't even care, because the number of strings is not large enough to make a noticeably difference; in fact, the usage of AnsiStrings alone and the associated reference counting and constant memory allocation and deallocation might even be much more influencing on the overall performance. Don't get me wrong, usually this hiding of implementation details is a good thing, because it let's you solve the problem at hand a lot more quicker. If the solution turns out to be "not fast enough", you can still start optimizing instead of doing it the other way around. Mantra: First make it work, then make it fast. IOW: A fast, but wrong solution is one thing first: Wrong. No matter how fast it does it wrong. BTW, any performance differences in the example above highly depends on the work done in the loop body anyway, so whining about possible performance issues is quite a bit premature here. ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
I disagree with any statement saying that for .. in loop is only a type-saver. It's a good language extension and should be included (since Delphi already have this, it will also be a good idea). Consider the following example: for d in [Monday,Wednesday,Friday] do ; // versus for d:=Low(TDaySet) to High(TDaySet) do if d in [Monday,Wednesday,Friday] then ; The latter one has iteration overheads, while the former can be optimized to loop as many as needed. I'm not saying I'm the best Pascal programmer, but in case there's a (better) solution to this (rather than extending the language) please tell me. I think there will be no performance difference because internaly the compiler has to generate something like the first for-loop anyway. It will only be hidden from the programmer and I am not sure whether this a good thing. Everything that obscures what's going on under the hood has the potential to generate performance problems. In your example, you may not be aware that at the end all possible members have to be checked for beeing part of the set. If you only read for d in [Monday,Wednesday,Friday] do ; you may think that the loop is run through only 3 times, but internally there are much more iterations (to check the "if d in [Monday,Wednesday,Friday]"). Jürgen Hestermann. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Library Project raises Linker Error Hints at -fPIC option
On 07 Jan 2009, at 03:46, Andrew Brunner wrote: Can anyone tell me why this would be a problem or what I need to do to get FPC to build or LD to link properly? It sounds like a bug in the code generator. Please submit a bug report with a compilable library that demonstrates the program. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
leledumbo schreef: OK, I've read http://wiki.freepascal.org/Modernised_Pascal this (and the FAQ as well). I disagree with any statement saying that for .. in loop is only a type-saver. It's a good language extension and should be included (since Delphi already have this, it will also be a good idea). Consider the following example: type TDays: (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday); TDaySet: set of TDays; var d: TDaySet; begin for d in [Monday,Wednesday,Friday] do ; // versus for d:=Low(TDaySet) to High(TDaySet) do if d in [Monday,Wednesday,Friday] then ; end; The latter one has iteration overheads, while the former can be optimized to loop as many as needed. I'm not saying I'm the best Pascal programmer, but in case there's a (better) solution to this (rather than extending the language) please tell me. You could write it like this: type TDays: (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday); TDaySet: set of TDays; var d: TDays; // note the type i: 0..2; const SomeDays: array[0..2] of TDays = (Monday,Wednesday,Friday); begin for i:=Low(SomeDays) to High(SomeDays) do begin d := SubSet[i]; end; end; And it loops as many times as necessary. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation
In our previous episode, leledumbo said: > The latter one has iteration overheads, while the former can be optimized to > loop as many as needed. I'm not saying I'm the best Pascal programmer, but > in case there's a (better) solution to this (rather than extending the > language) please tell me. Your assesment is correct as far as I can see. However IMHO that doesn't meant you are right. One single case of an optimalization advantage, and then in a border case like iteration over a constant set does not justify a language extension. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] for .. in loop implementation
OK, I've read http://wiki.freepascal.org/Modernised_Pascal this (and the FAQ as well). I disagree with any statement saying that for .. in loop is only a type-saver. It's a good language extension and should be included (since Delphi already have this, it will also be a good idea). Consider the following example: type TDays: (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday); TDaySet: set of TDays; var d: TDaySet; begin for d in [Monday,Wednesday,Friday] do ; // versus for d:=Low(TDaySet) to High(TDaySet) do if d in [Monday,Wednesday,Friday] then ; end; The latter one has iteration overheads, while the former can be optimized to loop as many as needed. I'm not saying I'm the best Pascal programmer, but in case there's a (better) solution to this (rather than extending the language) please tell me. -- View this message in context: http://www.nabble.com/for-..-in-loop-implementation-tp21327686p21327686.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Part of OOo Linux is written in FPC?
On 07 Jan 2009, at 05:23, leledumbo wrote: I've read this in a discussion forum somewhere, is it true? There's no Pascal code in Open Office according to Ohloh: http://www.ohloh.net/p/openoffice/analyses/latest Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
