Hi all,

Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)?

Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both.

TIA.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bee wrote

Hi all, Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)?

No.

Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them

Use an underscore.

Michael.

Bee wrote

Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)?

Probably not. And if at all, it wouldn't accomplish what you want to do.

Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both.

Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for.

Vinzent.

I think the dot is used in the grammar.
for example :

unit foo;
interface
procedure Print;
implementation
[...]
end.

You want to be able to call foo.Print; and you can not make the difference between a dot for the filename and a dot as a separator.

Probably not. And if at all, it wouldn't accomplish what you want to do.

If someone would provide a patch for this, is it gonna be accepted? If not, may I know what the reason(s)? ;)

Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for.

For some reasons, sometimes version control is too bloated, especially when the project is not too big. Nevertheless, it's the easiest way to have "manual" version control. :D

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

I think the dot is used in the grammar.

I understand.

You want to be able to call foo.Print; and you can not make the difference between a dot for the filename and a dot as a separator.

I believe the compiler has some kind of unit list. Compiler should know the difference using some kind of specific logic.

I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :(

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bee wrote

> Probably not. And if at all, it wouldn't accomplish what you want to do. If someone would provide a patch for this, is it gonna be accepted? If not, may I know what the reason(s)? ;)

unit_name.function (....) ...
...

How would you coap with this situation if you'll have "." inside ? You can translate it into "_", yes, or you can just use underscore at the file name at the first place...

Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language...

Ido

Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)?

I think more interesting are dots in unit name for making better namespaces. If I have a class called TSpecialButton, I want a unit name like "Michael.GUI.Buttons.TSpecialButton".

Or is there an other way to make namespaces like this?

Micha

Bee wrote

For some reasons, sometimes version control is too bloated, especially when the project is not too big.

I used RCS on 2K SLOC projects years ago already and never found it to be "too bloated". No, I could actually look at the change log and diffs from weeks ago and see why the code was broken now.

Nevertheless, it's the easiest way to have "manual" version control. :D

And about the most error-prone. Believe me, I speak from experience.

One of my co-workers used "manual" version control by renaming and moving files around (and even now his code is on SVN, he still does it - bad habits die hard, I guess).
No joke, but there was not one single version he had given me as "the latest" which actually matched his "tested" development copy. Despite all his effort[1], there were always "differences" and "bugs he already fixed" appearing at the beta test site once I installed "the exact same copy" of his development tree from his PC.

Vinzent.

[1] I'd rather be lazy than spending hours and hours finding out what the hell went wrong. After all, my laziness lend me to believe that software developer is the right profession for me. And so far, it worked out for me. :)

Bee wrote

I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :(

No offense, but maybe this is a good time to start becoming a serious developer now?

Vinzent.

Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language...

Feature is feature, you may use it, if you like, you may not, if you don't. Doesn't need to make yourself got complicated. ;)

It's like the '='. It does not always mean 'equal' as you have to use it on type declaration *and* comparison. It's like the 'end'. It does not always need to have 'begin' since 'case' and 'try' can also have an 'end'. Etc. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Actually, I'm thinking "child units".

"Namespaces" don't even have the appropriate scoping rules. The Java language's package is a perfect example for that: No matter where you put the class, it only sees it's own package. There they missed a perfect opportunity to enforce scoping rules with the compiler instead of letting the programmer decide it all over again just like they did back in the 70s, where all programs were written in FORTRAN and never crossed the 1023 lines of code boundary. ;)

Vinzent.

No offense, but maybe this is a good time to start becoming a serious developer now?

No offense, but maybe this is a good time to start providing a serious namespace to FPC now? ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Use an underscore.

Ok, I need to learn a new habit then. I can live with that. Thanks, Michael. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

I think you are missing the point. Bee may indeed be misguided, but the feature is in Delphi[.Net] in general. It is used to implement Namespaces - something sadly lacking in the FPC dialect of Pascal. Maybe it is time *you* embraced modern programming techniques? I, for one, would rate Namespaces over templates and generics. I use them daily. Give me partial classes too (i.e. OO modular design.)

M

Bee wrote

> Use an underscore. Ok, I need to learn a new habit then. I can live with that. Thanks, Michael. :)

For clarity: I am not against this dot by itself. I can only assure you, if implemented, that it will not end up in 2.2.2.

As for implementing this feature: this is not so trivial as one might think.

