Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Michael Van Canneyt
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;

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Michael Van Canneyt
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread olle . r
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 :

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Marco van de Voort
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread olle . r
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread olle . r
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread olle . r
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Florian Klaempfl
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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,

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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,

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Michael Van Canneyt
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Michael Van Canneyt
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.

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-14 Thread olle . r
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

Re: [fpc-devel] Create installer for MacOSX

2005-03-14 Thread Jonas Maebe
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

Re: [fpc-devel] Create installer for MacOSX

2005-03-14 Thread Adriaan van Os
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

[fpc-devel] Daily Lazarus Snaps

2005-03-14 Thread rstar
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

2005-03-14 Thread Dr. Karl-Michael Schindler
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