1. Why doesn't this work? (short)
Why doesn't this work?
Three simple files...
--in file "Main.exw"
include AStruct.ew as AS
include BStruct.ew as BS
atom addr
addr=AS:allocate()--want to call AStruct's allocator.
--in file "AStruct.ew"
include machine.e as mach --namespace so i can reuse "allocate"
atom addr
global function allocate()
addr=mach:allocate(64)
return addr
end function
--in file "BStruct.ew"
include machine.e
atom addr
addr=allocate(64)
--resulting error message:
---------------------------------------------------------
C:\Euphoria\Projects\Tests\Ns2\BStruct.ew:5
A namespace qualifier is needed to resolve allocate.
allocate is defined as a global symbol in:
C:\EUPHORIA\include\machine.e
C:\Euphoria\Projects\Tests\Ns2\AStruct.ew
addr=allocate(64)
^
Press Enter...
----------------------------------------------------------
Any ideas?
Take care,
Al
2. Re: Why doesn't this work? (short)
Hello Al, you wrote:
> Why doesn't this work?
>
>
> Three simple files...
>
>
> --in file "Main.exw"
> include AStruct.ew as AS
> include BStruct.ew as BS
> atom addr
> addr=AS:allocate()--want to call AStruct's allocator.
>
>
> --in file "AStruct.ew"
> include machine.e as mach --namespace so i can reuse "allocate"
> atom addr
> global function allocate()
> addr=mach:allocate(64)
> return addr
> end function
>
>
> --in file "BStruct.ew"
> include machine.e
"machine.e" is included in "BStruct.ew", and "BStruct.ew" is included
in "Main.exw". So "machine.e" is indirectly included in "Main.exw".
It looks to me, as if the command 'include BStruct.ew as BS' only adds
the namespace qualifier to the global routines physically contained in
the file "BStruct.ew". Maybe.
If so, then IMHO it's the same problem, that is discussed in the thread
"A Problem with v2.4 (for Rob)".
> atom addr
> addr=allocate(64)
>
>
> --resulting error message:
> ---------------------------------------------------------
> C:\Euphoria\Projects\Tests\Ns2\BStruct.ew:5
> A namespace qualifier is needed to resolve allocate.
> allocate is defined as a global symbol in:
> C:\EUPHORIA\include\machine.e
> C:\Euphoria\Projects\Tests\Ns2\AStruct.ew
>
> addr=allocate(64)
> ^
>
>
> Press Enter...
> ----------------------------------------------------------
>
> Any ideas?
>
> Take care,
> Al
Best Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
3. Re: Why doesn't this work? (short)
Al Getz wrote:
> Why doesn't this work?
>
>
> Three simple files...
>
>
> --in file "Main.exw"
> include AStruct.ew as AS
> include BStruct.ew as BS
> atom addr
> addr=AS:allocate()--want to call AStruct's allocator.
>
>
> --in file "AStruct.ew"
> include machine.e as mach --namespace so i can reuse "allocate"
> atom addr
> global function allocate()
> addr=mach:allocate(64)
> return addr
> end function
>
>
> --in file "BStruct.ew"
> include machine.e
> atom addr
> addr=allocate(64)
>
>
> --resulting error message:
> ---------------------------------------------------------
> C:\Euphoria\Projects\Tests\Ns2\BStruct.ew:5
> A namespace qualifier is needed to resolve allocate.
> allocate is defined as a global symbol in:
> C:\EUPHORIA\include\machine.e
> C:\Euphoria\Projects\Tests\Ns2\AStruct.ew
>
> addr=allocate(64)
> ^
Thanks for the clear example.
It's similar to what Derek sent me yesterday.
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Why doesn't this work? (short)
- Posted by gertie at visionsix.com
May 17, 2003
On 17 May 2003, at 12:56, Robert Craig 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.
How about:
include local file.name
or at the end of a file:
end include file.name
?
Kat
5. Re: Why doesn't this work? (short)
----- Original Message -----
From: <gertie at visionsix.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Why doesn't this work? (short)
>
> On 17 May 2003, at 12:56, Robert Craig 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.
>
> How about:
>
> include local file.name
>
> or at the end of a file:
>
> end include file.name
>
Thanks Kat,
these are good ideas. I think I prefer the "include local file.name" one.
This would stll put the onus on the library author though. Another idea,
which can also work with yours, is to have a line like ...
drop global_symbol_1,...
that causes specific included global symbols to be dropped from the symbol
table. This would allow coders using 3rd party libraries, to excluded some
globals while still having access to others.
Example:
-- in mytest.ex
include lib1.e
drop procD
include lib2.e
-- in lib1.e
include sublib1.e
procD()
-- in lib2.e
include sublib2.e
procD()
-- in sublib1.e
global procedure procD()
puts(1,"sub1\n")
end procedure
-- in sublib2.e
global procedure procD()
puts(1,"sub2\n")
end procedure
this would mean that code inside lib1.e could reference the procD routine
that was included inside sublib1.e, and code inside lib2.e could reference
the procD routine included sublib2.e, without namespace clashes.
Further refinements could be that droppping a non-existant symbol should not
cause an error (a warning maybe). Also, dropping an unadorned symbol name
(one without a namespace qualifier) should not prevent the adorned name from
being used. Example:
-- in mytest.ex
include lib1.e as L1
drop procD -- allows lib2 to use 'procD'
include lib2.e as l2
L1:procD() -- explictly uses the procD in lib1.
----------------
cheers,
Derek Parnell
6. Re: Why doesn't this work? (short)
gertie at visionsix.com wrote:
> How about:
>
> include local file.name
>
> or at the end of a file:
>
> end include file.name
>
> ?
Thanks for the suggestions.
I may get into this issue again for the
next release (2.5). At the moment I'm trying
to finalize 2.4 and get a stable release out
that we can live with for a while.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Why doesn't this work? (short)
Derek Parnell wrote:
> ... Another idea,
> which can also work with yours, is to have a line like ...
>
> drop global_symbol_1,...
>
> that causes specific included global symbols to be dropped from the symbol
> table. This would allow coders using 3rd party libraries, to excluded some
> globals while still having access to others.
Thanks. I'll add that idea to my list as well.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. 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.
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.
Otherwise I'm quite happy (so far) with the way globals currently work
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 
Pete
PS Have you considered my claim that conflicts within an include
could actually be unambiguously resolved?
9. Re: Why doesn't this work? (short)
On Sun, 18 May 2003 07:27:12 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:
> drop global_symbol_1,...
Nice idea, though I dont feel this warrants a new keyword, how about
instead a new builtin:
renameglobal("procD","x1procD")
would be useful, and
renameglobal("procD","")
could function as drop
Pete
10. Re: Why doesn't this work? (short)
That works ... until someone passes renameglobal() a variable or constant.
Then, the translator could break.
jbrown
On Sun, May 18, 2003 at 01:08:34AM +0100, Pete Lomax wrote:
>
> On Sun, 18 May 2003 07:27:12 +1000, Derek Parnell
> <ddparnell at bigpond.com> wrote:
>
> > drop global_symbol_1,...
>
> Nice idea, though I dont feel this warrants a new keyword, how about
> instead a new builtin:
>
> renameglobal("procD","x1procD")
>
> would be useful, and
>
> renameglobal("procD","")
>
> could function as drop
>
> Pete
>
>
>
> 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 |
11. Re: Why doesn't this work? (short)
On Sat, 17 May 2003 20:40:56 -0400, jbrown1050 at hotpop.com wrote:
>
>That works ... until someone passes renameglobal() a variable or =
constant.
>
>Then, the translator could break.
>
Enlighten me. How would renameglobal() break things when misuse of a
drop keyword would not?
Pete
12. Re: Why doesn't this work? (short)
On Sun, May 18, 2003 at 01:42:29AM +0100, Pete Lomax wrote:
>
> On Sat, 17 May 2003 20:40:56 -0400, jbrown1050 at hotpop.com wrote:
>
> >
> >That works ... until someone passes renameglobal() a variable or constant.
> >
> >Then, the translator could break.
> >
> Enlighten me. How would renameglobal() break things when misuse of a
> drop keyword would not?
>
> Pete
>
--
global object gTry
sequence s, v
s = "gT"
v = "ry"
renameglobal(s&v, "")
--
It'd be tricky, knowing what s&v is at translation time ... and I'd doubt how
the translator could set it up to rename it at runtime!
And, if you dont allow such things as s&v in it, only literal strings,
might as well as take the "'s off of it .. which would make it essentially
a keyword.
Need more clarification?
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 |
13. Re: Why doesn't this work? (short)
by holmes.peterlink.ru (8.12.6/8.12.6) with ESMTP id h4I5M2CN085805
for <EUforum at topica.com>; Sun, 18 May 2003 09:22:03 +0400 (MSD)
by stapleton.peterlink.ru (8.12.3/8.12.3) with ESMTP id h4I5JxOv049895
for <EUforum at topica.com>; Sun, 18 May 2003 09:20:00 +0400 (MSD)
Dear EU users:
Just IMHO.
Just globals must be real globals
and must be visible anywhere
EU is simple and clear language,
please, do not forget about this=20
simple thing.
Regards,
Igor Kachan
kinz at peterlink.ru
----------
> =CE=F2: Robert Craig <rds at RapidEuphoria.com>
> =CA=EE=EC=F3: EUforum <EUforum at topica.com>
> =D2=E5=EC=E0: Re: Why doesn't this work? (short)
> =C4=E0=F2=E0: 18 =EC=E0=FF 2003 =E3. 1:51
>=20
> Derek Parnell wrote:
> > ... Another idea,
> > which can also work with yours, is to have a line like ...
> >=20
> > drop global_symbol_1,...
> >=20
> > that causes specific included global symbols to be dropped from the
symbol
> > table. This would allow coders using 3rd party libraries, to excluded
some
> > globals while still having access to others.
>=20
> Thanks. I'll add that idea to my list as well.
>=20
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
14. Re: Why doesn't this work? (short)
OOOpppSSS!!!
Something wrong with Topica or with
somethind else, my previous message with
damadged test programs is on Topica page,
but I recived it as blank and empty.
Regards,
Igor Kachan
kinz at peterlink.ru
15. Re: Why doesn't this work? (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 Sun, 18 May 2003 07:27:12 +1000, Derek Parnell
> <ddparnell at bigpond.com> wrote:
>
> > drop global_symbol_1,...
>
> Nice idea, though I dont feel this warrants a new keyword, how about
> instead a new builtin:
>
> renameglobal("procD","x1procD")
>
> would be useful, and
>
> renameglobal("procD","")
>
> could function as drop
>
> Pete
Because 'drop ...' works at interpretation/compile time and built in
routines work at runtime. And namespace clashes occur at interpretation
time.
----------------
cheers,
Derek Parnell
16. Re: Why doesn't this work? (short)
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Why doesn't this work? (short)
>
> Dear EU users:
>
> Just IMHO.
>
> Just globals must be real globals
> and must be visible anywhere
Agreed, but just not all the time.
> EU is simple and clear language,
> please, do not forget about this
> simple thing.
Unfortunately, life's situations are not always simple. Do we want Euphoria
to be able to address a greater subset of programming issues than it
currently can or not.
And remember, simple and simplistic are not the same thing. I want Euphoria
to be simple but not simplistic.
17. Re: Why doesn't this work? (short)
Al Getz wrote:
----------
> From: Al Getz <Xaxo at aol.com>
> Sub: RE: Why doesn't this work? (short)
<snip>
> 2. I would bet that there are not that many
> people using the namespace thing yet.
> If they are using it, they arnt using it very
> much or they would have noticed this already.
> Even so, i would seriously doubt that they are
> using it in a way that would break their code
> if a warning was issued instead of halting.
> If it now haults on error, then their code cant
> contain any errors, so it seems their code wont
> issue any warnings either.
<snip>
Above point sounds as a good invitation to
inventions of some artificial (maybe crazy)
test codes to try the namespace thing from
all sides.
Actually The Archive almost globally consists
of the programs written without the namespace
feature.
So, those programs are not very useful as
the special test programs -- they have no
any conflicts of any names and only pure
new special stuff can help.
As an example of such special test program
I have attached 4 files.
Try please and you'll see that global integer
z of a.e is not visible inside include files
b.e and c.e.
This feature seems to be not very useful
--Just for Topica test I put below the programs
--from the attachment of my damaged
--previous message.
--a.e file
global integer z
z=1
?z
--a.e eof
--b.e file
global integer z
z=2
?z
--b.e eof
--c.e file
global integer z
z=3
?z
--c.e eof
--z.ex file, run it
include a.e
include b.e
include c.e
?z
z=5
?z
integer z
z=4
z+=z
?z
include c.e
global integer z
z=2
?z
--z.ex eof
--------
Regards,
Igor Kachan
kinz at peterlink.ru
18. Re: Why doesn't this work? (short)
On Sun, 18 May 2003 20:19:33 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:
>Because 'drop ...' works at interpretation/compile time and built in
>routines work at runtime. And namespace clashes occur at interpretation
>time.
Yep, you're right.
Pete
19. Re: Why doesn't this work? (short)
Hi Derek,
----------
> From: Derek Parnell <ddparnell at bigpond.com>
> Subject: Re: Why doesn't this work? (short)
> ----- Original Message -----
> From: "Igor Kachan" <kinz at peterlink.ru>
> To: "EUforum" <EUforum at topica.com>
> Subject: Re: Why doesn't this work? (short)
>
> >
> > Dear EU users:
> >
> > Just IMHO.
> >
> > Just globals must be real globals
> > and must be visible anywhere
>
> Agreed, but just not all the time.
>
> > EU is simple and clear language,
> > please, do not forget about this
> > simple thing.
>
> Unfortunately, life's situations are not
> always simple. Do we want Euphoria
> to be able to address a greater subset
> of programming issues than it
> currently can or not.
global sequence OK
OK = repeat("ok", 100)--+0000)
for i=1 to length(OK) do puts(1, OK[i])
end for
--Do you understand my Agree?
> And remember, simple and simplistic are
> not the same thing. I want Euphoria
> to be simple but not simplistic.
Sorry, I have no the "simplistic" word in my book --
Muller's English-Russian Dictionary of 53000 entries,
but I do believe it is not "simple" and it is something
very very not good
If so, just run above code once more
Regards,
Igor Kachan
kinz at peterlink.ru
20. Re: Why doesn't this work? (short)
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Why doesn't this work? (short)
>
[snip]
>
> > And remember, simple and simplistic are
> > not the same thing. I want Euphoria
> > to be simple but not simplistic.
>
> Sorry, I have no the "simplistic" word in my book --
> Muller's English-Russian Dictionary of 53000 entries,
> but I do believe it is not "simple" and it is something
> very very not good
>
SIMPLE: implies easy to use or understand
SIMPLISTIC: implies limited capabilities.
----------------
cheers,
Derek Parnell
21. Re: Why doesn't this work? (short)
by holmes.peterlink.ru (8.12.6/8.12.6) with ESMTP id h4IDD4CL005135
for <EUforum at topica.com>; Sun, 18 May 2003 17:13:04 +0400 (MSD)
by stapleton.peterlink.ru (8.12.3/8.12.3) with ESMTP id h4IDBwOv057520
for <EUforum at topica.com>; Sun, 18 May 2003 17:11:59 +0400 (MSD)
Hi Derek again,
Thanks for explanation, but read please below...
----------
> =CE=F2: Derek Parnell <ddparnell at bigpond.com>
> =CA=EE=EC=F3: EUforum <EUforum at topica.com>
> =D2=E5=EC=E0: Re: Why doesn't this work? (short)
> =C4=E0=F2=E0: 18 =EC=E0=FF 2003 =E3. 16:15
>=20
> >=20
> [snip]
>=20
> >=20
> > > And remember, simple and simplistic are=20
> > > not the same thing. I want Euphoria
> > > to be simple but not simplistic.
> >=20
> > Sorry, I have no the "simplistic" word in my book --
> > Muller's English-Russian Dictionary of 53000 entries,
> > but I do believe it is not "simple" and it is something
> > very very not good
> >=20
>=20
> SIMPLE: implies easy to use or understand
>=20
> SIMPLISTIC: implies limited capabilities.
Hey, no one can make EU simplistic now.
So, I can not share your trouble about
that "simplistic".
Don't worry be happy!
Just let us try the new EU=20
from every side.
Regards,
Igor Kachan
kinz at peterlink.ru
22. Re: Why doesn't this work? (short)
Hello Dear EU users:
Igor Kachan (me:) wrote
> Dear EU users:
>
> Just IMHO.
>
> Just globals must be real globals
> and must be visible anywhere
>
> EU is simple and clear language,
> please, do not forget about this=20
> simple thing.
I have to explain these thesises more clearly, I think now.
(BTW take a look to a Topica's "this=20", "this=BbUuGg", not 20).
Good programming language MUST be clear.
English key words of EU were absolutelly clear for most
Russians. Now single exeption relates to the *global* word
after, so to say, the namespace 'revolution'.
This common word has it's *main* sense, so the action of the
*global* operator of EU programming language must be
as close to this sense as possible without many words
to explain what is EU global really.
And this *global* operator may have some additional
features detailed in documentation.
But now, you must first of all learn *these additional features*
to understand common word *global* well in EU and avoid the
cryptic bugs. The OOP concept is difficult for understanding
just because of similar abstractions.
For good and easy understanding, space of the global names
has to be more and more common-single-monolite for the user's
program with all include files after the points of including.
If you need separate that common space because of names
conflicts -- use additional features, use the AS form of
the include operator, you may even rename yourself
This common-single-monolite space of the global names may
be organized with better warning system, something similar
to the builtin names, I think. Globals are too important to be
silently ignored or overridden in a program of novice nor guru.
Novice has no experience, guru has no his own memory to remember
all win32lib or Win95/98/ME/2000/X/XP - Linux/DOS32/FreeBSD
- EU own globals' names
"with/without globals" or similar command is not so good
as just warning or aborting, I think.
Remember please, an include file with its include files may
be just included into your program and then same include
file may be executed from same your program with system_exec()
command any times in any points you wish.
This feature is powerful but rare used for now.
Sorry, just IMHO again.
Regards,
Igor Kachan
kinz at peterlink.ru