1. The parser needs changing. That's probably the easy part.

2. Symbol lookups need changing. This is the hard part, because you must be able to handle correctly unitname.identifier.identifier2.identifier3

It doesn't take a lot of intelligence to see that if unitname can containe one (or more) dots, this mechanism becomes suddenly a lot harder because your unitname may, by accident, match unitname.identifier1 of a symbol in another unit.

And doing all this in a way that doesn't change current behaviour... Not something you can do in a day, if you ask me.

Michael.

No, I don't.

Bee may indeed be misguided, but the feature is in Delphi[.Net] in general.

Screw Delphi. That "feature" was in ISO-standardized Ada back in 1995 already. And there it's called child units. Name spaces have too flat scoping rules to be really useful.

And yes, I'd like to have implemented that ("child units") in FPC.

But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered.

Vinzent.

ik wrote

Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language...

Think "records".

If you can have "unit.identifier.record_field" ad infinitum (any record may contain another record), it's not too far fetched to extend that concept to "unit.sub_unit. ...".

Vinzent.

> I think more interesting are dots in unit name for making better > namespaces. Actually, I'm thinking "child units".

You mean like in Ada? Yes, this would be great.
Are there any plans to implement this in future versions?

Micha

And yes, I'd like to have implemented that ("child units") in FPC.

What is child unit?

But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered.

It's alright. I can learn a new habit to use underscore instead of dot since today. Yes, bad habits die hard! :-D It just looks cool to see my unit like this: bee.buttons.myfancybutton; :-D

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Vinzent Hoefler wrote

But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered.

No problem, I just didn't get that from the glib "you should learn how to program" reply. My mistake.

I'm not an expert, the compiler is not my domain, but:

parser is in parser.pas
sym*.pas files contain the symbol handling.

Michael.

Maybe it is a good time for me to learn fpc compiler codes now. I never look inside them before, just the RTL and FCL. :-D

Can you show me which files I need to look and learn in order to have this feature? TIA.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

The more important: What would the user gain from it?

Other than being able to write "unit1" and "unit1.extension" instead of a "unit1" and "unit1_extension"?

As namespaces were thrown into the discussion: The same scoping rules would still apply, so it's merely a "writing" enhancement, nothing the compiler could check or would enforce.

So, as far as I am concerned, putting effort into the development of such flat namespaces - which, while enforced by the developer only, are already there, but using underscores instead of dots - gain zero points, so I would be against it.

This is just too much effort for pure syntactic sugar.

Vinzent.

That's not what I said. If at all I said "you should learn how to engineer software". That's quite a difference. ;)

Vinzent.

Well, the statements so far went like "this sub.sub.unit stuff is just .NET crap, we won't implement any of those". ;)

Vinzent.

The more important: What would the user gain from it?

I could gain my old bad habit again. LOL :-D

So, as far as I am concerned, putting effort into the development of such flat namespaces - which, while enforced by the developer only, are already there, but using underscores instead of dots - gain zero points, so I would be against it.

FPC core developers don't need to do this by themselves. Perhaps I'll do it to learn and understand fpc compiler codes, in my spare times of course. Just for learning, nothing serious. ;) I hope FPC will accept a patch for this feature if it is done.

This is just too much effort for pure syntactic sugar.

Sugar is sweet. Lots of people like sweet things. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bee wrote

> And yes, I'd like to have implemented that ("child units") in FPC. What is child unit?

http://www.adaic.com/docs/95style/html/sec_4/4-1-1.html

Well, the statements so far went like "this sub.sub.unit stuff is just .NET crap, we won't implement any of those". ;)

I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. If some of them are really good, then why not implement some of them in FPC too?

Like FPC supports the ugly '+=' C syntax. :-P Maybe it's a good feature for some 'lazy' programmers, but I personally don't like it. However, I'm not against it, because FPC doesn't force me to use that syntax. It's just a 'nice' feature to please some people. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Op Fri, 18 Jan 2008, schreef Bee:

Agreed, but, many things in .NET interfere with how things work in Pascal. The .NET way of modular programming is totally different compared with the Pascal unit system, therefore it would function as an "alien".

What should be done is, that if the .NET namespace stuff provides advantages, the Pascal unit system should be logically extended to provide such functionality, rather than duplicate the .NET way of modular programming.

