1. A Problem with v2.4 (for Rob)
Hello again Rob,
While working with v2.4 i came upon a problem that has
quite profound consequences. The problem centers around
the new implementation of 'include as'.
--in file SomeoneElsesExistingFuncs.ew--------
procedure DoSomething()
?{1}
end procedure
-- and 100 other procedures already named.
----------------------------------------------
--in file MyNewFuncs.ew-----------------------
procedure DoSomething()
?{2}
end procedure
-- and 99 other procedures, a lot with the same
-- names as in SomeoneElsesExistingFuncs.ew
----------------------------------------------
-- MyNewFuncs.ew DoSomething() does something slightly different
-- then that which is in SomeoneElsesExistingFuncs.ew
-- all the following in file Test.exw ...
include SomeoneElsesExistingFuncs.ew
include MyNewFuncs.ew as MF
-------Someone elses existing .exw code section---------
DoSomething()
-- and call 100 other functions already named in
-- SomeoneElsesExistingFuncs.ew
---------------------------------------------------
-------My new code section (also in Text.exw)---------
MF:DoSomething() --<----flags a name qualifier required error.
-- and call 99 other functions already named in
-- both MyNewFuncs.ew
-------------------------------------------------------
The interpreter flags a name qualifier required error because
it doesnt see that "MF:DoSomething()" is different then simply
"DoSomething()". This is exactly the same as Euphoria 2.2.
This reduces the value of 'include as' in programming technique.
You should be able to block completely the new code so as to
provide perfect encapsulation without having to change
var names.
This means that either one of two things has to happen:
1. rename all the procedures in SomeoneElsesExistingFuncs.ew
2. rename all the procedures in MyNewFuncs.ew
Isnt this exactly the same as it was before v2.3 i think?
If someone wants to include a file both without a name qualifier
and with a name qualifier all they have to do is use the following
code:
include TheirFile.ew as TF
include TheirFile.ew
and that would acheive the same thing that exists now.
This means if the interpreter is changed to stop recognition
of globals in files that are exclusively included
with 'include as' then this default action can be turned on
or off by either using one line of code or two (as above).
This really has a big effect on what you can and cant write
when it might be used with other peoples include files.
Once this works it's going to be very useful. The impact
on the code that can be allowed will be incredible.
Take care for now,
Al
2. Re: A Problem with v2.4 (for Rob)
On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote:
>
> Hello again Rob,
>
> While working with v2.4 i came upon a problem that has
> quite profound consequences. The problem centers around
> the new implementation of 'include as'.
>
>
> --in file SomeoneElsesExistingFuncs.ew--------
> procedure DoSomething()
> ?{1}
> end procedure
> -- and 100 other procedures already named.
> ----------------------------------------------
>
> --in file MyNewFuncs.ew-----------------------
> procedure DoSomething()
> ?{2}
> end procedure
> -- and 99 other procedures, a lot with the same
> -- names as in SomeoneElsesExistingFuncs.ew
>
> ----------------------------------------------
>
> -- MyNewFuncs.ew DoSomething() does something slightly different
> -- then that which is in SomeoneElsesExistingFuncs.ew
>
>
> -- all the following in file Test.exw ...
>
> include SomeoneElsesExistingFuncs.ew
> include MyNewFuncs.ew as MF
>
>
> -------Someone elses existing .exw code section---------
> DoSomething()
> -- and call 100 other functions already named in
> -- SomeoneElsesExistingFuncs.ew
> ---------------------------------------------------
>
> -------My new code section (also in Text.exw)---------
> MF:DoSomething() --<----flags a name qualifier required error.
> -- and call 99 other functions already named in
> -- both MyNewFuncs.ew
> -------------------------------------------------------
>
> The interpreter flags a name qualifier required error because
> it doesnt see that "MF:DoSomething()" is different then simply
> "DoSomething()". This is exactly the same as Euphoria 2.2.
That is not quite what is happening. Euphoria sees "DoSomething()" so it
looks for a local routine with this name. If it can't find one, it looks
for a global routine with this name. In this case it finds two global
routines with this name. Now, which one did you actually mean to use? How
would Euphoria know? For example, if it assumes that because you didn't use
the namespace qualifier that it should use the routine in a file that
wasn't namespaced? Maybe, but that assumes you INTENDED to leave off the
namespace qualifier. Rather than second guess you, Euphoria raises an error
so that you can disambiguate the situation.
> This reduces the value of 'include as' in programming technique.
> You should be able to block completely the new code so as to
> provide perfect encapsulation without having to change
> var names.
You can - and using the current Euphoria.
> This means that either one of two things has to happen:
> 1. rename all the procedures in SomeoneElsesExistingFuncs.ew
> 2. rename all the procedures in MyNewFuncs.ew
Ah hah! There is a third alternative.
3. Add a namespace qualifier on the "include SomeoneElsesExistingFuncs.ew"
Exmaple:
include SomeoneElsesExistingFuncs.ew SE
include MyNewFuncs.ew as MF
-------Someone elses existing .exw code section---------
-- Explicitly tell Eu that you want somebody else's routine.
SE:DoSomething()
-- and call 100 other functions already named in
-- SomeoneElsesExistingFuncs.ew
---------------------------------------------------
-------My new code section (also in Text.exw)---------
-- Explicitly tell Eu that you want your routine.
MF:DoSomething()
> Isnt this exactly the same as it was before v2.3 i think?
>
> If someone wants to include a file both without a name qualifier
> and with a name qualifier all they have to do is use the following
> code:
> include TheirFile.ew as TF
> include TheirFile.ew
>
> and that would acheive the same thing that exists now.
Which is nothing. A file only gets included once - no matter how many times
you refer to it. In fact...
include TheirFile.ew as TF
include TheirFile.ew as YG
include TheirFile.ew as UH
just creates namespace aliases for the same file. In other words ...
TF:DoSomething()
YG:DoSomething()
UH:DoSomething()
all refer to exactly the same routine.
> This means if the interpreter is changed to stop recognition
> of globals in files that are exclusively included
> with 'include as' then this default action can be turned on
> or off by either using one line of code or two (as above).
I'm not sure what you are saying here. Are you saying ...
All globals defined in a file that has been included with the "as" phrase
must ONLY be referred to by using the namespace qualifier - and thus if a
symbol is not namespace-qualified in your code, Euphoria must not look in
files that were included with a namespace qualifier
> This really has a big effect on what you can and cant write
> when it might be used with other peoples include files.
>
> Once this works it's going to be very useful. The impact
> on the code that can be allowed will be incredible.
I agree that this would help your situation a lot. Maybe a warning might be
useful in case the coder just forgot to qualify a reference or two. It
would also potentially break existing code - but maybe not that much.
--
cheers,
Derek Parnell
3. Re: A Problem with v2.4 (for Rob)
Hello Derek, you wrote:
> On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote:
>
>>
>> Hello again Rob,
>>
>> While working with v2.4 i came upon a problem that has
>> quite profound consequences. The problem centers around
>> the new implementation of 'include as'.
>>
>>
>> --in file SomeoneElsesExistingFuncs.ew--------
>> procedure DoSomething()
>> ?{1}
>> end procedure
>> -- and 100 other procedures already named.
>> ----------------------------------------------
>>
>> --in file MyNewFuncs.ew-----------------------
>> procedure DoSomething()
>> ?{2}
>> end procedure
>> -- and 99 other procedures, a lot with the same
>> -- names as in SomeoneElsesExistingFuncs.ew
>>
>> ----------------------------------------------
>>
>> -- MyNewFuncs.ew DoSomething() does something slightly different
>> -- then that which is in SomeoneElsesExistingFuncs.ew
>>
>>
>> -- all the following in file Test.exw ...
>>
>> include SomeoneElsesExistingFuncs.ew
>> include MyNewFuncs.ew as MF
>>
>>
>> -------Someone elses existing .exw code section---------
>> DoSomething()
>> -- and call 100 other functions already named in
>> -- SomeoneElsesExistingFuncs.ew
>> ---------------------------------------------------
>>
>> -------My new code section (also in Text.exw)---------
>> MF:DoSomething() --<----flags a name qualifier required error.
>> -- and call 99 other functions already named in
>> -- both MyNewFuncs.ew
>> -------------------------------------------------------
>>
>> The interpreter flags a name qualifier required error because
>> it doesnt see that "MF:DoSomething()" is different then simply
>> "DoSomething()". This is exactly the same as Euphoria 2.2.
>
> That is not quite what is happening. Euphoria sees "DoSomething()" so it
> looks for a local routine with this name. If it can't find one, it looks
> for a global routine with this name. In this case it finds two global
> routines with this name.
Maybe I'm wrong, but in my understanding the two global routines have
*different* names: One name is 'DoSomething()', and the other name is
'MF:DoSomething()'.
> Now, which one did you actually mean to use? How
> would Euphoria know? For example, if it assumes that because you didn't use
> the namespace qualifier that it should use the routine in a file that
> wasn't namespaced?
Yes. Isn't this situation similar to that one, when you start a program
say 'myprog.exe' from the command line? If the program is in the current
directory or in a directory on the PATH, and you want to run this one,
you just have to type 'myprog.exe'. If you want to run another program
with this name in another directory that is not on the PATH, you can do
this by typing the full qualified name, e.g. 'C:\test\myprog.exe'.
> Maybe, but that assumes you INTENDED to leave off the
> namespace qualifier.
Yes.
> Rather than second guess you, Euphoria raises an error
> so that you can disambiguate the situation.
[big snip]
> Maybe a warning might be
> useful in case the coder just forgot to qualify a reference or two. It
> would also potentially break existing code - but maybe not that much.
Yes, IMHO a warning -- instead of an error -- would be the appropriate
reaction here (if it doesn't break too much existing code).
Best Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
4. Re: A Problem with v2.4 (for Rob)
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: A Problem with v2.4 (for Rob)
>
> Hello Derek, you wrote:
[snip]
> >
> > That is not quite what is happening. Euphoria sees "DoSomething()" so it
> > looks for a local routine with this name. If it can't find one, it looks
> > for a global routine with this name. In this case it finds two global
> > routines with this name.
>
> Maybe I'm wrong, but in my understanding the two global routines have
> *different* names: One name is 'DoSomething()', and the other name is
> 'MF:DoSomething()'.
Well if that was the case then Euphoria would not complain about having to
need a namespace to remove an ambiguous reference, because there would be no
ambiguous reference if they had different names.
> > Now, which one did you actually mean to use? How
> > would Euphoria know? For example, if it assumes that because you didn't
use
> > the namespace qualifier that it should use the routine in a file that
> > wasn't namespaced?
>
> Yes. Isn't this situation similar to that one, when you start a program
> say 'myprog.exe' from the command line? If the program is in the current
> directory or in a directory on the PATH, and you want to run this one,
> you just have to type 'myprog.exe'. If you want to run another program
> with this name in another directory that is not on the PATH, you can do
> this by typing the full qualified name, e.g. 'C:\test\myprog.exe'.
MS-DOS has built in rules about how to search for for program files. The
most important, in this context, is that it STOPS searching when it finds
one that matches the one you typed in. It does not find ALL possible
matching files then tries to decide which to run. Euphoria does look for all
matching ids.
> > Maybe, but that assumes you INTENDED to leave off the
> > namespace qualifier.
>
> Yes.
But how would Eu know that. You could have just forgotten to put it on.
----------------
cheers,
Derek Parnell
5. Re: A Problem with v2.4 (for Rob)
On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote:
Al, the example you gave worked fine, flagging the line of code in
your program which now needs a namespace qualifier. The following
shows how to get this problem in a way that would force you to edit
someone elses code:
--Someone else's code:
lib1.e is:
include subs1.e
d()
subs1.e is:
global procedure d() ?{1} end procedure
--Another persons code:
lib2.e is:
include subs2.e
d()
subs2.e is:
global procedure d() ?{2} end procedure
--Your code can then have all the namespace qualifiers you can shake a
--stick at, it will always bomb (even with your include twice idea):
include lib1.e as x
include lib2.e as y
What I think is needed is that if you are "inside" an include as
statement, then it should automatically select globals defined since
that "as" directive over any defined beforehand.
You would still have the task, when you have reams of existing,
non-namespace qualified code, of a global edit (which really you must
admit is not that difficult - I do it all the time. Maybe your editor
is not up to scratch - Try Meditor 
Pete
6. Re: A Problem with v2.4 (for Rob)
Hello Derek, you wrote:
> From: "Juergen Luethje" <j.lue at gmx.de>
>> Hello Derek, you wrote:
>
> [snip]
>
>>>
>>> That is not quite what is happening. Euphoria sees "DoSomething()" so it
>>> looks for a local routine with this name. If it can't find one, it looks
>>> for a global routine with this name. In this case it finds two global
>>> routines with this name.
>>
>> Maybe I'm wrong, but in my understanding the two global routines have
>> *different* names: One name is 'DoSomething()', and the other name is
>> 'MF:DoSomething()'.
>
> Well if that was the case then Euphoria would not complain about having to
> need a namespace to remove an ambiguous reference, because there would be no
> ambiguous reference if they had different names.
I meant: From a logical point of view, I regard 'DoSomething()' and
'MF:DoSomething()' as two different names. I know, that Euphoria can't
realize that at the moment, but I don't see any logical reason, why.
>>> Now, which one did you actually mean to use? How
>>> would Euphoria know? For example, if it assumes that because you didn't use
>>> the namespace qualifier that it should use the routine in a file that
>>> wasn't namespaced?
>>
>> Yes. Isn't this situation similar to that one, when you start a program
>> say 'myprog.exe' from the command line? If the program is in the current
>> directory or in a directory on the PATH, and you want to run this one,
>> you just have to type 'myprog.exe'. If you want to run another program
>> with this name in another directory that is not on the PATH, you can do
>> this by typing the full qualified name, e.g. 'C:\test\myprog.exe'.
>
> MS-DOS has built in rules about how to search for for program files. The
> most important, in this context, is that it STOPS searching when it finds
> one that matches the one you typed in. It does not find ALL possible
> matching files then tries to decide which to run. Euphoria does look for all
> matching ids.
Yes, of course. The idea only works, if there is not more that one of
those "critical" include files without a namespace identifier.
E.g. given 3 include files with identical code, using
include file1.e
include file2.e
include file3.e as i3
cannot work.
But using
include file1.e
include file2.e as i2
include file3.e as i3
should work, because any file has an unambiguous namespace. file1.e has
the namespace "" which is not nothing. Eu IMHO should be able to handle
that.
>>> Maybe, but that assumes you INTENDED to leave off the
>>> namespace qualifier.
>>
>> Yes.
>
> But how would Eu know that. You could have just forgotten to put it on.
Eu can't know that, unless Rob gives us a "do what I mean, not what I
say" (DWIM) interpreter.
There are many other situations, were Eu must rely on the assumption,
that what I wrote, was what I intended to write.
In contrast to Eu, I know what I want, and at the moment, Eu forces me
*unnecessarily* to write things, that I don't want.
Al already wrote in more detail about that in the meantime.
Best regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
7. Re: A Problem with v2.4 (for Rob)
In my namespace parser, when looking for "DoSomething", it would first look
at the local routines, then the global ones. If still no match, then it would
look at the namespaces, one-by-one, (in the order they were created) until it
found a match. If no match was found then it raised an error.
Note that my parser didn't raise an error if there were _2_ DoSomeThing's, since
it stopped after it had found _1_.
That is arguably a flaw, but perhaps not.
(I'm hinting at how the RDS version of namespaces could be improved, btw,
not at getting more people to use my namespace parser, in case you didn't get
that ... my parser was designed for Eu 2.2, pre-namespaces.)
jbrown
On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote:
>
> Hello Derek, you wrote:
>
> > From: "Juergen Luethje" <j.lue at gmx.de>
> >> Hello Derek, you wrote:
> >
> > [snip]
> >
> >>>
> >>> That is not quite what is happening. Euphoria sees "DoSomething()" so it
> >>> looks for a local routine with this name. If it can't find one, it looks
> >>> for a global routine with this name. In this case it finds two global
> >>> routines with this name.
> >>
> >> Maybe I'm wrong, but in my understanding the two global routines have
> >> *different* names: One name is 'DoSomething()', and the other name is
> >> 'MF:DoSomething()'.
> >
> > Well if that was the case then Euphoria would not complain about having to
> > need a namespace to remove an ambiguous reference, because there would be no
> > ambiguous reference if they had different names.
>
> I meant: From a logical point of view, I regard 'DoSomething()' and
> 'MF:DoSomething()' as two different names. I know, that Euphoria can't
> realize that at the moment, but I don't see any logical reason, why.
>
> >>> Now, which one did you actually mean to use? How
> >>> would Euphoria know? For example, if it assumes that because you didn't
> >>> use
> >>> the namespace qualifier that it should use the routine in a file that
> >>> wasn't namespaced?
> >>
> >> Yes. Isn't this situation similar to that one, when you start a program
> >> say 'myprog.exe' from the command line? If the program is in the current
> >> directory or in a directory on the PATH, and you want to run this one,
> >> you just have to type 'myprog.exe'. If you want to run another program
> >> with this name in another directory that is not on the PATH, you can do
> >> this by typing the full qualified name, e.g. 'C:\test\myprog.exe'.
> >
> > MS-DOS has built in rules about how to search for for program files. The
> > most important, in this context, is that it STOPS searching when it finds
> > one that matches the one you typed in. It does not find ALL possible
> > matching files then tries to decide which to run. Euphoria does look for all
> > matching ids.
>
> Yes, of course. The idea only works, if there is not more that one of
> those "critical" include files without a namespace identifier.
> E.g. given 3 include files with identical code, using
> include file1.e
> include file2.e
> include file3.e as i3
>
> cannot work.
> But using
> include file1.e
> include file2.e as i2
> include file3.e as i3
>
> should work, because any file has an unambiguous namespace. file1.e has
> the namespace "" which is not nothing. Eu IMHO should be able to handle
> that.
>
> >>> Maybe, but that assumes you INTENDED to leave off the
> >>> namespace qualifier.
> >>
> >> Yes.
> >
> > But how would Eu know that. You could have just forgotten to put it on.
>
> Eu can't know that, unless Rob gives us a "do what I mean, not what I
> say" (DWIM) interpreter.
> There are many other situations, were Eu must rely on the assumption,
> that what I wrote, was what I intended to write.
> In contrast to Eu, I know what I want, and at the moment, Eu forces me
> *unnecessarily* to write things, that I don't want.
> Al already wrote in more detail about that in the meantime.
>
> Best regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain | |\ _,,,---,,_
> \ / against HTML in | /,`.-'`' -. ;-;;,_
> X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
> / \ and unneeded MIME | '---''(_/--' `-'\_)
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME |
8. Re: A Problem with v2.4 (for Rob)
On Sun, 18 May 2003 22:58:07 +0000, Al Getz <Xaxo at aol.com> wrote:
>
>
> Juergen Luethje wrote:
>> Eu can't know that, unless Rob gives us a "do what I mean, not what I
>> say" (DWIM) interpreter.
>> There are many other situations, were Eu must rely on the assumption,
>> that what I wrote, was what I intended to write.
>
> Again, i cant agree more, and you pretty much summed it up 
>
>
> if i type
>
> atom x
> x=1
>
> i dont get an error saying
>
> ERROR_MESSAGE_START
>
> "ERROR!!!"
> "Are you sure you wanted to declare x as an atom and not
> really an integer instead? Or maybe you wanted to declare
> it as a sequence and use only the first element for now so
> that you can add elements later?
> I'll hault your program now so you can think about it.
> Oh, but one last thing:
> If you decide that you really wanted to declare it as atom,
> then i'll stop your program again anyway and ask you again."
>
> ERROR_MESSAGE_END
>
> <chuckles a little>
>
Whooaa! This is WAY off the mark. You have presented a situation that no-
one is complaining about, proceed to show that its a silly situation then
generalize from this that the namespace problem is the same sort of
problem. But its not!
The reason is that there is NO AMBIGUITY when somebody types
atom x
x = 1
Because 'atom' is a superset of integer, and this is quite acceptable and
documented. If they had of written
atom x
x = "derek"
then Eu detects an anomoly.
The namespace issue is one of resolving an ambiguity. How can this come
about???
Chris Bensler writes a library called 'clib.e' that contains a global
routine called peek_string(). Derek writes a library called tk_mem.e that
contains a global routine called peek_string() and includes that library in
win32lib.e. When other people use either Chris' or Derek's peek_string()
there is no problems. Its ONLY when somebody includes these clib.e and
win32lib.e that problems can arise - through no fault of the person that
combined them. The "invisible" global: qualifier is not going to help that
one.
--
cheers,
Derek Parnell
9. Re: A Problem with v2.4 (for Rob)
Hello Jim, you wrote:
> In my namespace parser, when looking for "DoSomething", it would first look
> at the local routines, then the global ones. If still no match, then it would
> look at the namespaces, one-by-one, (in the order they were created) until it
> found a match. If no match was found then it raised an error.
>
> Note that my parser didn't raise an error if there were _2_ DoSomeThing's,
> since
> it stopped after it had found _1_.
>
> That is arguably a flaw, but perhaps not.
All this namespace stuff is quite hairy (at least for my brain 1.0 ).
If there was a naming conflict because of 2 or more routines or
variables with the same name in the same scope, I'd like the interpreter
to raise an error rather than ignore all but the one it found first, for
the sake of safety.
> (I'm hinting at how the RDS version of namespaces could be improved, btw,
> not at getting more people to use my namespace parser, in case you didn't get
> that
I got it.
> ... my parser was designed for Eu 2.2, pre-namespaces.)
>
> jbrown
>
> On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote:
<big snip>
>> But using
>> include file1.e
>> include file2.e as i2
>> include file3.e as i3
>>
>> should work, because any file has an unambiguous namespace. file1.e has
>> the namespace "" which is not nothing. Eu IMHO should be able to handle
>> that.
My point is, that -- from a logical point of view -- here is no naming
conflict at all, and I wish that this fact would be realized by Euphoria.
Best regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
10. Re: A Problem with v2.4 (for Rob)
On Tue, 20 May 2003 00:37:21 +0000, Al Getz <Xaxo at aol.com> wrote:
[snip]
>
>
> Whooaaaa!! Derek, dont get so carried away!
> It was merely an example to show that a language cant have
> error handlers for everything because some things must be
> explicitly stated.
Sorry, I didn't get it. Still don't, too.
> Also, remember that issue i said a while back that i didnt
> want to mention because it would 'cloud' the current issue?
> Well now that you brought it out, we have to deal with that
> too.
>
> The reason you cant include two lib's that dont use namespace
> qualifiers even with in invisible 'global:' prefix is because
> DoSomething() in Henries lib is the same name as
> DoSomething()
> in Marges lib.
>
> So, that means you cant include BOTH Henries lib AND
> Marges lib, right?
Wrong. You can include both libraries. Try it.
> BUT.............
You can't refer to the common global name without at least one having a
namespace qualifier.
> You still *CAN*
> include *EITHER* of the two libraries, and not run into a problem,
> which is something you *CANT* do *NOW*!!!
That does not make sense to me. Sorry. I'm not sure what you mean.
> Since being able to include ONE library that doesnt have ns qualifiers is
> better then not being able to include ANY (or ZERO) libraries, the
> 'invisible' global prefix idea is better then the current situation.
> In other words:
>
> integer ONE,ZERO
> ONE=1
> ZERO=0
>
> if ONE>ZERO then
> puts(1,"having a global prefix is better then not having it")
> else
> puts(1,"having a global prefix is not any better then not having it")
> end if
> Also, along the same lines of reasoning you could also say that:
> x:DoSomething in Henries lib is the same as
> x:DoSomething
> in Marges lib too,
>
> which also means that at some point
> some things will have to be renamed, but, again
> using the invisible global prefix would solve
> at least problems associated with 'one' of the files,
> something that cant be done now.
Sorry, but I have to disagree again. It is possible with the current
Euphoria to do something to fix this situation. I know because I'm doing
it.
You see, the namespace concept is designed to help us manage global
symbols, but the namespace itself is not global. This means that I can code
in win32lib.e ...
include clib.e as xx
. . .
s = xx:peek_string(a)
and somebody else can code in their program ...
include win32lib.e
include magiclib.e as xx
. . . x = xx:magic_rtn()
and there is now two independant namespaces called 'xx' that do not know
about each other.
This simply means that I can use any namespace ID I like inside win32lib
and it will NOT clash with anybody else's IDs if they include win32lib.e
> You will note that it is *not possible* to solve
> the problem of two lib's included at the same time
> if they use the same names like DoSomething()
> and have been included in a third file, without
> renaming something somewhere.
> When two libs occur like this it's the responsibility
> of the programmer to do some renaming.
If we are using the current Euphoria then either the coder that is
combining libraries will have to do some changes to the library code, or
get the original authors to change their libraries.
> The global prefix idea at least handles the case when
> you are only including one lib that also includes files
> that dont use namespaces, but it's still better then nothing.
But its still a change to Euphoria, and that is not likely to happen in the
near future (6-18 months).
>
> Now you see why i didnt want to cloud the issue earlier?
No.
> Take care, and lighten up a little will ya??
Now you're starting to sound like my son
--
cheers,
Derek Parnell
11. Re: A Problem with v2.4 (for Rob)
On Mon, May 19, 2003 at 04:45:50PM +0200, Juergen Luethje wrote:
>
> Hello Jim, you wrote:
>
> > In my namespace parser, when looking for "DoSomething", it would first look
> > at the local routines, then the global ones. If still no match, then it
> > would
> > look at the namespaces, one-by-one, (in the order they were created) until
> > it
> > found a match. If no match was found then it raised an error.
> >
> > Note that my parser didn't raise an error if there were _2_ DoSomeThing's,
> > since
> > it stopped after it had found _1_.
> >
> > That is arguably a flaw, but perhaps not.
>
> All this namespace stuff is quite hairy (at least for my brain 1.0 ).
> If there was a naming conflict because of 2 or more routines or
> variables with the same name in the same scope, I'd like the interpreter
> to raise an error rather than ignore all but the one it found first, for
> the sake of safety.
>
A better approach, for the interactive preparser, would be to show all the
routines in all the namespaces, and ask the user which one to use.
For the interpreter (or noninteractive preparser), flag an error, and abort.
I'd feel, tho, that the interpreter should flag a warning instead of an error.
<snip>
> > On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote:
>
> <big snip>
>
> >> But using
> >> include file1.e
> >> include file2.e as i2
> >> include file3.e as i3
> >>
> >> should work, because any file has an unambiguous namespace. file1.e has
> >> the namespace "" which is not nothing. Eu IMHO should be able to handle
> >> that.
>
> My point is, that -- from a logical point of view -- here is no naming
> conflict at all, and I wish that this fact would be realized by Euphoria.
As do I. I did mention, that my namespace parser DOES recognize this fact ...
we are in complete agreement on this part, it would seem.
>
> Best regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain | |\ _,,,---,,_
> \ / against HTML in | /,`.-'`' -. ;-;;,_
> X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
> / \ and unneeded MIME | '---''(_/--' `-'\_)
>
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME |
12. Re: A Problem with v2.4 (for Rob)
Hello Jim, you wrote:
> On Mon, May 19, 2003 at 04:45:50PM +0200, Juergen Luethje wrote:
>>
>> Hello Jim, you wrote:
>>
>>> In my namespace parser, when looking for "DoSomething", it would first look
>>> at the local routines, then the global ones. If still no match, then it
>>> would
>>> look at the namespaces, one-by-one, (in the order they were created) until
>>> it
>>> found a match. If no match was found then it raised an error.
>>>
>>> Note that my parser didn't raise an error if there were _2_ DoSomeThing's,
>>> since
>>> it stopped after it had found _1_.
>>>
>>> That is arguably a flaw, but perhaps not.
>>
>> All this namespace stuff is quite hairy (at least for my brain 1.0 ).
>> If there was a naming conflict because of 2 or more routines or
>> variables with the same name in the same scope, I'd like the interpreter
>> to raise an error rather than ignore all but the one it found first, for
>> the sake of safety.
>>
>
> A better approach, for the interactive preparser, would be to show all the
> routines in all the namespaces, and ask the user which one to use.
That sounds nice.
> For the interpreter (or noninteractive preparser), flag an error, and abort.
> I'd feel, tho, that the interpreter should flag a warning instead of an error.
>
> <snip>
>>> On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote:
>>
>> <big snip>
>>
>>>> But using
>>>> include file1.e
>>>> include file2.e as i2
>>>> include file3.e as i3
>>>>
>>>> should work, because any file has an unambiguous namespace. file1.e has
>>>> the namespace "" which is not nothing. Eu IMHO should be able to handle
>>>> that.
>>
>> My point is, that -- from a logical point of view -- here is no naming
>> conflict at all, and I wish that this fact would be realized by Euphoria.
>
> As do I. I did mention, that my namespace parser DOES recognize this fact ...
I must have missed that, sorry! This namespace stuff is almost driving
me crazy. 
> we are in complete agreement on this part, it would seem.
>
> jbrown
Best regards,
Juergen
--
/"\ ASCII ribbon campain | Everything should be made as simple
\ / against HTML in | as possible, but not simpler.
X e-mail and news, |
/ \ and unneeded MIME | http://www.sfheart.com/einstein.html
13. Re: A Problem with v2.4 (for Rob)
- Posted by irvm at ellijay.com
May 20, 2003
On Monday 19 May 2003 10:41 pm, Derek wrote:
> If we are using the current Euphoria then either the coder that is
> combining libraries will have to do some changes to the library code, o=
r
> get the original authors to change their libraries.
Which was, I thought, what we were trying to avoid.=20
Changing someone else's libraries is error-prone and counter-productive.=20
Plus you now have to ship those modified libraries along with your progra=
m,
causing conflicts with other programs which may use the original unmodifi=
ed=20
libraries.
Then whenever the original author of the library changes/updates her code=
,=20
your program no longer works. Some solution!
Add to that the fact that properly implemented namespacing could encourag=
e=20
clearer, more modular coding, but the current solution fails to do this,=20
because you can't "pass on" namespaced variables via another include.
I'm sorry, but I have tried very hard to find a practical use for namespa=
cing=20
(as implemented) and I just can't.=20
Irv
14. Re: A Problem with v2.4 (for Rob)
----- Original Message -----
From: <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: A Problem with v2.4 (for Rob)
>
>
> On Monday 19 May 2003 10:41 pm, Derek wrote:
>
> > If we are using the current Euphoria then either the coder that is
> > combining libraries will have to do some changes to the library code, or
> > get the original authors to change their libraries.
>
> Which was, I thought, what we were trying to avoid.
I assume you mean by this is that the rationale for namespaces was that we
are trying to avoid the need to alter other people's code.
> Changing someone else's libraries is error-prone and counter-productive.
> Plus you now have to ship those modified libraries along with your
program,
> causing conflicts with other programs which may use the original
unmodified
> libraries.
> Then whenever the original author of the library changes/updates her code,
> your program no longer works. Some solution!
Agreed. And that's why we are trying to avoid being forced to modify their
code.
> Add to that the fact that properly implemented namespacing could encourage
> clearer, more modular coding, but the current solution fails to do this,
> because you can't "pass on" namespaced variables via another include.
Its only in the last few days that I've realized I've been thinking about
Euphoria's namespace implementation the wrong way round. I too thought like
you that a coder put in namespaces for others to use when needed. This is
the idea of "passing on" namespaced identifiers.
However, I now see namespaces as just a way for me to force Euphoria to use
a specific global symbol rather than one that just happens to be in scope.
But it only effects the code that I write. In other words, if I'm writing a
file that *could* be included by somebody, I really should ensure that any
global symbols I use that are contained in files that I include, then I
should be prefixing them with a namespace qualifier. That way, Eu is forced
to use the global(s) from the specific files I include and not get confused
with the same name being defined in some file that I did not explicitly
include.
To summarize, "X:Y" tells Euphoria to ONLY look in the file I've given the
namespace 'X', for the symbol 'Y' - and not to bother looking anywhere else.
> I'm sorry, but I have tried very hard to find a practical use for
namespacing
> (as implemented) and I just can't.
Even though currently its not perfect, its still better than nothing - just.
----------------
cheers,
Derek Parnell
15. Re: A Problem with v2.4 (for Rob)
Hello Derek, you wrote:
<snip>
> Its only in the last few days that I've realized I've been thinking about
> Euphoria's namespace implementation the wrong way round.
<snip>
If even you -- being one of our gurus -- write that, what shall most of
the other people here say?
I think it's quite legitimate to say, that Euphoria's namespaces are far
from simple. I estimate there may be a maximum of 10 people in the world,
who actually understand, how they work.
<not sure what kind of smiley to put here>
Best regards,
Juergen
--
/"\ ASCII ribbon campain | Everything should be made as simple
\ / against HTML in | as possible, but not simpler.
X e-mail and news, |
/ \ and unneeded MIME | http://www.sfheart.com/einstein.html
