1. My not-quite obsolete namespace parser
I've updated my namespace parser, you can find the link to it on my
web site.
My version of namespaces is quite different from what RDS has
implemented
in Eu 2.3, so I believe it will be useful to some people.
My version lets you include a file into seperate namespaces and have
them
be actually seperate. Also, you can "insert" a file into the current
file's
direct namespace. 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.
(My parser has one big bug: both the local and global are accessable in
a
named namespace. I'm fixing this right now, and also adding an
"insert file as namespace" which can be used to have the current buggy
behavior exhibited by "include file as namespace" right now. I'll send
and update when I have done this.)
jbrown
--
Faster than the email provider that you're using!
Soar with FastMail.FM! -> http://fastmail.fm
2. My not-quite obsolete namespace parser
I've updated my namespace parser, you can find the link to it on my
web site.
My version of namespaces is quite different from what RDS has
implemented
in Eu 2.3, so I believe it will be useful to some people.
My version lets you include a file into seperate namespaces and have
them
be actually seperate. Also, you can "insert" a file into the current
file's
direct namespace. 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.
(My parser has one big bug: both the local and global are accessable in
a
named namespace. I'm fixing this right now, and also adding an
"insert file as namespace" which can be used to have the current buggy
behavior exhibited by "include file as namespace" right now. I'll send
and update when I have done this.)
jbrown
--
Faster than the email provider that you're using!
Soar with FastMail.FM! -> http://fastmail.fm
3. Re: My not-quite obsolete namespace parser
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: My not-quite obsolete namespace parser
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
- Posted by euman at bellsouth.net
May 14, 2002
BIG-D tries to throw the BOSS a curve ball but "the BOSS" hits a home run
off it.....that is cool !
btw, thx for your info on the listview problem BIG-D..
Euman
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
> 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
6. Re: My not-quite obsolete namespace parser
On 0, Robert Craig <rds at RapidEuphoria.com> 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
No, that was my mistake. I believe that was a bug in the alpha? version
of
Eu 2.3, but it seems to work fine under my comp with the most recent
version.
However, I also found another bug:
(in /opt/linux, $EUDIR = /opt/euphoria, /opt/linux is a symlink to
$HOME/space)
if i put this in a.exu and run it
include get.e
include ../euphoria/include/get.e --really /opt/euphoria/include/get.e
works, but making a.exu
include ../euphoria/include/get.e
claims that "../euphoria/include/get.e" cannot be found when run.
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!
For my namespace parser, the first and third cases will fail like the
second,
unlike exu which lets them continue to run and reports no errors.
Also, if i create $HOME/euphoria/get.e and put in it
global atom foo
foo = 1
and make a.exu
include get.e
include ../euphoria/get.e --really $HOME/euphoria/get.e
? foo
I get an error saying foo has not been declared???
even if I make a.exu (which my parser does btw)
include /opt/euphoria/include/get.e
include /home/jbrown/euphoria/get.e
? foo
It still fails???
it seems clear to me that this is a bug.
jbrown
--
http://fastmail.fm - 100% lightning
7. Re: My not-quite obsolete namespace parser
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
8. Re: My not-quite obsolete namespace parser
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
9. Re: My not-quite obsolete namespace parser
Derek Parnell writes:
> can I suggest then a minor change to the documentation.
Thanks.
I'll improve the description for the next release.
> 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.
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. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: My not-quite obsolete namespace parser
On 0, irv at take.maxleft.com wrote:
> 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
>
Ugh! So that is a "feature". Well, I'll work on modifying my namespace
parser to fix it. Should only take a few minor modifications.
jbrown
--
http://fastmail.fm
Any faster and it wouldn't be e-mail!