I think this feature is mainly there for historical reasons. Long ago someone wanted the feature and did provide a patch. It was made disabled by default because of "uglyness". This is how things work in open source, if you write code, a lot is possible.

But, I never encounter code that uses this feature; it is the perfect example of how adding syntactic sugar can help the needs of just one man.

Daniël

Yeah, right. Nothing of that is new. It just wasn't hyped and backed by a big $ company before.

If some of them are really good, then why not implement some of them in FPC too?

*If*, yes.

Don't get me wrong, I am not against this syntax (on the contrary, I'm even a strong supporter for easily extensible units), but I am against the (so far) suggested semantics.

Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort.

Vinzent.

Agreed, but, many things in .NET interfere with how things work in Pascal. The .NET way of modular programming is totally different compared with the Pascal unit system, therefore it would function as an "alien".

I came from Delphi (my last Delphi is the Turbo Delphi) before I switch totally to FPC/Laz and Ubuntu. I must admit that Delphi way of thinking still affects me. I even still use it since FPC has very well compatibility with Delphi in Delphi mode.

Though I don't intend to use dot as namespace, but I disagree if it is totally an alien to pascal. Delphi does it very well on this. This fact alone is enough to show that pascal is quiet friendly to dot namespace. So, why FPC can't? At least by supporting it in Delphi mode.

What should be done is, that if the .NET namespace stuff provides advantages, the Pascal unit system should be logically extended to provide such functionality, rather than duplicate the .NET way of modular programming.

I don't use .Net, but supporting Delphi dot namespace doesn't need to stop providing other functionality. Ideally, we should able to provide them both, the Delphi way and the FPC way. Both are the most used pascal compiler nowadays. ;)

But, I never encounter code that uses this feature; it is the perfect example of how adding syntactic sugar can help the needs of just one man.

You never encounter it doesn't mean it never been used or it's only used by one man. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Op Fri, 18 Jan 2008, schreef Bee:

I don't use .Net, but supporting Delphi dot namespace doesn't need to stop providing other functionality. Ideally, we should able to provide them both, the Delphi way and the FPC way. Both are the most used pascal compiler nowadays. ;)

As far as I am concerned, there will be no "two ways" of doing things. It will only be confusing and makes the language needlessly baroque. Both compilers use the UCSD Pascal unit system, which, as of today is still one of the best modular programming systems. That is the base to start from.

But it does show such features are irrelevant to the project.

Daniël

Vinzent Hoefler wrote

On Friday 18 January 2008 12:35, Bee wrote: Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort.

And units are better because...?

I would take Namespaces over the crippled '80's unit notation any day. Units come from an age when filenames were limited to 8.3 format. Yes, we now have longer unit names, but Namespaces give context if nothing else.

Scoping is what you make of it. Java has Packages, C++ has Namespaces, C# has DotNet style Namespaces (not entirely the same thing.) I'd far rather have:

uses Windows.Win32.Standard, Windows.Win32.Messages;

than

uses Windows, Messages;

File names should have nothing to do with Namespaces too.

I'd also love:

unit Blah;
Namespace MyAPI.Blah;
interface
type
  TTest = partial class
      //non GUI code
   end;
implementation
end.

and then be allowed

unit Blah.GUI;
Namespace MyAPI.Blah;
interface
type
  TTest = partial class
      public
         //GUI code
   end;
implementation
end.

What is the difference ?
The second one saves on typing, which is a plus in my book ?

And how will you know which namespace is in what unit (or file) ?

You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO.

Michael.

I have added a missing word from that statement I think.

which, as of today is still one of the best modular programming systems. That is the base to start from.

No, no it is not one of the best modular programming systems. Not for OO related code. Love them or hate them, namespaces and partial classes are extremely useful..

You are right. The better way is "unit MyAPI.Blah;". The Namespace is the unit name.

g
Micha

I think if sb would waste time on it, and the patch is good quality it might be added. Not because it is a good feature (afaik it is not), but out of Delphi compat.

But, maybe you could enlighten me, what is exactly the needed functionality ?

Because how do you determine the difference

b.a.c.d (field d of class c in unit b.a)

and

b.a.c.d (field d of class c in class a in unit b)

What does Delphi/win32 really do with that? Does it more than simply ignoring parts of the name, and if so, what exactly? Could you make an overview of this feature?

And what is the use in your view?

