1. RE: A Problem with v2.4 (for Rob)#2
Hello there Derek,
I think you may have missed the point, which i'll try to clarify here.
You did, however, hint on something else that might also be a problem,
but im not sure i want to get into it right now because it might
cloud the first issue here.
Derek Parnell wrote:
>
>
> 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()
>
I could do this with Eu v2.0 by changeing ":" to "_" .
If you look closely at the
above code, you will notice that you changed two things:
1. the include statement from "include file.ew" to "include file.ew as
SE"
2. DoSomething() to SE:DoSomething()
But in the actual code you would have had to change 102 things because
there were 100 other existing functions also.
So, when you say "Explicitly tell Eu" what you really mean
is "rename", and once you say 'rename' havent you defeated
the purpose of having a namespace in the first place?
The reason for having a namespace is so you dont have to go
over someone elses code and rename every variable in the files
that clashes with yours.
If you dont agree on this, then i have 2073 include files i
can send you and you can 'explicitly tell Eu' in all the files
for every global and then send them back to me 
>
> 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
>
> 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.
>
>
This is what the two lines:
include thisfile.ew as wx
include thisfile.ew
was suppose to show the 'fix' for just in case any code gets broken.
I agree a warning would be better too.
WX:MyAtom
should refer only to the file that was included as WX,
which certainly makes sense.
MyAtom
would refer to only a global atom declared in another file.
Lets try to take a more careful look...
The main problem involves at least two sets of files, the
existing files and the new files. Since each set
can either use qualifiers or not use qualifiers,
we end up with 16 cases, which i believe can be
reduced to the two most important ones:
1. (Existing files uses Namespace Qualifiers) AND (New files do too)
2. (Existing files dont use Namespaces) AND (New files do use them)
Now we already know that case #1 probably works ok.
It's case #2 that is the biggest problem.
Note that if we assigned two values to indicate whether or not
the file ever was included with Namespace Prefixes we might choose these
two:
constant
HAS_PREFIX=1,
NO_PREFIX=0
and so the interpreter would always be able to tell the difference
between
DoSomething() --in existing code
and
MF:DoSomething() --a new procdure in the new code
Another way of stating the solution would be this:
1. For every global that appears in the file assign a provisional
namespace qualifier. For the sake of clarity here lets use 'guID'.
Now the function that first appears as 'DoSomething()' looks like
this:
guID:DoSomething()
except the prefix 'guID:' is implied, not visible to the programmer.
2. The next thing that could happen is the file with 'DoSomething()'
in it gets included with 'include file.ew'. In this case, for all
globals that appear in the file each one keeps it's original
provisional prefix of 'guID:' .
Alternately, the file might get included with
'include file.ew as XP'
in which case the provisional prefix gets replaced with "XP:" .
This should be very easy to implement.
Now, looking back at the original code, the function
"DoSomething()"
calls the original existing function as expected because
it already has a prefix and that prefix matches the original
codes prefix (even though invisible to the programmer),
and the new function
"MF:DoSomething()"
calls the new code as expected.
BTW, the provisional globally unique identifier could be
choosen to be something like "EuXyZ" and conveyed to
programmers as a reserved keyword for prefixes so as
not to use for your new file prefixes. We wouldnt want
to take up any name that could be useful in an actual
program such as "GuID".
I hope this clears up this issue as i would really like to see
this get resolved very soon.
Take care for now,
Al
2. RE: A Problem with v2.4 (for Rob)#2
Hello again,
Pete:
Im not really trying to include two libs with
"include"
but trying to say that
include file1
include file2 as x
should mean globals in both files are visible
to the exw, but the ones in file2 are prefixed
while the ones in file1 are not, which means
they are still different functions even though
they have the same name inside each include file.
The following shows this more clearly.
Derek wrote:
-------------------------------------------------------------------------
Clears as mud. It seems to me that you have made this way too
complicated.
Are you just saying that ...
DoSomething()
should be found in the include file that did NOT have a namespace
because
the reference did not specify a namespace. Is that it?
-------------------------------------------------------------------------
Yes, that's it, but it's very important.
I'll try to show why here just in case the importance isnt that clear.
I also see now why there is some confusion. I havent properly
explained the problem situation, only the solution.
Here, we will be dealing with actual code (except for
the c_func() calls, which can be eliminated and
instead just return a zero).
This means the example code will be able to run.
In the following scenario the function 'CreateWindow()' is used
to represent a generic class of global functions as well as
global variables.
Generic global variables are those which are highly likely to
appear in libraries such as:
hInstance
MainWindow
WM_PAINT
WS_OVERLAPPED
while generic global functions are same except they are
global functions and procedures such as:
CreateWindow()
getstring()
or_all()
The scene looks like this:
We have a lib ew file (file1.ew) and a program (file3.exw)
that we are currently using and it works fine. This file
has a lot of generic globals in it.
Sometime later, we want to add another library (file2.ew)
with lots of the same generic globals in it and call it
from the exw program file along with the original lib.
It wont matter that much if we have indentical function
calls and identical variables, because if we never use them
the binder will remove them (assumed) when we go to exe form.
The two libraries should be able to coexist in the program
with no difficulty, even though they have exactly the
same function and variable names, and lots of them.
I would think this scenario is quite common these days.
Now the actual files...
--The original program consisted of file1.ew and file3.ew
--file1.ew
--Existing, ew library (lib1)
global function CreateWindow()
puts(1, "Creating a window")
hWnd=c_func(...)
return hWnd
end function
--file3.exw
--Existing, exw file that calls lib1 functions
include file1.ew --we want to use "CreateWindow()"
atom hWnd
hWnd=CreateWindow()
So far all we are doing is using an ew library.
Now later, we write a new library, or find another one
to use (file2.ew). The new library has updated functions
(represented by CreateWindowEx) but also has many
other older functions that were also needed in
it's original app, and these also appear in the original
library (file1.ew).
--file2.ew
--New, or possibly just another existing library (lib2)
global function CreateWindow()
atom hWnd
puts(1, "Let's make a window")
hWnd=c_func(...)
return hWnd
end function
global function CreateWindowEx()
atom hWnd
puts(1, "Let's make a windowEx")
hWnd=c_func(...)
return hWnd
end function
Now since we want to use our new library AND the old library AND
our original code, we have to modify the exw file.
We of course have to add the new function calls and new code,
but we shouldnt have to modify any existing code.
Note that anything we change can easily include a prefix,
while that which exists we shouldnt have to add a prefix to:
--file3.exw (modified)
include file1.ew --we want to use the old functions
include file2.ew as Windows --we want to use our new functions.
atom hWnd
--the original function call using the original lib1:
hWnd=CreateWindow()
--the new call using the new lib2:
hWnd=Windows:CreateWindow()
In the modified file, line 5, an error is flagged for
a namespace prefix and the program stops running.
To make matters worse, let's rem out line 7
"hWnd=Windows:CreateWindow()"
changes to
"--hWnd=Windows:CreateWindow()"
and let's instead call the newer function we intended
by adding a line to the end of the exw file:
"hWnd=Windows:CreateWindowEx()"
The new modified file now looks like this:
--file3.exw (modified again)
include file1.ew --we want to use the old functions
include file2.ew as Windows --we want to use our new functions.
atom hWnd
--the original function call in the original lib1:
hWnd=CreateWindow()
--the new call using the new lib2:
--hWnd=Windows:CreateWindow() ------ remmed out
hWnd=Windows:CreateWindowEx() ------ new call
Now we run the program again.
What happens?
Again line 5
"hWnd=CreateWindow()"
flags the prefix error and haults
(as we would have guessed because we modified lines AFTER that error).
Thus, merely the PRESENCE of an identical global in the newer ew file
causes errors that hault the program, even though we arent
calling or using it and we have properly prefixed it.
This could be interpreted as the newer file being the offender,
even though it is properly prefixed.
Keep in mind that we didnt necessarily write the
new file, and we dont want to have to modify that file
either.
Now in the modified file3.exw it's true that if we change the line
"include file1.ew as x"
then we can change the offending line(s)
"hWnd=CreateWindow()"
to
"hWnd=x:CreateWindow()"
and this would solve the problem, but,
this would require our changing EVERY generic function
call and EVERY generic global variable in the whole exw program
to include a prefix. This is exactly what we want to avoid.
The reason i say "EVERY" and not "SOME" is because in theory
we assume that we have to change every global, not just some,
because in some libraries there will be a very high coincidence
of identical names and we wont want to have to go through the whole
file adding prefixes, even though it isnt 'really' every single
variable and function. Once we assume "EVERY", we'll cover
'every' case when we find a solution.
It's also true that we could either change or remove the
offending globals in the new ew (file2.ew) but this
too can be very difficult when there are lots of them.
Now if every global in every file that wasnt included
with a qualifier
was prefixed with something like "guid:" then the program
would run just fine because it would see that
"include file1.ew"
was really
"include file1.ew as guid"
and that
"hWnd=CreateWindow()"
was really
"hWnd=guid:CreateWindow()"
in the modified file3.exw,
except that the prefix "guid:"
isnt nor has to be visible.
With this there is no problem and the code would run fine.
I dont think it would even break any existing code.
CONCLUSION
The way Euphoria is handling the namespace right now is such that
an exw file that calls a library has to use qualifiers if a new
library with identical names might someday be used with it, or else
either the old lib, new lib, or exw file has to be extensively modified.
By using the idea of the implied provisional prefix, this problem
would go away.
Possibly just eliminating the syntax error halting would do it too,
as long as the non-qualified global call was referenced to the
non-qualified file properly.
I think this explains it, finally
Take care for now,
Al
3. RE: A Problem with v2.4 (for Rob)#2
jbrown1050 at hotpop.com wrote:
>
> On Thu, May 15, 2003 at 08:28:33PM +0000, Al Getz wrote:
> >
> > Hello again,
> >
> <big snip>
> > CONCLUSION
> >
> > The way Euphoria is handling the namespace right now is such that
> > an exw file that calls a library has to use qualifiers if a new
> > library with identical names might someday be used with it, or else
> > either the old lib, new lib, or exw file has to be extensively modified.
> > By using the idea of the implied provisional prefix, this problem
> > would go away.
> > Possibly just eliminating the syntax error halting would do it too,
> > as long as the non-qualified global call was referenced to the
> > non-qualified file properly.
> >
> > I think this explains it, finally
> >
> > Take care for now,
> > Al
>
> Yes, it does. I, of course, actually wrote a preprocessor to get around
> this problem. (It was back in the days of 2.2 tho, but modern namespaces
> haven't obsoleted it just yet..)
>
> I think, a warning should be emitted, naturally, but not an error. Don't
> see
> quite why Rob did it this way.
>
> jbrown
>
> >
> > either the old lib, new lib, or exw file has to be extensively modified.
> ^^^
>
> I just hate it when people get Windows-centric. Don't you? (Seriously,
> this
> does affect the DOS and Linux/FreeBSD versions of Euphoria as well, you
> know.)
>
> --
> /"\ 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 |
>
>
Hello there jbrown,
Yes, i agree a warning would be better and that seems to be
the general opinion on the matter. In my opinion, however,
i dont even want that because if the programmer doesnt
know that
DoSomething()
is a different function call than
WX:DoSomething()
then they also dont realize that
DoSomething()
is a different function call than
WX_DoSomething()
simply because the two 'names' are different in all cases.
If the programmer doesnt type the correct function, it's not
the language that's at fault and who needs a warning?
Maybe then they also dont realize that
DoThis()
is a different function call then
DoThat()
Also, i didnt mean to imply that namespace issues were
confined to ew files with windows. As you said, the
same things come up with e files using dos. I just use
the ew files much more often.
Thanks for your input on the matter too.
Take care for now,
Al
4. RE: A Problem with v2.4 (for Rob)#2
Pete Lomax wrote:
>
> On Fri, 16 May 2003 19:19:53 +0000, Al Getz <Xaxo at aol.com> wrote:
>
> >Yes, i agree a warning would be better and
>
> > that seems to be the general opinion on the matter.
> ^^^^^
> Huhh!!??, I missed that. Let me remind you: you are wrong.
>
> > In my opinion, however,
> >i dont even want that because if the programmer doesnt
> >know that
> >DoSomething()
> >is a different function call than
> >WX:DoSomething()
>
> No. Derek picked this up far quicker than me.
> You are asking Euphoria to be changed for the benefit of programmers
> who are just too damn lazy to do what must be done to make their
> program work. And make it a thousand times more likely to put new
> unfathomable errors in new code.
>
> What YOU cannot see is that
> DoSomething()
> and
> WX:DoSomething()
> is quite simply not enough for the interpreter to be *CONFIDENT* it is
> making the right choice; *CORRECTLY* it knows it may be wrong, and it
> says so.
>
> Let me repeat this slowly. It is not whether the programmer knows what
> they mean, it is what the machine is *UNAMBIGUOUSLY* told.
>
> If that means you have to edit lots of code, then guess what, you have
> to edit lots of code.
>
> Life is full of pain, son, get over it.
>
> Pete
> <starting a flame war, I know, but this is important, plus I'm right>
>
Pete,
First off, i wasnt talking to you.
Second, if you cant see that
DoSomething()
is different then
WX:DoSomething()
then you also cant see that
DoSomething()
is different then
WX_DoSomething()
or is it that you cant read English perhaps?
I dont know about the interpreter, but i'm totally
confident that when i call DoSomething() i dont
want to call WX_DoSomething(), and the idea is to
*not* have to rename *anything*.
In computer science it's sometimes referred to as
"Reusable code".
Nice try, dad.
"It seems often perfectly, which its errors perfectly hide."
--Al Getz
5. RE: A Problem with v2.4 (for Rob)#2
Juergen Luethje wrote:
>
> Hello Al, you wrote:
>
> > Yes, i agree a warning would be better and that seems to be
> > the general opinion on the matter. In my opinion, however,
> > i dont even want that because if the programmer doesnt
> > know that
> > DoSomething()
> > is a different function call than
> > WX:DoSomething()
> >
> > then they also dont realize that
> > DoSomething()
> > is a different function call than
> > WX_DoSomething()
> >
> >
> > simply because the two 'names' are different in all cases.
> > If the programmer doesnt type the correct function, it's not
> > the language that's at fault and who needs a warning?
> >
> > Maybe then they also dont realize that
> > DoThis()
> > is a different function call then
> > DoThat()
> >
>
> That's really the bottom line IMHO. A warnning isn't necessary, but it
> maybe could help to be on the safe side.
>
> Regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain | |\ _,,,---,,_
> \ / against HTML in | /,`.-'`' -. ;-;;,_
> X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
> / \ and unneeded MIME | '---''(_/--' `-'\_)
>
Hello again Juergen,
I couldnt agree more.
I think if the interpreter can understand the difference
between the global and the local i think everyone will be
happy, even if they dont realize it yet
Take care for now,
Al
