1. More Namespace (was: little question once again)
- Posted by nieuwen at XS4ALL.NL
Sep 27, 1999
NameSpace
=========
The current namespace suggestion of prefixing with the include file: it will not
work with the
present programs and librariesnot ? Because they still conflict! Irregardless of
the fact that
you're program is capable of specifying the include he meant. I suggest, that
the base of fixing
the namespace problem is by getting rid of that one huge global namespace. It
*is* that
simple.
"Global will, from now on, be interpreted as accessible from any file that
contains an
*include* statement with the name of the file."
In other words, modularize namespace and 99% of the problems will be solved, or
can be
easily solved. The same is true for overloading of identifiers.
Now, the point-syntax may be a solution, but routine names in Euphoria are
already very
long. I think it would create almost unusable long identifier names.
Plus, it isn't really needed:: no program has to use both the normal graphics
routines and Neil
at the same time, for example. And then there is always routine-id. The biggest
namespace
issue at the moment is that Euphoria halts your program rather than letting the
identifier being
redefined. The second biggest problem *would* be: Once routines are overloaded
once and
the original routines are 'included' *again* what should Euphoria do ? Answer:
Overload
them again. Implementation-wise this would mean, for some 'colliding' routine
names the
interpreter has to know which of the two include files was included last *in
this current
namespace* .. so, for the interpreter, a situation as:
include a
z = special_libfunction (x)
include b
z = special_libfunction (x)
include a
z = special_libfunction (x)
The first call would be to the function from include file 'a', the second from
include file 'b' and
the third again from include file 'a'. Assuming both files contain a function
called
special_libfunction ()
This would already *fix* the problem, however, we might, lazy as we are, forget
to include a
number of files that we _do_ use, but usually are already included and part of
the namespace.
This is why I suggest modular-namespace. So, in short, the example above shows
how, in my
eyes, Euphoria should handle 'overloading' .. but I suggest routines from an
include library not
specifically included by that part of the program should generate an error. This
will force a
programmer to specify all the include files that he uses in that particular file
( a library or
program component), with the result that possible side-effects of changing the
order of
include files in the main program or any library loaded earlier are simply not
possible.
So, in short, two rules, would solve everything:
- overloading occurs again and again and again when the include statement is
encountered.
- only identifiers defined in an include file directly included in the current
namespace (the
current file, ie. a library or program) are accessible.
This will, in my eyes, be the most clean approach to handle the namespace issue.
It makes
currently broken programs run, and does not add any new construct to the
language, and
most of all, when you use it, its quite intuitive.
Ralf Nieuwenhuijsen
[[ Email ]]
nieuwen at xs4all.nl
ralf_n at email.com
[[ I-Seek-You ]]
UIN: 9389920
[[ The Elevator ]]
http://www.xs4all.nl/~nieuwen
2. Re: More Namespace (was: little question once again)
On Mon, 27 Sep 1999 18:38:33 +0000, nieuwen at XS4ALL.NL wrote:
>NameSpace
>=========
>
>The current namespace suggestion of prefixing with the include file: it
will not work with the
>present programs and librariesnot ? Because they still conflict!
I don't see how they conflict, unless you mean that, unchanged they still
conflict.
>Irregardless of the fact that
>you're program is capable of specifying the include he meant. I suggest,
that the base of fixing
>the namespace problem is by getting rid of that one huge global namespace.
It *is* that
>simple.
>
>"Global will, from now on, be interpreted as accessible from any file that
contains an
>*include* statement with the name of the file."
>
This is good thinking as far as it goes, but will cause a problem I will
mention further down.
>In other words, modularize namespace and 99% of the problems will be
>solved, or can be
>easily solved. The same is true for overloading of identifiers.
>
>Now, the point-syntax may be a solution, but routine names in Euphoria are
>already very
>long. I think it would create almost unusable long identifier names.
>
As I suggested in another post, my preference is to allow "named" includes
to keep the prefixes short. These might be something of the order of
include foo=foo_this_name_is_to_long_to_easily_use.e
very much like a globally declared constant, which in reality, it is. Now
everything gets prefixed with foo.
>Plus, it isn't really needed:: no program has to use both the normal
>graphics routines and Neil
Many times libraries grow up that are only partially congruent and it is
quite convenient to use routines from multiple libraries.
>at the same time, for example. And then there is always routine-id. The
>biggest namespace
routine-id is what I call a foreign attachment to the language..it violates
the letter and the spirit of the language to allow linking to Windows
routines. I recognize the need, but I would very much not like to read too
many more programs that use it...most confusing.
>issue at the moment is that Euphoria halts your program rather than letting
the identifier being
>redefined. The second biggest problem *would* be: Once routines are
overloaded once and
>the original routines are 'included' *again* what should Euphoria do ?
Answer: Overload
>them again. Implementation-wise this would mean, for some 'colliding'
routine names the
>interpreter has to know which of the two include files was included last
*in this current
>namespace* .. so, for the interpreter, a situation as:
>
>include a
> z = special_libfunction (x)
>include b
> z = special_libfunction (x)
>include a
> z = special_libfunction (x)
>
>The first call would be to the function from include file 'a', the second
from include file 'b' and
>the third again from include file 'a'. Assuming both files contain a
function called
>special_libfunction ()
>
This would be an unmitigated disaster(nothing personal :). The interpreter
would have to make multiple passes through the same include for possibly
every shift in library that the programmer wants to use. Ugh! Now, if we
were to extend your original namespace argument by modularizing includes,
the second include of "a" would merely be a switch to a previously parsed
include. I would still prefer the prefix, rather than being dependent on
order of include. I always prefer explicit to implicit measures, but their
is no reason that both approaches cannot be combined.
>This would already *fix* the problem, however, we might, lazy as we are,
forget to include a
>number of files that we _do_ use, but usually are already included and part
of the namespace.
>This is why I suggest modular-namespace. So, in short, the example above
shows how, in my
>eyes, Euphoria should handle 'overloading' .. but I suggest routines from
an include library not
>specifically included by that part of the program should generate an error.
This will force a
>programmer to specify all the include files that he uses in that particular
file ( a library or
>program component), with the result that possible side-effects of changing
the order of
>include files in the main program or any library loaded earlier are simply
not possible.
>
>So, in short, two rules, would solve everything:
> - overloading occurs again and again and again when the include statement
is encountered.
I wasn't sure about the last part of your explanation, but this is clear,
and it just doesn't allow enough flexibility without causing huge overhead.
Overloading should only occur in "unnamed includes of the current type".
Named includes should be prefixed.
> - only identifiers defined in an include file directly included in the
current namespace (the
>current file, ie. a library or program) are accessible.
I agree 100% with this one. Includes embedded in includes are a pain, and
should not be allowed unless somebody can come up with a really elegant,
efficient and painless way to deal with them(a form of modularization might
meet this standard). Include libraries should state their dependencies in
the documentation and it should be the job of the programmer to insure that
those other includes are written in and available. With named includes,
include libraries could be programmed in such a way as to pick up the global
name constant that is a prefix for the routines that they need and plug it
into the include. Probably need to think about that one for a little longer.
>
>This will, in my eyes, be the most clean approach to handle the namespace
issue. It makes
>currently broken programs run, and does not add any new construct to the
language, and
>most of all, when you use it, its quite intuitive.
>
>
>Ralf Nieuwenhuijsen
>
Thanks for the thought provoking post, Ralf.
Everett L.(Rett) Williams
rett at gvtc.com
3. Re: More Namespace (was: little question once again)
Everett Williams wrote:
> routine-id is what I call a foreign attachment to the language..
> it violates the letter and the spirit of the language to allow
> linking to Windows routines.
You didn't mention forward references.
-- David Cuny
4. Re: More Namespace (was: little question once again)
- Posted by nieuwen at XS4ALL.NL
Sep 28, 1999
> >NameSpace
> >=========
> >
> >The current namespace suggestion of prefixing with the include file: it
> will not work with the
> >present programs and librariesnot ? Because they still conflict!
>
> I don't see how they conflict, unless you mean that, unchanged they still
> conflict.
What I mean is, when using Jiri's font library and Neil together, for example,
they conflict.
This would be solved by my solution.
> This is good thinking as far as it goes, but will cause a problem I will
> mention further down.
This is how OO languages, as well as Modula-2, and many many others look at
scope rules.
The part where a 'component' is included should not alter its global namespace,
if it could
then it has to be a integrated part of the program and writing solid 3rd party
libraries would
be impossible. (like it is now, no way to hide everything, except the
programmer's interface,
without a risk of routine collision, unwanted overloading, etc.)
Euphoria currenlty makes one long program out of all the different parts, and
thereby actually
eliminating the potential of programming seperated and isolated components.
> As I suggested in another post, my preference is to allow "named" includes
> to keep the prefixes short. These might be something of the order of
>
> include foo=foo_this_name_is_to_long_to_easily_use.e
This will already make a lot of difference.
> very much like a globally declared constant, which in reality, it is. Now
> everything gets prefixed with foo.
>
> >Plus, it isn't really needed:: no program has to use both the normal
> >graphics routines and Neil
>
> Many times libraries grow up that are only partially congruent and it is
> quite convenient to use routines from multiple libraries.
Yes, but not in the same part of the program. Example:
include graphics.e
-- graphics-like stuff
include neil.e
-- neil graphics like stuff
include graphics.e
-- graphics stuff again
Without adding any new construct to the language we've suddenly accomplished
almost the
same, except for the fact that one routine can't use routines from both includes
at the same
time, however this is easily overcome with even a small wrapper, such as:
include graphics.e
procedure eu_pixel (sequence s, object p)
pixel (s, p)
end procedure
include neil.e
procedure neil_pixel (sequence s, object p)
pixel (s, p)
end procedure
Off course, I would only have to wrap one of the two, it is much cleaner this
way.
> >at the same time, for example. And then there is always routine-id. The
> >biggest namespace
>
> routine-id is what I call a foreign attachment to the language..it violates
> the letter and the spirit of the language to allow linking to Windows
> routines. I recognize the need, but I would very much not like to read too
> many more programs that use it...most confusing.
What I mean is, I wouldn't mind adding an argument to the routine_id that lets
you specify
which include file, although, even that is not really needed. The example above
that wraps the
two pixel routines could also be like:
include graphics.e
constant eu_pixel = routine_id ("pixel")
include neil.e
constant neil_pixe = routine_id ("pixel")
If only Euphoria wouldn't halt your program when identifers get overloaded.
> This would be an unmitigated disaster(nothing personal :). The interpreter
> would have to make multiple passes through the same include for possibly
> every shift in library that the programmer wants to use. Ugh! Now, if we
> were to extend your original namespace argument by modularizing includes,
> the second include of "a" would merely be a switch to a previously parsed
> include. I would still prefer the prefix, rather than being dependent on
> order of include. I always prefer explicit to implicit measures, but their
> is no reason that both approaches cannot be combined.
True, but hte multiple pass thing is very untrue actually.
Think about the way Euphoria currently handles with/withouts.
Imagine your prefix would be added. Whenever it sees an include file, it already
makes a list
of identifers within that namespace. Now, all it has to do is add the prefix of
the include file
loaded last. Where are your multiple passes ?
> >So, in short, two rules, would solve everything:
> > - overloading occurs again and again and again when the include statement
> is encountered.
>
> I wasn't sure about the last part of your explanation, but this is clear,
> and it just doesn't allow enough flexibility without causing huge overhead.
> Overloading should only occur in "unnamed includes of the current type".
> Named includes should be prefixed.
No, off course not. Think about Dos32Lib/Win32Lib, by only changing the include
file, you
can have your program run using a completely different mechanism/gui on a
different
platform. Currenlty, we would still be able to do so, however, what happens when
I also use
some other OO library that also defines identifers such as class, etc. ?
Then I would either need to prefix all routine calls (making a conversion to
dos32lib harder)
or, when my rules would be taken over (my rules ? about a dozen languages
include java use
the same modularization. Isolation is the whole point of seperate include
files), it would
automatically work as we meant without having to change anything or any part,
without
messing with prefixes, or routine pointers.
> > - only identifiers defined in an include file directly included in the
> current namespace (the
> >current file, ie. a library or program) are accessible.
>
> I agree 100% with this one. Includes embedded in includes are a pain, and
> should not be allowed unless somebody can come up with a really elegant,
> efficient and painless way to deal with them(a form of modularization might
> meet this standard). Include libraries should state their dependencies in
> the documentation and it should be the job of the programmer to insure that
> those other includes are written in and available. With named includes,
> include libraries could be programmed in such a way as to pick up the global
> name constant that is a prefix for the routines that they need and plug it
> into the include. Probably need to think about that one for a little longer.
If two libraries collide big time, and the above rule is true, you could simple
split your
program up, and make sure the two libraries are not included at the same time in
some
library.
> Thanks for the thought provoking post, Ralf.
Actually, it was how I first assumed it would work. When I started to understand
the one
huge global namespace junkjard, it confused me.
As simerlar as most expect this to work in the beginning:
{ x, y } = location ()
Although, unlike the modularization, this would be a new thing, where the
modularization is
pretty much a logical standard within programming. (except for asm+++++ (I mean
C) and
the like)
Ralf Nieuwenhuijsen
[[ Email ]]
nieuwen at xs4all.nl
ralf_n at email.com
[[ I-Seek-You ]]
UIN: 9389920
[[ The Elevator ]]
http://www.xs4all.nl/~nieuwen