Right.. confusion over verbosity. Given two units called "Constants.pas", which one is the correct unit? Given a unit called "Utils.pas" and one called "ExtraDefs.pas", both of which contain different implementations of the type TSocket, which is the correct unit to use?

Turning it on its head - file names should have nothing to do with unit names. The unit lives in a namespace, The namespace directive gives the path to the unit. so it would be:

unit Blah;
namespace MyAPI

and

uses MyAPI.Blah;

You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO

Nope.. see above.

Do you have a problem with partial classes? Also called "Categories" in Objective C.

But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name
It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace.

g
Micha

The filename would be "MyAPI.Blah.pas" as you indicate.

I think if sb would waste time on it, and the patch is good quality it might be added. Not because it is a good feature (afaik it is not), but out of Delphi compat.

Good or bad is relative. FPC is about development tool, each user has he's own good or bad way of programming. The more features it has, the better for the users. As I said, feature is feature, users may use it or not, it's absolutely up to him. So, it's all about Delphi compatibility. :)

Because how do you determine the difference b.a.c.d (field d of class c in unit b.a) and b.a.c.d (field d of class c in class a in unit b)

I know nothing about compiler. But in my simple way of thinking, the compiler should "remember" unit list.

- If "b.a.c" is declared within the uses clause then threat each "b.a.c" as a unit.
- If then in the unit body there is a "b" class/record that has an "a" property/subrecord that has a "c" record variable then compiler should raise an "ambiguous identifier" error.
- If compiler finds "b.a.d" then it raises "unknown identifier" error since there's no "b.a.d" unit is declared within uses clause.
- If there is no "b.a.c" in uses clause than threat "b" as an identifier.

Of course, this logic is far too simplified. :-D

What does Delphi/win32 really do with that? Does it more than simply ignoring parts of the name, and if so, what exactly? Could you make an overview of this feature?

I don't know how Delphi handle this internally. AFAIK, Delphi threats "b.a.c" as a unit if it's declared in the uses clause. Actually it is like the usual way Delphi threat units, but allows dot in the unit's file name. You can't use "a.c" and hope it will refers to "b". Use it all or use none. CMIIW. I didn't touch my Delphi in the last 6 months, I can be wrong or forget the detail of this feature. Somebody please confirm this.

And what is the use in your view?

I don't need (yet) namespace or whatever that is as in Delphi 2007, I just want to use dot in my unit's file name. Second, for Delphi compatibility. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

unit name = file name

That's it. It's enough for me. Let the dot as part of the file name. That's all. :-D

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

*Child* units are better, because they provide both _compiler checked_ namespaces and clearly defined visibility rules.

Namespaces don't. Namespaces are ugly C++ hacks from the time where the only namespace lied in the hope that a 6 letter identifier (where the first 2 letters were the initials of the programmer, two digits the project number and with the remaining two significant characters freely available to the programmer with the first one required to be an underscore[1]) would still link with the third party library from the vendor without having duplicate symbols to resolve.

Vinzent.

[1] All this naming convention may sound like a joke. Actually, it isn't.[2]
[2] It may be a bit exaggerated, though.

Bee wrote

The more features it has, the better for the users.

No. It's more like:

The nice thing about standards is that you have so many to choose from. -- Andrew S. Tanenbaum

(And yes, that was meant ironically.)

Vinzent.

Give two the same classes in the same namespace, which one is chosen?

Given a unit called "Utils.pas" and one called "ExtraDefs.pas", both of which contain different implementations of the type TSocket, which is the correct unit to use?

Utils.TSocket or ExtraDefs.TSocket.

That means either that you must scan all files in all dirs to build your state, or must register een unit (cq class) before using it, so that the compiler can limit the space. (this "registration" system can be a directory structure, but IMHO is replacing a fixed filename with a fixed dirname is no solution either)

This is exactly what the unit system was designed to avoid, central registries of units/classes. Under Java/.NET you need this because the JIT must be able to find them runtime too. With normal compilation this is a burden.

unit Blah; namespace MyAPI uses MyAPI.Blah;

And all this to avoid double unit names. Which is way less of a problem, since you have multiple classes in an unit (namespace) as a feature.

I don't like the concept, but for some workarounds it can be of some use in quick 'n dirty hacks. All in the case where you don't want to change libs as a temporary workaround (e.g. if they have to be revalidated with other apps then too)

