1. RE: My not-quite obsolete namespace parser
Robert Craig wrote:
> jbrown writes:
> > ... Finally, my version fixes a bug which RDS still has:
> >
> > include ./eufile.e
> > include eufile.e
> >
> > are 2 seperate files for RDS, but my parser sees
> > them as one and the same.
>
> In Euphoria, if you include the same file twice,
> the second include statement is quietly ignored.
> I tried your example above, in both DOS and Linux,
> and it worked fine. I'm not sure what you consider to
> be a bug.
>
Robert,
try this:
In file 'a.e' enter these three lines...
global myval
myval = 1
? 1
In the file 'b.ex' enter these two lines...
include ./a.e
include a.e
Now execute b.ex. When I do this I get ...
1
1
2. RE: My not-quite obsolete namespace parser
Robert Craig wrote:
> Derek Parnell writes:
> > In file 'a.e' enter these three lines...
> >
> > global myval
> > myval = 1
> > ? 1
> >
> > In the file 'b.ex' enter these two lines...
> >
> > include ./a.e
> > include a.e
> >
> > Now execute b.ex. When I do this I get ...
> >
> > 1
> > 1
>
> If I correct "global myval" to "global integer myval",
> and I correct "./a.e" to ".\a.e", then
> it correctly prints a single "1" on DOS or Windows.
>
> Or if I use "./a.e" on Linux or FreeBSD it also
> correctly prints a single "1".
>
> Euphoria assumes "\" in file paths on DOS and Windows,
> and "/" and Linux and FreeBSD. If you have something else
> it just passes it through to the O/S. It looks like DOS and Windows
> will accept "/" in some cases (but not all).
> Linux and FreeBSD never accept "\".
I humbly apologise. I can now see that this is a feature and not a bug.
At the MS-DOS prompt when I type:
type ./b.ex
I get the message:
G:\MYDOCS~1>type ./b.ex
The syntax of the command is incorrect.
Then I enter :
type "./b.ex"
and I get ...
G:\MYDOCS~1>type "./b.ex"
include .\a.e
include ..\mydocs~\a.e
So it would seem that DOS accepts either type of 'slash' symbol when it
is is clearly a part of the file-path string.
On this basis, it could be argued that Euphoria is not compliant with
MS-DOS systems. However, I *would *never *say *that, because Euphoria is
perfect in every way 
------------
Derek.
3. RE: My not-quite obsolete namespace parser
Robert Craig wrote:
> jbrown writes:
> > In fact, when I make it
> >
> > include get.e
> > include ../euphoria/get.e --really /opt/euphoria/get.e
> >
> > it still runs, despite the fact that ../euphoria/get.e does not exist!
>
> >From REFMAN:
> > ... an include statement will be quietly ignored if a file with
> > the same name has already been included.
>
> That means your second include is ignored because it
> is trying to include a file with the name "get.e", and "get.e"
> has already been included. The second get.e doesn't exist,
> but Euphoria doesn't try to open it.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
Robert,
can I suggest then a minor change to the documentation. Currently it
reads ...
include filename
. . . <big snip>
...an include statement will be quietly ignored if a file with
the same name has already been included.
There appears to be a slight ambiguity. Namely that "include filename"
seems to imply that the phrase 'filename' actually means "optional
file-path concatenated with a file-name". eg. mydir\xyz.e
Now further into this section we find the phrase "file name" where that
literally means the name of a file (excluding any path information).
I could be argued that some people (eg myself) might confuse the two
very similar terms, and wrongly assume that ...
include dir1\abc.e
include dir2\abc.e
would actually include two distinct files (because that's what they are)
that coincidently had the same name . However, as you have explained
(and I just tested), Euphoria only looks at the FILE NAME part of the
include statement to determine if a file has been included or not.
On the other hand, you could just change Euphoria to do the obvious,
that is use the entire normalized path-file-name to detect duplicate
include references, just like all other languages do.
------------
Derek.
4. RE: My not-quite obsolete namespace parser
Regardless of whether it's an intended 'feature', or a bug, it's a
problem.
What is the reason that eu DOS/WIN can't use '/' just the same as '\'?
I prefer to use '/' so I don't have to change my code when I take it to
linux.
It seems silly to me to force developers to use the DOS convention,
especially considering '\' is already used in eu as the switch char.
If ANYTHING, it should only allow '/', to maintain a cross platform
standard.
Chris
Robert Craig wrote:
> Derek Parnell writes:
> > In file 'a.e' enter these three lines...
> >
> > global myval
> > myval = 1
> > ? 1
> >
> > In the file 'b.ex' enter these two lines...
> >
> > include ./a.e
> > include a.e
> >
> > Now execute b.ex. When I do this I get ...
> >
> > 1
> > 1
>
> If I correct "global myval" to "global integer myval",
> and I correct "./a.e" to ".\a.e", then
> it correctly prints a single "1" on DOS or Windows.
>
> Or if I use "./a.e" on Linux or FreeBSD it also
> correctly prints a single "1".
>
> Euphoria assumes "\" in file paths on DOS and Windows,
> and "/" and Linux and FreeBSD. If you have something else
> it just passes it through to the O/S. It looks like DOS and Windows
> will accept "/" in some cases (but not all).
> Linux and FreeBSD never accept "\".
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
5. RE: My not-quite obsolete namespace parser
You didn't explain why / is recognized as being different, when the
meaing is clearly the same thing. I understand the logic for
differentiating bewteen the two. If that is going to be done, it should
be enforced, not quietly allowed, but not fully supported, what's the
deal with that? It seems irratic to me.
You mention the suppression of duplicate includes, but the behaviour is
inconsistent.
For over a year now it has never even crossed my mind that I shouldn't
be using /. Eu doesn't complain, or even warn me that it will be
evaluated as a separate include. Instead I spent days trying to figure
out where my code was broken. For a long time I thought I just couldn't
use relative paths.
Even upon mentioning the problem on the list numerous times, noone
answered my dilemna.
What ambiguities? When eu encounters include, and the platforn is not
LNX, either allow only \, or convert / to \.
I wouldn't care if the support for / were removed, except that it would
break code. The other option is to make the behavoiur consistent, which
wouldn't break any code, and would be alot less confusing.
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > What is the reason that eu DOS/WIN can't use '/' just the same as '\'?
>
> In general, you *can* use '/' just the same as '\', even
> though it is clearly not the convention on DOS or Windows.
>
> The thing we are quibbling about here,
> is the suppression of duplicate include files,
> where you should use the standard '\'
> on DOS/Windows to avoid ambiguities
> in rare situations, e.g. .\foo.e will look like
> the same file as foo.e and won't be included,
> but ./foo.e will look like a different file and will be included.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
6. RE: My not-quite obsolete namespace parser
Robert Craig wrote:
>
> C and C++ and probably most others
> don't detect duplicate include references at all.
> You just get an avalanche of "attempt to redefine ..." messages.
> C/C++ programmers have to set up elaborate systems
> of kludgy #ifdef's to avoid redefining stuff. Bjarne Stroustrup
> has admitted that this is a flaw in the C/C++ include file mechanism.
>
> I'm content with the current way of handling duplicate includes.
> It's been that way for 9 years and I don't recall anyone complaining
> about it. There aren't many other features with as clean a record. 
As I've written before, Euphoria is perfect already
As a philosophical diversion:
Are two files the same if their names are the same or if their contents
are the same?
-----------
Derek
7. RE: My not-quite obsolete namespace parser
- Posted by irv at take.maxleft.com
May 15, 2002
Derek Parnell wrote:
> Robert Craig wrote:
> > I'm content with the current way of handling duplicate includes.
> > It's been that way for 9 years and I don't recall anyone complaining
> > about it. There aren't many other features with as clean a record.
>
> As I've written before, Euphoria is perfect already
>
> As a philosophical diversion:
> Are two files the same if their names are the same or if their contents
> are the same?
>
> -----------
> Derek
Despite what Rob said earlier, Euphoria's namespacing
doesn't work as well as C, Pascal, etc. It doesn't work
as a normal programmer (if there is such a thing) would
expect.
A simple example in C:
/* Contents of main.c */
#include "./misc.c"
#include "./gtk/misc.c"
int main()
{
foo();
bar();
return 0;
}
/* Contents of misc.c */
void foo()
{
printf("Foo\n");
}
/* Contents of /gtk/misc.c */
void bar()
{
printf("Bar\n");
}
Save these three files, compile and execute.
[irv at localhost irv]$ ./main
Foo
Bar
Just what you'd expect, right?
Do the same thing in Euphoria, and you'll get an
error:
[irv@localhost irv]$ exu main
Foo
main.exu:5
bar has not been declared
bar()
^
Why hasn't bar() been declared?
Because to Euphoria, ./misc.e and ./gtk/misc.e are
duplicates, even though the include name and file
content are different. Our only option is to re-name
one or the other. You can surely think of reasons why
this would be undesirable, especially if we want
to distribute programs using other peoples' includes.
I can see absolutely no reason that Euphoria should
function in this manner.
Regards,
Irv
8. RE: My not-quite obsolete namespace parser
irv at take.maxleft.com wrote:
>
> Derek Parnell wrote:
> > Robert Craig wrote:
>
> > > I'm content with the current way of handling duplicate includes.
> > > It's been that way for 9 years and I don't recall anyone complaining
> > > about it. There aren't many other features with as clean a record.
> >
> > As I've written before, Euphoria is perfect already
> >
> > As a philosophical diversion:
> > Are two files the same if their names are the same or if their contents
> > are the same?
> >
> > -----------
> > Derek
>
> Despite what Rob said earlier, Euphoria's namespacing
> doesn't work as well as C, Pascal, etc. It doesn't work
> as a normal programmer (if there is such a thing) would
> expect.
<<code example SNIPPED>>
> Because to Euphoria, ./misc.e and ./gtk/misc.e are
> duplicates, even though the include name and file
> content are different. Our only option is to re-name
> one or the other. You can surely think of reasons why
> this would be undesirable, especially if we want
> to distribute programs using other peoples' includes.
>
> I can see absolutely no reason that Euphoria should
> function in this manner.
Hi Irv,
don't get me wrong - I'm with you on this one. RDS has got it wrong. RDS
was so concerned to get around the problem one has in C with duplicated
definitions that it also removed a perfectly valid use of same-named
files. IMHO the clear thing to do is to literally exclude truely
duplicated files rather than just files with the same name. If one then
goes and tries to 'trick' Euphoria by placing an include file into two
directories and attempting to 'include' both, then they'll get what they
deserve. This is the same as copying an include file to a new file with
a different name and including both.
The way I assumed that RDS was doing it was to fully normalize the
file's path and file name, and treating '\' and '/' as the same
character. Then you could compare two file-path-name strings for
duplications.
Of course, another way would be just to allow duplicate file references
and issue warnings about any duplicated global identifiers while
otherwise ignoring them.
------------
Derek.
9. RE: My not-quite obsolete namespace parser
- Posted by irv at take.maxleft.com
May 16, 2002
Derek Parnell wrote:
> Hi Irv,
> don't get me wrong - I'm with you on this one. RDS has got it wrong. RDS
>
> was so concerned to get around the problem one has in C with duplicated
> definitions that it also removed a perfectly valid use of same-named
> files.
Exactly. And if someone *did* include the same file
twice, what's the harm?
Suppose that foo.e is a copy of bar.e. With ver. 2.3,
you can include both without *any* warnings or
problems. You can even have global variables with
the same name in each, but with different types,
still no problems.
Only when you try to reference a global from your
main program does Euphoria give an error -
'a namespace qualifier is needed to resolve' the variable
or function being referenced. IOW, it's asking
"Which x are you talking about here?"
Since you are writing the program which uses those two
files, you are fully able to answer that question,
and so where's the harm? There's not any. It would be
nice if Euphoria was a bit more helpful, for example,
the error message read:
"global integer x in foo.e"
"global sequence x in bar.e"
"please qualify one or both include files"
That would be *much* better than just quietly 'forgetting'
an entire file just because it happens to have the same
base name as another file.
