Re: [fpc-devel] Local procedures as procedural parameter
On Mon, 14 Mar 2005, Adriaan van Os wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure typ_fun( pf: tfun);
begin
end;
procedure somefun;
function f( x: real): real;
begin
f:= x
end;
begin
iso_fun( f);
typ_fun( f); {procedural variable can't get nested routiine}
end;
begin
end.
1. What happens if f would use a variable from somefun, and f is called
when somefun is no longer executed ?
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is allowed,
the other should be allowed as well.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 09:45, Michael Van Canneyt wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure typ_fun( pf: tfun);
begin
end;
procedure somefun;
function f( x: real): real;
begin
f:= x
end;
begin
iso_fun( f);
typ_fun( f); {procedural variable can't get nested routiine}
end;
begin
end.
1. What happens if f would use a variable from somefun, and f is called
when somefun is no longer executed ?
That is not possible. If you take the address of f and put it in a
procedural variable, you'll get an error (just like when you attempt to
assign a method to a regular procedural variable). You can only pass it
as parameter to procedures declared with an ISO-style
procedure/function parameter, and since its scope is limited to
somefun, somefun will always be active when you can do so.
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is allowed,
the other should be allowed as well.
Well, it currently isn't in either our compiler or in Delphi. You
cannot declare a function type inside a parameter list for now. Maybe
this was even done on purpose to avoid clashes with ISO-style procedure
parameters.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On Mon, 14 Mar 2005, Jonas Maebe wrote:
On 14 mrt 2005, at 09:45, Michael Van Canneyt wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure typ_fun( pf: tfun);
begin
end;
procedure somefun;
function f( x: real): real;
begin
f:= x
end;
begin
iso_fun( f);
typ_fun( f); {procedural variable can't get nested routiine}
end;
begin
end.
1. What happens if f would use a variable from somefun, and f is called
when somefun is no longer executed ?
That is not possible. If you take the address of f and put it in a procedural
variable, you'll get an error (just like when you attempt to assign a method
to a regular procedural variable). You can only pass it as parameter to
procedures declared with an ISO-style procedure/function parameter, and since
its scope is limited to somefun, somefun will always be active when you can
do so.
But the compiler can never guarantee this ?
It seems to me that the following is perfectly valid code :
Var
StoredF : Function (x : real) : real
Procedure iso_fun( function f( x: real): real);
begin
StoredF:=F;
end;
StoredF can then be called at will, even outside somefun.
When compiling this, there is no way the compiler can determine whether
f (or storedf) will be a local procedure or a global one. To solve this,
it would mean that each procedure variable would have to consist of 2
things; A pointer and a type indicator.
This would break _a lot_ of existing code. If that is the consequence, I
am heavily against introducing this possibility.
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is allowed,
the other should be allowed as well.
Well, it currently isn't in either our compiler or in Delphi. You cannot
declare a function type inside a parameter list for now. Maybe this was even
done on purpose to avoid clashes with ISO-style procedure parameters.
Yes, but why would one be allowed and the other not ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:15, Michael Van Canneyt wrote: It seems to me that the following is perfectly valid code : Var StoredF : Function (x : real) : real This is a regular procedural variable, not an ISO-style procedural variable. Just like var a: array of byte; is a dynamic array and not an open array. Procedure iso_fun( function f( x: real): real); begin StoredF:=F; end; This assignment is invalid, it's the same as trying to assign a method to a regular procedural variable. StoredF can then be called at will, even outside somefun. When compiling this, there is no way the compiler can determine whether f (or storedf) will be a local procedure or a global one. To solve this, it would mean that each procedure variable would have to consist of 2 things; A pointer and a type indicator. This would break _a lot_ of existing code. If that is the consequence, I am heavily against introducing this possibility. That is not necessary. Well, it currently isn't in either our compiler or in Delphi. You cannot declare a function type inside a parameter list for now. Maybe this was even done on purpose to avoid clashes with ISO-style procedure parameters. Yes, but why would one be allowed and the other not ? In general, you cannot declare complex types inside a parameter list (you also can't declare new record, array or set types inside a parameter list). That's why you can (ab)use those things to declare special things, like open arrays (and ISO-style procvars). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:37, [EMAIL PROTECTED] wrote: 2. I see no difference whatsoever between typ_fun and iso_fun, except the use of an extra type, which, in my opinion, does not change anything to the usage or code of these functions. If one is allowed, the other should be allowed as well. No, and at present there is no difference in generated code. Note that you are talking about MacPas mode now. In the generic fpc mode (or in Delphi or TP mode), you cannot declare a procedural variable type inside a parameter list. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:34, Marco van de Voort wrote: BuIt seems to me that the following is perfectly valid code : Var StoredF : Function (x : real) : real This is not allowed. Only TP style is allowed with VAR, so var stored : TSomeFunc; That's not true, the above is perfectly valid (but it creates a regular procedural variable, and not an ISO-style procedural variable, as those simply do not exist). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:51, Michael Van Canneyt wrote: 2. I see no difference whatsoever between typ_fun and iso_fun, except the use of an extra type, which, in my opinion, does not change anything to the usage or code of these functions. If one is allowed, the other should be allowed as well. No, and at present there is no difference in generated code. Which means that the above example IS a problem. Only because the compiler currently does not support ISO-style procvars. Olle changed it to accept the syntax (so it works in cases you do not access variables of a parent), but it generates code as if it's a regular procvar (which is indeed wrong). The latter is what Adriaan wants to fix. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
Michael Van Canneyt wrote: In fact standard pascal does not allow procedure variables, only procedure parameters (note the difference). I suppose the above problem is the reason. Then I think standard pascal is very handicapped indeed. var f : function : longint of procedure(a : longint); I dont think this is allowed :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:34, Marco van de Voort wrote: BuIt seems to me that the following is perfectly valid code : Var StoredF : Function (x : real) : real This is not allowed. Only TP style is allowed with VAR, so var stored : TSomeFunc; That's not true, the above is perfectly valid (but it creates a regular procedural variable, and not an ISO-style procedural variable, as those simply do not exist). That's another possibility. I was just naming a way to avoid the problem. You specify/implemented another, but the point was that it doesn't _have_ to be a problem :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
Procedure iso_fun( function f( x: real): real); begin StoredF:=F; end; This assignment is invalid, it's the same as trying to assign a method to a regular procedural variable. This is exactly my point: how does the compiler distinguish the two in this case ? Possible soultions: They have different datatypes, or a flag is set in the type definition. I don't see how, unless you add an extra parameter for the 'iso' way of doing things. So, basically, to be able to use a local procedure as a callback, - You must declare a function with the ISO way to specify a callback. - This function is not usable with a global callback function. - So if you would want to use such a function for both normal and local procedures, you would have to implement it twice ! If this is indeed the case, then it is totally ridiculous in my opinion to implement such a feature, because if you must make special amends _anyway_, then you can just as well do it with global functions, without the local variants. I would only see the use of being able to pass a local function as a callback if the called function can be used for both local and global callback procedures. It can. When a global proc is passed, the static link is set to nil. I question the usefullness of this whole feature. When using a call back, you dont need to pass data to it as global variables, making code cleaner. Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 10:51, Michael Van Canneyt wrote: 2. I see no difference whatsoever between typ_fun and iso_fun, except the use of an extra type, which, in my opinion, does not change anything to the usage or code of these functions. If one is allowed, the other should be allowed as well. No, and at present there is no difference in generated code. Which means that the above example IS a problem. Only because the compiler currently does not support ISO-style procvars. Olle changed it to accept the syntax (so it works in cases you do not access variables of a parent), but it generates code as if it's a regular procvar (which is indeed wrong). The latter is what Adriaan wants to fix. The credits should go to Peter, who implemented it :-) Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
No, because in this case, you are comparing 2 basically different programming techniques: OOP and linear; they are fundamentally different in their practical use. The iso feature supports a third, namely recursive programming, which has been forgotten after C took over the world and introduced its assembly style programming. I don't see much code out there which mixes the two. (I'm talking 50-50%, not 99-1%) Beware: I want to make clear that I am not against the concept an sich. If the compiler was born 'out of the blue', and it supported 'iso' procedures from the very start, the problem would not exist. All procedures (local and global) could be made 'iso-aware', and you would be able to pass both local and global functions for the same procedural parameter. The problem is that we are in the situation where the majority of existing code There is a lot of existing code out there which currently are not supported by any live compiler, namely everything written in some of the mac pascals. FPC can be the remedy. does not work like that, and that we have to introduce a 'schisma' in the compiler. I'm not particularly fond of this idea. As I see the suggested solution, the iso stuff can be added, without affecting existing code. Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
Michael Van Canneyt wrote: I will object against a solution that causes existing code to be altered in any way, such as an extra hidden parameter for all callbacks. For the ISO ones, I don't think there is any other way of doing it. As long as it is restricted to those, there is no problem... If it would cause all types of proc. vars. (which is doesn't as far as I understand) it could be made mac mode only. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 11:11, Michael Van Canneyt wrote: No, because normally, one never mixes 'procedure of object' with 'procedural'. You program either linear, either OOP, so you either use one or the other, never both. The distinction is also very clear. Except when programming a compiler, apparently :) No, because in this case, you are comparing 2 basically different programming techniques: OOP and linear; they are fundamentally different in their practical use. With nested procedures, you are emulating parts of OOP using procedural programming. They were some form of OOP avant-la-lettre. I don't see much code out there which mixes the two. (I'm talking 50-50%, not 99-1%) They all have their own uses. I want to make clear that I am not against the concept an sich. If the compiler was born 'out of the blue', and it supported 'iso' procedures from the very start, the problem would not exist. All procedures (local and global) could be made 'iso-aware', and you would be able to pass both local and global functions for the same procedural parameter. Then you'd get problems with C callbacks... The problem is that we are in the situation where the majority of existing code does not work like that, and that we have to introduce a 'schisma' in the compiler. I'm not particularly fond of this idea. The majority of existing code depends on whose code it is. Existing programs will not notice anything, for them declaring a procedural variable type in a parameter list will remain impossible. It's only for people using MacPas mode, who are used to these semantics, that things will change (or rather remain the same compared to other compilers). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 11:53, Florian Klaempfl wrote: I will object against a solution that causes existing code to be altered in any way, such as an extra hidden parameter for all callbacks. For the ISO ones, I don't think there is any other way of doing it. As long as it is restricted to those, there is no problem... If it would cause all types of proc. vars. (which is doesn't as far as I understand) it could be made mac mode only. It's both for now: a) it does not cause all procvars to become of this special type (only those whose type is fully declared inside a parameter list) b) it will only be available in MacPas mode Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On Mon, 14 Mar 2005, Florian Klaempfl wrote: Michael Van Canneyt wrote: I will object against a solution that causes existing code to be altered in any way, such as an extra hidden parameter for all callbacks. For the ISO ones, I don't think there is any other way of doing it. As long as it is restricted to those, there is no problem... If it would cause all types of proc. vars. (which is doesn't as far as I understand) it could be made mac mode only. As far as I understood it, it would only be for ISO type i.e. Function MyFunction (f : Func(X : Real) : Real) : Real; begin end; If this is so, there is no problem. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On Mon, 14 Mar 2005, Jonas Maebe wrote: On 14 mrt 2005, at 11:11, Michael Van Canneyt wrote: No, because normally, one never mixes 'procedure of object' with 'procedural'. You program either linear, either OOP, so you either use one or the other, never both. The distinction is also very clear. Except when programming a compiler, apparently :) Indeed :-) No, because in this case, you are comparing 2 basically different programming techniques: OOP and linear; they are fundamentally different in their practical use. With nested procedures, you are emulating parts of OOP using procedural programming. They were some form of OOP avant-la-lettre. That is a new definition :-) I don't see much code out there which mixes the two. (I'm talking 50-50%, not 99-1%) They all have their own uses. Absolutely. I agree 100%; for me, it depends on the project; where OOP is more useful, use OOP. Where procedural makes more sense: use procedural. I want to make clear that I am not against the concept an sich. If the compiler was born 'out of the blue', and it supported 'iso' procedures from the very start, the problem would not exist. All procedures (local and global) could be made 'iso-aware', and you would be able to pass both local and global functions for the same procedural parameter. Then you'd get problems with C callbacks... On top of all other things :-) The problem is that we are in the situation where the majority of existing code does not work like that, and that we have to introduce a 'schisma' in the compiler. I'm not particularly fond of this idea. The majority of existing code depends on whose code it is. Existing programs will not notice anything, for them declaring a procedural variable type in a parameter list will remain impossible. It's only for people using MacPas mode, who are used to these semantics, that things will change (or rather remain the same compared to other compilers). Macpas mode and iso callbacks: No problem... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 11:58, Michael Van Canneyt wrote: As far as I understood it, it would only be for ISO type i.e. Function MyFunction (f : Func(X : Real) : Real) : Real; begin end; If this is so, there is no problem. It is, and those ISO types are additionally only allowed in MacPas mode :) So people using FPC or Delphi mode can't even accidentally declare an ISO-style procvar parameter (for now at least, we could of course decide to allow it in some other modes as well). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local procedures as procedural parameter
On 14 mrt 2005, at 11:11, [EMAIL PROTECTED] wrote: I would only see the use of being able to pass a local function as a callback if the called function can be used for both local and global callback procedures. It can. When a global proc is passed, the static link is set to nil. That is not possible, because the static link parameter is currently passed as an implicit hidden *first* parameter. If you start passing an extra first parameter with the value nil to procedures, you'll get all sorts of strange effects. The PPC ABI actually prescribes that the static link parameter should always be passed in r11 (which can never be used for any other parameter, since regular parameters stop at r10), so then this works. However, in that respect we don't follow the PPC ABI, and it would also break on other processors so that's not an option. I agree. As little ABI dependancy as possible. The only possibility I see for this is to make the hidden static link parameter the last instead of the first parameter. What I was thinking of was to check for nil, when the procedure parameter is about to be called. If the static link is nil, it is a global proc, and it is called as such, if not nil it is called as a local proc. But this mean there must be two separate code chuncks which sets up the parameters, since for the local variant the first must be the static link. Example Powerpc with static link first: local static link r3 param no 1 r4 ... global param no 1 r3 ... To avoid this problem, it would be better to have the static link last. For an ABI which passes everything on the stack this would not have been any problem since paremeters are just pushed to the stack, and the push instructions is relative. Perhaps Wirth did have this kinds of architectures in mind when designing Pascal. Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Create installer for MacOSX
On 14 Mar 2005, at 22:40, Vincent Snijders wrote: I want to create a lazarus installer package for darwin (MacOSX). What tool should I use to create such a package? What tool does fpc use for packaging the compiler for MacOSX? I saw on sourceforge the MacOSX package is a .dmg file. How is that package created? make dmg in the fpc dir? No, manually. Creating a disk image is possible using command line tools, but creating an installer package isn't for some reason. You have to use /Developer/Applications/Utilities/PackageMaker for that. To create a disk image, either use Disk Utility or hdiutil create -imagekey zlib-level=9 -format UDZO -srcfolder srcfolder outputfile Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Create installer for MacOSX
Jonas Maebe wrote: Vincent Snijders wrote: I want to create a lazarus installer package for darwin (MacOSX). What tool should I use to create such a package? What tool does fpc use for packaging the compiler for MacOSX? I saw on sourceforge the MacOSX package is a .dmg file. How is that package created? make dmg in the fpc dir? No, manually. Creating a disk image is possible using command line tools, but creating an installer package isn't for some reason. You have to use /Developer/Applications/Utilities/PackageMaker for that. PackageMaker is basically a GUI interface to pax, so it might be possible to create a Mac OS X installer package with command line tools. You would have to look at the file layout of a package by using PackageMaker first or by looking at an existing package. I didn't try this, it is just an idea. Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Daily Lazarus Snaps
Great!!! All in one! http://www.ca.freepascal.org/Lazarus/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] crt unit fix
There is a endian related bug in the crt unit, which breaks the
examples ex10 and ex11 of the crt docs. The following fixes the bug and
makes the code more obvious. I suggest to replace the following two
routines. Tested on Mac OS X. It fixes web bug 3788 (I submitted that
one) and 3391 as good as possible (submitted by coraxyn). Some small
editing corrections as well.
Procedure DoEmptyLine(y,xl,xh:Longint);
{
Write an empty line at row Y from column Xl to Xh. Memory is also
updated.
}
Var
len : Longint;
blank_with_attribute : TCharAttr;
Begin
ttyGotoXY(xl,y);
len:=xh-xl+1;
LineWrite(Space(len));
blank_with_attribute.ch:=' ';
blank_with_attribute.attr:=TextAttr;
FillWord(ConsoleBuf^[(y-1)*ScreenWidth+xl
-1],len,word(blank_with_attribute));
End;
Procedure ClrScr;
{
Clear the current window, and set the cursor on 1,1
}
Var
CY,i : Longint;
oldflush : boolean;
blank_with_attribute : TCharAttr;
Begin
{ See if color has changed }
if OldTextAttrTextAttr then
begin
i:=TextAttr;
TextAttr:=OldTextAttr;
ttyColor(i);
end;
oldflush:=ttySetFlush(Flushing);
if FullWin then
begin
if not OutputRedir then
ttySendStr(#27'[H'#27'[2J');
CurrX:=1;
CurrY:=1;
blank_with_attribute.ch := ' ';
blank_with_attribute.attr := TextAttr;
FillWord(ConsoleBuf^,ScreenWidth*ScreenHeight,word(blank_with_attribute)
);
end
else
begin
For Cy:=WinMinY To WinMaxY Do
DoEmptyLine(Cy,WinMinX,WinMaxX);
GoToXY(1,1);
end;
ttySetFlush(oldflush);
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