However again, as far as I understand partial classes (Class Helpers in Delphi.NET), for this you need a registration system again because you need to compile all units that might use class X so that they auto import all units with classhelpers for unit X. (or you have to scan all directories on each compiler start, and must make 100% sure that you don't use units that don't have these class helpers added.

And if I import "blah" what would be imported? As far as I can see this is no real advantage, except allowing dots in unitnames.

Not really. In practice, you can compile a partial class without all of its parts and use it just fine. In the real world, this is extremely useful in sharing an engine between GUI systems (or a web application and a Console application) without pulling in specifics for the role implemented (GUI kits etc). It allows for a modular design (extensions at compile time.) It allows the programmer to create a flatter less complex hierarchy - e.g MVC in a single class, but with clear separation of responsibility.

In C#, Vs2005 always buts all of the GUI generation code in to a partial class called XXX.Designer.cs. This is an extreme improvement over the Pascal way.

An extention to this would be partial units (just invented this) which would allow the removal of the include files that dog FPC's RTL and support libs. All specific files could be organised in such a way that the include path found only the correct unit parts.

Yes, this is all a pipe dream, but dreaming is fun sometimes ;-)

M

No, you would import "MyAPI.Blah"...

I would say, remove "unit" replace with "Namespace" and all would be fine. Thinking about it, the Chrome dialect is a better model.

As far as I can see this is no real advantage, except allowing dots in unitnames.

That is what I want. :-)

Ok, the better way are child units, but the dots would be a nice feature.

g
Micha

If you request for features please come up with something realistic and also provide good information how it then should work. E.g. provide grammar how the syntax and semantics work. And if it is for compatibility you should also be able to provide real pascal examples that show how ambigious constructs are handled by Delphi.

So please answer first the question that Marco already wrote before continueing other discussions about this topic:

Take as example the reference to a.b.c.d.

- Can someone provide the grammar how an identifier looks like in Delphi?
- How shall the compiler detect that "a.b" is an unit if a is also defined as a record that doesn't contain a field b?
- How shall the compiler handle if "a.b.c" is an unit and a.b.c is class?

So please come with a design instead of just asking give me this feature in one line. Because if the feature was really important and simple it was for sure already implemented. The left over features are therefor not in the category simple anymore. Also important is debatable because we've already lived without them for years.

Peter

Well, that means you don't really have a namespace system, just dots in unitnames. Which is IMHO something totally different.

I would say, remove "unit" replace with "Namespace" and all would be fine. Thinking about it, the Chrome dialect is a better model.

I haven't seen one shred of evidence yet for either of those statements.

More over it should map one to one to what Delphi does, since it is a compability item.

Also have a look at http://www.freepascal.org/faq.var#extensionselect for how to do file a proper proposal.

Matt Emson wrote

I would say, remove "unit" replace with "Namespace" and all would be fine.

And the same as before, just with a different syntax.

Vinzent.

Marco van de Voort wrote

More over it should map one to one to what Delphi does, since it is a compability item.

And then - IMO - it's useless and indeed ".NET crap". Not worth the trouble.

Vinzent.

If he said that, he is totally braindead and doesn't have a clue about what he is talking.

And also, ECO doesn't work on win32, it requires .NET :)

Michael.

Well, the discussion and explanation that have been provided so far, back up that braindead guy's statement.

Vinzent.

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.

and

unit x;
interface
type
   sometype3 = record
         d: sometype3;
         end;
   sometype2 = record
         c: sometype3;
         end;
   sometype = record
         b: sometype2;
         end;
var
  a: sometype;

unit test; interface

  uses a.b.c,x;

This one shows that simply treating "a.b.c" as identifier _IF_ it is in the uses clause also is ambiguous.

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.

Daniël

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.

Michael.

Op Fri, 18 Jan 2008, schreef Michael Van Canneyt:

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

The magic word would be "scope" here. It's the same as with using two different units including the same identifier twice.

In Ada, you have to explicitely resolve the ambiguity by specifying the full name, in Pascal the last encountered scope counts, so in your example:

[...]

