Re: RES: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 20:12, John Stoneham wrote: [Ada package system] However, you can also do: with Unit_1; use Unit_1; This imports the namespace of Unit_1 into the current file so that now you *can* refernce foo without a qualifier. It's as if all the identifiers in Unit_1 were defined in the current file (and so yes, you can get conflicts). Yes, and that's what uses Unit_1; in Pascal does. The only difference between Pascal and Ada is that Ada complains about ambiguities (same identifier in different modules) while Pascal's scope model just uses the identifier from the last used module (while you're still able to overwrite that behaviour by prefixing the identifier just like you're required to do in Ada in case of ambiguities). So, the only difference is that Ada plays it safe and complains about ambiguities while a Pascal compiler tries to resolve the ambiguity by itself (and sometimes fails in a horrible way - I still remember the issue I once had, when I just reordered the used units and without changing any code, the application suddenly started crashing, because it used a different DisposeStr then. BTW, that's one of the reasons why I always use prefixed notation in Pascal now, just like I do in Ada). (As written before, this explanation is more from a user's point of view than from the view of a compiler writer.) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Jonas wrote: The magic word would be scope here. It's the same as with using two different units including the same identifier twice. Yes and no, of course it will work, but might be counterintuitive. uses x, a.b.c; a.b.c.d. if x also contains an identifier a. error : a.b.c.d identifier not found. (but a.b.c.d exists). We already print fully qualified identifiers in some error messages in case confusion is possible (e.g. unit1.type1 expected, but got unit2.type1). True, but this is different. To know the cause you have to search further than the first hit, not just detect a mismatch. PS: could you configure your mail client so it inserts an attribution line at the top? (it's hard to follow who wrote what) Phew. elmrc is not my favorite, but I'll try to look into it tomorrow ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: On Fri, 18 Jan 2008, Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: Well, with normal Pascal rules, you cannot declare a variable with the same name as a unit you use, because a unit is also an identifier. Most logical would be to reject the declaration of variable A in this case due to a duplicate identifier. No, because the unit identifier is a.b.c, not a. It has to be, otherwise units windows.messages and windows.records would both have identifier windows, leading to an error. You are right. In other words, .NET namespaces cannot be unified with normal scoping rules, meaning you would need a new set of scoping rules and mark the old ones legacy. Not acceptable. I have made my conclusion: No .NET namespaces and no dots in names. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Vinzent Hoefler: On Friday 18 January 2008 16:04, Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: Well, with normal Pascal rules, you cannot declare a variable with the same name as a unit you use, because a unit is also an identifier. Most logical would be to reject the declaration of variable A in this case due to a duplicate identifier. No, because the unit identifier is a.b.c, not a. It has to be, otherwise units windows.messages and windows.records would both have identifier windows, leading to an error. Why? It would be in the uses clause, not in the declaration part. So it's not declaring the same identifier twice. Search for unit identifier in TP/Delphi books. uses x declares x as unit identififier in the symtable of the current program/unit. So, it is declared twice (with reason). Well, but at that time there would be no confusion between a Windows.Messages and Windows.Constants. Both have to be units at that point. Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
On 1/18/08, Vinzent Höfler [EMAIL PROTECTED] wrote: On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. In Ada the fully qualified name of the variable would be A.A here. I certainly see the problems for the (Pascal) compiler write here, but from a user's point of view this identifier is in no way different than SysUtils.Sleep. Ada really does have an extremely well-defined and flexible package/module system with the ability to define child packages, which are conceptually identical to nestes packages/units. But there are actually two keywords to handle modules and namespaces in Ada: with and use. When you with a module, you make it's identifiers accessible to the current file, but only in a qualified manner: you have to use dot notation for everything. So if you: with Unit_1; you have to use: Unit_1.foo; to access foo from Unit_1. If you try to access foo without the qualifier, you get compile errors because foo is unkown, only Unit_1.foo is known. However, you can also do: with Unit_1; use Unit_1; This imports the namespace of Unit_1 into the current file so that now you *can* refernce foo without a qualifier. It's as if all the identifiers in Unit_1 were defined in the current file (and so yes, you can get conflicts). To accomplish the same type module system that Ada has would require at least another keyword (e.g. with) in addition to uses, and the grammar would have to allow defining nested/child units. But then Pascal would basically become Ada95. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
On Fri, 18 Jan 2008, Vinzent Hoefler wrote: On Friday 18 January 2008 15:19, Michael Van Canneyt wrote: I saw this week a CodeGear Guy in a cg ng talking about that. In Win32 its is Just dots in the name, nothing else. If he said that, he is totally braindead and doesn't have a clue about what he is talking. Well, the discussion and explanation that have been provided so far, back up that braindead guy's statement. Of course not: tell me, what does a.b.c.d mean if you have a record a with field b, and you have a uses a.b.c in your uses clause ? so unit a.b.c; interface Var D : Integer; implementation end. and then: unit test; interface uses a.b.c; Type T = record b : integer; end; Implementation var A : T; begin A.b.c.d:=3;// ??? end. To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: 1. Scoping rules dictate that the first match is the variable a. So, it finds a as a variable. 2. then it finds b in the fields of T. OK, it's on the right track! 3. But then it looks for C, but doesn't find it - error, what now ? nevertheless (a.b.c).d would be a correct reference to integer d in unit a.b.c (the brackets serve just to make a point, they are not real notation). So, what to do ? Throw an error, or set d in unit a.b.c. ? And what about searching for (a).b.c.d and (a.b).c.d ? What combinations of dots and brackets must be tried ? (namespaces could also be a and a.b) Maybe someone with delphi for .net available can run the above test ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Vinzent Höfler: Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- There is fundamental problem which such a construct even using normal Pascal scoping rules. The identifier test in this case, is in the symtable of procedure B, which is a deeper lexical level, thus can hide global identifiers. Yes. That's precisely why in Ada you have to write Test.X to go up that lexical level. The hiding happens here, too - but you have the possibility to explicitely override it. (Let's put aside the fact, that such constructs are usually bad coding style.) On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. In Ada the fully qualified name of the variable would be A.A here. I certainly see the problems for the (Pascal) compiler write here, but from a user's point of view this identifier is in no way different than SysUtils.Sleep. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Michael Van Canneyt wrote: You are wrong. It does not compile, neither in delphi, nor in FPC. D is not found, because 'A' resolves to the local a, and then the search is stopped. Ok, I think I got it. It's probably the same reason why in --- procedure Foo (const A : My_Type); overload; procedure Foo (const B : Some_Type); overload; procedure Bar; var A : My_Type; B : Some_Type; begin Foo (A); // works Foo (B); // works end; procedure Foobar; // declare Another_Type locally procedure Foo (const C : Another_Type); begin ... end; var A : My_Type; C : Another_Type; begin Foo (C); // works Foo (A); // wrong type! end; --- the last call does not work (unless I write unitname.Foo (A) there). BTW, the same happens with overloaded methods in classes when I try to extend the class: The overloaded methods of the parent class are suddenly not available anymore once I declare another overloaded method. This actually happened to me when I tried to extend the XMLConfig class for Double types. Once I declared SetValue (Double) in the derived class, I would have needed typecasts to access SetValue (Integer) and SetValue (String) in virtually every call. The other solution would have been to redeclare the overloaded methods in the derived class, I guess. Well, writing about all that, I come to the conclusion that the Pascal scoping rules can really suck from time to time. ;) No plan to change that, though, I suppose? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Vinzent Höfler: Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- There is fundamental problem which such a construct even using normal Pascal scoping rules. The identifier test in this case, is in the symtable of procedure B, which is a deeper lexical level, thus can hide global identifiers. On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
