Re: Why doesn't this work? (not-so-short)
----- Original Message -----
From: "Pete Lomax" <petelomax at blueyonder.co.uk>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Why doesn't this work? (short)
>
> On Sat, 17 May 2003 12:56:49 -0400, Robert Craig
> <rds at RapidEuphoria.com> wrote:
>
> >Whenever a file is included, the global symbols in that file
> >become visible in the including file, and all the code
> >that comes later (in other files). This might not have been
> >the best way to do things (maybe the globals should become
> >invisible at the end of the including file), but it has
> >been that way since day 1, with few complaints. If it were
> >changed now, it would break a lot of code, and require
> >people to add a lot of extra include statements.
>
> Unless I am seriously missing something about the examples posted,
> this is about namespaces, and the ability of namespace qualifiers to
> <my word no one elses:> unambiguously determine the intended reference
>
> The question is, without a namespace qualifier, is it unambiguous when
> two versions of a global exist (albeit one included with a qualifier
> and one not). I argue no, because the interpreter cannot know whether
> it is an old line or a mistyped new line.
I agree.
> In an ideal world, i'd like to see global constants and routines with
> ///the same binary signature/// not raise any eyebrows, so to speak,
> whenever there is a potential ambiguity. But that's a side issue.
I agree with these points too.
> Otherwise I'm quite happy (so far) with the way globals currently work
This is where we part ways.
> I am kicking and screaming and stamping my feet because I fear
> something might be put in to automatically resolve an ambiguity, in a
> way the programmer cannot override, and/or in a way that will be very
> difficult to spot. Hopefully I'm paranoid 
Hopefully you are and hopefully this community can provide good debate to
assist RDS in making the best decision on how to proceed. You need to be a
part of that too.
> Pete
> PS Have you considered my claim that conflicts within an include
> could actually be unambiguously resolved?
Yes, and I don't think it will without causing more confusion.
Let me tell you all a story. Its about five Euphoria coders, Alice, Bob,
Chris, Diane, and Errol.
Alice writes a really neat library. One of Alice's routines, Tokenize() is
noticed by Bob, who uses it his library. Bob's library not only includes and
uses Alice's library but it also contains a great little routine called
Read16(). Now independantly of these two coders, Chris writes a library and
it contains a routine called Tokenize(). Now Diane likes this routine of
Chris' so she uses it in her library. In fact, Diane writes a number of
useful litle utility routines in her library. Well, along comes Errol. He
sees the Read16() routine that Bob wrote and the little routine that Diane
wrote, MatrixAdd(). Errol writes a program that includes Bob's and Diane's
librarys so that he can use their routines. BANG!!! Now Diane's library is
reporting an error because she was trying to use Tokenize() from Chris's
library but Bob was trying to use Tokenize() from Alice's library, and
Euphoria cannot resolve the ambiguity. What can Errol do to fix this -
without changing any of Alice's, Bob's, Chris' and Diane's code. NOTHING.
There is nothing that Errol can do about it. He is now stuffed through no
fault of his own.
The two ideas put forward recently to help this very (real) situation attack
the problem from both perspectives. Kat's idea about "include local ..."
would allow Bob and Diane to include Alice's and Chris' library respectively
and limit the scope of libraries to their own code. In other words, Bob
could refernce Alice's Tokenize() and Diane could reference Chris'
Tokenize() and Errol would not even know about it.
The other idea is to allow Errol to add the 'drop ...' line to address a
specific ambiguity. He would write...
-- Allow bob to use alice's Tokenize()
include bob.e
-- Remove Toknize() from the global symbol table
drop Tokenize
-- Allow diane to use chris' Tokenize() 'cos alice's is now
hidden/dropped.
include diane.e
----------------
cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