the variable A would take precedence (as you've stated).

Correct.

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 ?

Running up the scope until the identifier is either found or not.

Same with:

---
unit

   A;

var
C : ...
D : ...
---

---
function Blubb;
   A : Record_Type;
begin
   A.D :=
   A.C :=
end
---

AFAIK this would be perfectly compilable already. (I'm in a hurry right now, but I guess, you catch my drift.)

Vinzent.

Why? It would be in the uses clause, not in the declaration part. So it's not "declaring" the same identifier twice.

Vinzent.

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.

-----------------------------------

unit a;
interface
Var
  D : Integer;
implementation
end.
-----------------------------------
unit b;
interface
uses a;
Type
  T = Record
    C : integer;
  end;
Implementation
Procedure Doit;
Var
 A : T;
begin
  A.C:=1;
  A.D:=2;
end;
end.
-----------------------------------

Michael.

Try adding the same unit to the uses clause twice (or even in implementation/interface uses clauses).

You'll get a nice error message, for the same reason as the rest: scope would be ambiguous.

Michael.

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).

So that would change the whole importing behaviour. The only solution would be to only allow qualified identifiers and qualified import.

Op Fri, 18 Jan 2008, schreef Vinzent Hoefler:

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).

Daniël

We already print fully qualified identifiers in some error messages in case confusion is possible (e.g. unit1.type1 expected, but got unit2.type1).

Jonas

PS: could you configure your mail client so it inserts an attribution line at the top? (it's hard to follow who wrote what)

If you request for features please come up with something realistic and also provide good information how it then should work. E.g. provide grammar how the syntax and semantics work. And if it is for compatibility you should also be able to provide real pascal examples that show how ambigious constructs are handled by Delphi.

I was just asking why FPC can't compile a unit that has dot(s) within its file name, since Delphi allows it. I know nothing about compiler so I can't provide enough informations how it should work. If it's too much, then forget it... I can live happily with current FPC.

So please come with a design instead of just asking give me this feature in one line. Because if the feature was really important and simple it was for sure already implemented.

The discussion goes wider to namespace and (Delphi).Net features. I didn't intend to go that far. I don't even know what namespace exactly is, let alone use it. I just want to have dot(s) within my unit's file name. That's all. If it's too much, then forget it... I can live happily with current FPC. As Michael suggested, I would change the dot to underscore. Fine.

Also important is debatable because we've already lived without them for years.

Ah, you should throw away your car, your cellphone, or even your laptop. Those are not important, because humans had already lived happily without them for ages! :-P

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

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.

Op Fri, 18 Jan 2008, schreef Vinzent Höfler:

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

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.

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.)

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.

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.

-----Mensagem original-----
De:
Em nome de Marco van de
Voort
Enviada em: sexta-feira, 18 de janeiro de 2008 06:05 Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] dot within unit file name

- Can someone provide the grammar how an identifier looks like in Delphi? - How shall the compiler detect that "a.b" is an unit if a is also defined

as a record that

doesn't contain a field b? - How shall the compiler handle if "a.b.c" is an unit and a.b.c is class? So please come with a design instead of just asking give me this feature

in one line. Because if

the feature was really important and simple it was for sure already

implemented. The left over

features are therefor not in the category simple anymore. Also important

is debatable because

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. I think is some talk about import ECO objects.

[]s

Cesar Romero

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.6/1230 - Release Date: 17/01/2008 16:59

> - Can someone provide the grammar how an identifier looks like in

Delphi?

> - How shall the compiler detect that "a.b" is an unit if a is also

defined

as a record that > doesn't contain a field b? > - How shall the compiler handle if "a.b.c" is an unit and a.b.c is

class?

for

If he said that, he is totally braindead and doesn't have a clue about what he is talking.

And also, ECO doesn't work on win32, it requires .NET :)

Michael.

I found the thread, and it was a comment about tiburon and circular reference, the guy seems to be a Capable object person, and he comments that in .NET is NameSpace and in Win32 is only unit names.

[]s

Cesar Romero

Bee wrote

> Well, the statements so far went like "this sub.sub.unit stuff is > just .NET crap, we won't implement any of those". ;)

[snip]

Good one Bee! That's a good argument. The '+=' is totally C syntax, but like you say, we as developers can decide if we want to use it or not.

As for the extra dots in unit names... If somebody wants do take up the challenge and implement it, I say go for it. I personally can't see me ever using it, but it will at least give developers the choice.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

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

On Friday 18 January 2008 20:12, John Stoneham wrote:

[Ada package system]

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.