1. Namespace Proposal
Here's what I'm planning to do in 2.3 about
the so called "namespace problem".
* First, what is the problem?
In Euphoria, as in all programming languages,
naming conflicts can occur. To reduce these conflicts,
there are mechanisms to reduce the scope of names.
For example, in Euphoria we basically have three
different scopes for user-defined names:
private - visible only within a routine
local - visible only within a file (after the point of declaration)
global - visible everywhere (after the point of declaration)
To keep things simple, we'll ignore keywords, built-in routines,
and loop variables.
This lets you for example, have a private variable x
in one routine, and a private variable x in another
routine, and the two are understood to be different variables.
There is no naming conflict. You can also have a private
variable x, and a global or local variable x.
No problem.
The main problems that have occurred have been with
global symbols. Because they are visible everywhere
(after they are declared), they tend to cause conflicts.
For example, if I add some new global routines or variables
to the standard Euphoria includes, it is very likely that I
will break someone's code, since someone is likely to have
already declared the same symbol in their program. For example,
if I were to add an abs() function to misc.e, it would conflict
with similar abs() functions declared globally and locally in
many people's code.
Similarly, if you try to use two large libraries (include files)
written by different people, there's a chance that a global
symbol in one will conflict with a global or local symbol
in the other. If you have the source, you can edit one of the
includes, but when the author comes out with a new version,
you'd have to re-edit it each time. Not very convenient.
* A solution
To alleviate this situation, I propose:
1. Let a local symbol override a global symbol with
the same name for the duration of the scope
of the local symbol. This is logical when you consider that
private variables already override local and global symbols.
This change alone would greatly reduce the number of conflicts.
2. Allow multiple globals with the same name to
coexist in a program. When you reference
a global you can use its filename as a
qualifier. e.g.
graphics.text_color(RED)
Some have proposed a new syntax such as:
include graphics.e as gr
gr.text_color(RED)
where you get to invent a new name, rather than
rely on the filename. filename's aren't really nice to use,
since on Windows they are case-insensitive.
Also you might have graphics.e and graphics.ew in the
same program. Or for that matter, graphics.xyz
I think that introducing a new name would cause confusion.
Everyone would make up his own new name,
and people would have trouble reading each other's code.
This syntax can be taken further, allowing variations on the include
mechanism to achieve finer control over what symbols are
part of what namespace. I think in a simple language like
Euphoria, we don't need to create a highly-sophisticated
namespace mechanism.
I can see one special case where this proposal will break
existing code. e.g.
integer x
include foo.e
.......... global integer x
x = 99 -- which x?
Currently, the x declared in foo.e will be set to 99.
Under the new proposal, the x at the top of the
main file will be set. I believe this case is extremely rare.
Any suggestions?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
2. Re: Namespace Proposal
Thanks Robert for giving us an opportunity to comment on your proposal.
I'm reading this as I'm having breakfast so please forgive me if my thoughts
aren't crystal clear yet.
>
> * A solution
>
> To alleviate this situation, I propose:
>
> 1. Let a local symbol override a global symbol with
> the same name for the duration of the scope
> of the local symbol. This is logical when you consider that
> private variables already override local and global symbols.
> This change alone would greatly reduce the number of conflicts.
This seems okay.
> 2. Allow multiple globals with the same name to
> coexist in a program. When you reference
> a global you can use its filename as a
> qualifier. e.g.
> graphics.text_color(RED)
One implication is that if the file name changes then I have to go an edit
my code to use the new file name. I might not have control of the filenames
either.
Another implication is that I can only refer to names declared by one file
but there might be more than one file included, just the extentions are
differrent.
Example:
The file "xyz.e" is ...
global constant aaa = 1
The file "xyz.ew" is ...
include xyz.e
global constant aaa = 2
The file "myprog.exw" is ...
include xyz.ew
constant xxx = xyz.aaa -- Which 'aaa' does this refer to?
Will constants, variables and routines all share the same namespace?
> Some have proposed a new syntax such as:
>
> include graphics.e as gr
>
> gr.text_color(RED)
>
> where you get to invent a new name, rather than
> rely on the filename. filename's aren't really nice to use,
> since on Windows they are case-insensitive.
> Also you might have graphics.e and graphics.ew in the
> same program. Or for that matter, graphics.xyz
This is my issue raised above.
> I think that introducing a new name would cause confusion.
> Everyone would make up his own new name,
> and people would have trouble reading each other's code.
Why would people have trouble? What is the difference in ...
include graphics.e
include mygraphics.e
a = text_color(RED)
b = my_text_color(RED)
and
include graphics.e as rds
include mygraphics.e as my
a = rds.text_color(RED)
b = my.text_color(RED)
Are you assuming that programmers aren't clever enough to understand this
syntax?
With the "as xxx" syntax, there is no reason that this cannot co-exist with
the "filename" syntax. Though I don't really recommend this because it could
lead to confusion or ambiguity.
Such that...
include graphics.e
include mygraphics.e as my
a = graphics.text_color(RED)
b = my.text_color(RED)
would be possible.
Another issue I have with just allowing filenames is that they tend to be
longer than necessary for coding, due to other reasons.
Example:
include w32infoattr.ew -- Constants for Win32lib GET/SETINFO message
result = Dispatch(mycntl, "GETINFO", {{w32infoattr.Maximum,
w32infoattr.Minimum}})
this can become rather wordy. how about this instead...
include w32infoattr.ew as prop -- Constants for Win32lib GET/SETINFO
message
result = Dispatch(mycntl, "GETINFO", {{prop.Maximum, prop.Minimum}})
> This syntax can be taken further, allowing variations on the include
> mechanism to achieve finer control over what symbols are
> part of what namespace. I think in a simple language like
> Euphoria, we don't need to create a highly-sophisticated
> namespace mechanism.
Why is "simple" and "highly-sophisticated" mutually exclusive?
Does this also mean that you regard Euphoria as a language only suitable for
simple programs? Meaning that if we have a complex program to write, we
should consider other languages.
Another alternative to both these suggestions is to let the include file
define its own namespace.
Example:
--Have this line near the top of graphics.e
namespace rds
--Have this line near the top of w32graphics.ew
namespace w32
then a user's program could have ...
include graphics.e
include w32graphics.e
a = rds.text_color(rds.RED)
b = w32.text_color(w32.RED)
The idea being that the "namespace" directive would create a namespace if it
didn't exist or use it if it had already been created, and then global names
would go in to that. You could have multiple "namespace" directives in the
same include file, naming different namespaces.
Eg:
namespace rdsC
global constant RED = 1
namespace rdsF
global function text_color(integer color)
------------
include graphics.e
a = rdsF.text_color(rdsC.RED)
Also, by using a namespace that already exists, it means that a related set
of files could all share the same namespace thus possibly increasing code
legibility.
include file.e
include get.e
a = rds.prompt_string(rds.current_dir())
rather than..
a = get.prompt_string(file.current_dir())
> I can see one special case where this proposal will break
> existing code. e.g.
>
> integer x
>
> include foo.e
> .......... global integer x
>
> x = 99 -- which x?
>
> Currently, the x declared in foo.e will be set to 99.
> Under the new proposal, the x at the top of the
> main file will be set. I believe this case is extremely rare.
You're probably right with this exception.
In summary, I believe that greater utility, at no significant cost, would be
provided if the namespace name and the file name were uncoupled. This could
be provided with either the "as name" syntax or the "namespace name" syntax.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
3. Re: Namespace Proposal
Excellent, namespaces are coming :)
> Here's what I'm planning to do in 2.3 about
> the so called "namespace problem".
>
> * First, what is the problem?
>
> In Euphoria, as in all programming languages,
> naming conflicts can occur. To reduce these conflicts,
> there are mechanisms to reduce the scope of names.
> For example, in Euphoria we basically have three
> different scopes for user-defined names:
>
> private - visible only within a routine
>
> local - visible only within a file (after the point of declaration)
>
> global - visible everywhere (after the point of declaration)
>
> To keep things simple, we'll ignore keywords, built-in routines,
> and loop variables.
>
> This lets you for example, have a private variable x
> in one routine, and a private variable x in another
> routine, and the two are understood to be different variables.
> There is no naming conflict. You can also have a private
> variable x, and a global or local variable x.
> No problem.
>
> The main problems that have occurred have been with
> global symbols. Because they are visible everywhere
> (after they are declared), they tend to cause conflicts.
>
> For example, if I add some new global routines or variables
> to the standard Euphoria includes, it is very likely that I
> will break someone's code, since someone is likely to have
> already declared the same symbol in their program. For example,
> if I were to add an abs() function to misc.e, it would conflict
> with similar abs() functions declared globally and locally in
> many people's code.
>
> Similarly, if you try to use two large libraries (include files)
> written by different people, there's a chance that a global
> symbol in one will conflict with a global or local symbol
> in the other. If you have the source, you can edit one of the
> includes, but when the author comes out with a new version,
> you'd have to re-edit it each time. Not very convenient.
>
> * A solution
>
> To alleviate this situation, I propose:
>
> 1. Let a local symbol override a global symbol with
> the same name for the duration of the scope
> of the local symbol. This is logical when you consider that
> private variables already override local and global symbols.
> This change alone would greatly reduce the number of conflicts.
Sounds good, better make it a warning though, could lead to some very
nasty bugs...
> 2. Allow multiple globals with the same name to
> coexist in a program. When you reference
> a global you can use its filename as a
> qualifier. e.g.
> graphics.text_color(RED)
>
> Some have proposed a new syntax such as:
>
> include graphics.e as gr
>
> gr.text_color(RED)
>
> where you get to invent a new name, rather than
> rely on the filename. filename's aren't really nice to use,
> since on Windows they are case-insensitive.
> Also you might have graphics.e and graphics.ew in the
> same program. Or for that matter, graphics.xyz
>
> I think that introducing a new name would cause confusion.
> Everyone would make up his own new name,
> and people would have trouble reading each other's code.
>
> This syntax can be taken further, allowing variations on the include
> mechanism to achieve finer control over what symbols are
> part of what namespace. I think in a simple language like
> Euphoria, we don't need to create a highly-sophisticated
> namespace mechanism.
How about some sort of way of defining the namespace with in the file, like:
namespace <name>
end namespace
or maybe something more along the lines of the "with" statement
(effects the whole file). Also I do like the:
include <file> as <name>
Maybe that could also be added, it would override the namespace set in
the file or could be used for files that don't have namespaces...
I really don't like the idea of having the namespace set by the
filename of the include, it's quite possible that 2 files with exactly
the same name get included, they could be in different directories (I
tend to do that, have files spread out over lots of directories to help
organize things better).
> I can see one special case where this proposal will break
> existing code. e.g.
>
> integer x
>
> include foo.e
> .......... global integer x
>
> x = 99 -- which x?
>
> Currently, the x declared in foo.e will be set to 99.
> Under the new proposal, the x at the top of the
> main file will be set. I believe this case is extremely rare.
>
> Any suggestions?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Looking forward to the new version :)
Thomas Parslow (PatRat) ICQ #:26359483
Rat Software
http://www.rat-software.com/
Please leave quoted text in place when replying
4. Re: Namespace Proposal
----- Original Message -----
From: Robert Craig <rds at RapidEuphoria.com>
Subject: Namespace Proposal
> Here's what I'm planning to do in 2.3 about
> the so called "namespace problem".
<snip>
> * A solution
>
> To alleviate this situation, I propose:
>
> 1. Let a local symbol override a global symbol with
> the same name for the duration of the scope
> of the local symbol. This is logical when you consider that
> private variables already override local and global symbols.
> This change alone would greatly reduce the number of conflicts.
A symbol declared inside a routine overrides one declared in the file.
That seems to cause no real problems. Likewise, an unqualified symbol
declared in the file should override a global symbol imported from
elsewhere.
> 2. Allow multiple globals with the same name to
> coexist in a program. When you reference
> a global you can use its filename as a
> qualifier. e.g.
> graphics.text_color(RED)
>
> Some have proposed a new syntax such as:
>
> include graphics.e as gr
>
> gr.text_color(RED)
>
> where you get to invent a new name, rather than
> rely on the filename. filename's aren't really nice to use,
> since on Windows they are case-insensitive.
> Also you might have graphics.e and graphics.ew in the
> same program. Or for that matter, graphics.xyz
>
> I think that introducing a new name would cause confusion.
> Everyone would make up his own new name,
> and people would have trouble reading each other's code.
Actually, less confusion, I believe. It's harder to come up with a unique
name for a
file than for a variable - for example graphics.e and graphics.ew.
Renaming one of the files is _not_ a workable solution.
Automatically prefixing the names of all imported variables with a
user-defined name is the most attractive solution to me, e.g:
include graphics.e as rds
text_color(rds.RED) -- pretty obvious who's version of RED we mean.
That's only a small part of the namespacing problem, however. If you're
fixing things, have a look at this:
Here's the kind of thing that drives me back to Delphi: I have a program
that uses 4 files:
customer.e
supplier.e
employee.e
products.e
Each of the files has fields which are logically indexed by [NAME].
Since the position of the [NAME] field differs in each file, they all have
to be
fully qualified in their individual files:
[CUST_NAME] = 2, [PROD_NAME] = 4, [EMP_NAME] = 1...
So I wind up with code like:
printf(1,"...",{customer[CUST_NAME],customer[CUST_ADDR],
customer[CUST_CITY],customer[CUST_STATE],customer[CUST_ZIP],employee[EMP_NAM
E]...}) -- erk!
When using Pascal or Delphi, I can write the same thing as:
with customer do
writeln(name,addr,city,state,zip,employee.name)
Which do you consider more confusing?
Note how neatly the dot notation takes precedence over the scoped
"with ... do". And how much less typing is involved. I don't see anything
confusing about that..
> I can see one special case where this proposal will break
> existing code. e.g.
>
> integer x
>
> include foo.e
> .......... global integer x
>
> x = 99 -- which x?
> Currently, the x declared in foo.e will be set to 99.
> Under the new proposal, the x at the top of the
> main file will be set. I believe this case is extremely rare.
> Any suggestions?
Consistency is good.
I think it should always be the 'nearest' x, that is, the one inside the
routine,
if one exists, if not then the one inside the file, if it exists, then the
global.
There could be a warning along the lines of 'local x takes precedence over
global x from graphics.e' , if you wish, although we don't have them for
routines now, and people don't seem to have much problem grasping that
concept.
Regards,
Irv
5. Re: Namespace Proposal
Howdy y'all!
Here, I feel that I must agree with Derek that the "namespace" idea would be
best. The biggest reason for this would be uniformity, especially among any
future libraries which would implement the namespace system.
For instance, suppose that win32lib.ew used the namespace "win." Now then, the
name for this namespace would be set within the include file itself, not within
the user's code. This would make other people's code more readable, in my
opinion, because it would "standardize" the win namespace with win32lib.ew.
For instance, with the namespace being declared in the win32lib.ew include
file, anyone familiar with that library would be able to see its use in Mr.
Jones' program:
include win32lib.ew
sequence
theVersion
theVersion = win.getWin32libVersion()
If the user declares the namespace, the user might declare such a namespace as
"win," or "win32", or "winnythepoo." That, I feel, would make it much harder
for others to read the code.
The only problem I can see with namespaces is that, in a way, it only jacks the
conflict up to a higher level. What if file A declares the namespace "myFile,"
and file B declares the namespace "myFile"? Will this be considered a naming
conflict, or will file B's symbols be added to the namespace previously created
by file A?
Another question would be scoping. In the following example, what would be the
result?
-- myLib.ew
include myFirstLib
namespace myLib
include mySecondLib.ew
-- end of code
Now, let's assume that the only namespace declared is in myLib. Would symbols
in myFirstLib be in the global namespace and symbols for mySecondLib be in the
myLib namespace? If mySecondLib has the namespace "Second" declared, would
"Second" therefore be a subset of the "myLib" namespace? I fear there would be
a lot of hashing out syntax using this setup.
All things considered, I know I would be a lot more comfortable using the
namespace system, and I do feel that, as much trouble as it will be to setup
and implement, it would be the most readable of the proposals I've seen thus
far, as it would provide with a namespace standarization of libraries -- when
the reader of my code sees the "win" namespace, or the "obj" (objecteu(?))
namespace, the reader knows exactly where it's coming from, without hesitation.
With Best Regards,
Travis Beaty
Claude, Texas.
6. Re: Namespace Proposal
I noticed some mention on the topic of dot notation.
If dot-notation is so important
this.variable
this.sequence
this.integer
this.atom
this.routine_id (hehe yeah right)
would be fine with me.....
Euman
euman at bellsouth.net
7. Re: Namespace Proposal
----- Original Message -----
From: Travis Beaty <travisbeaty at arn.net>
>
> For instance, suppose that win32lib.ew used the namespace "win." Now
then, the
> name for this namespace would be set within the include file itself, not
within
> the user's code. This would make other people's code more readable, in my
> opinion, because it would "standardize" the win namespace with
win32lib.ew.
Disagree, see below.
> The only problem I can see with namespaces is that, in a way, it only
jacks the
> conflict up to a higher level.
That is exactly the problem. If we all could cooperate, we would already
take
pains to always name our variables *differently* from everyone else's
variables.
That doesn't happen now, so why should we expect it to suddenly work in the
future when even more people are writing Euphoria code?
How do you prevent me from namespacing my include file in the "win"
namespace also? You would just have to go in and change it - making things
even more confusing, since your program code would have no indication that
such a thing had been done.(assuming my code wasn't shrouded, in which case
you would be s.o.l.)
Unless someone wants to set up an UNCLE (Universal Namespace CLearinghouse
for Euphoria) Organization, with broad enforcement powers, I think it will
work much better if we are allowed to rename at the time we do the include.
There's no reason that doing so would make code harder to understand After
all, the naming would take place right out in the open at the top of the
file, where anyone could (and should) read it - not hidden away somewhere
else, making you read
all the include files to find it.
Regards,
Irv
8. Re: Namespace Proposal
On 22 Jun 2001, at 22:51, Euman wrote:
>
> I noticed some mention on the topic of dot notation.
>
> If dot-notation is so important
>
> this.variable
> this.sequence
> this.integer
> this.atom
> this.routine_id (hehe yeah right)
You know, that would sure make it easy to do this:
s = this.*
Kat
9. Re: Namespace Proposal
Howdy y'all!
> That is exactly the problem. If we all could cooperate, we would already
> take
> pains to always name our variables *differently* from everyone else's
> variables.
> That doesn't happen now, so why should we expect it to suddenly work in the
> future when even more people are writing Euphoria code?
Hmmmm. I can see your point. I guess for clarification about this, I should
ask how possible namespace clashes are handled in, say, C++. Does C++ have a
convention when it comes to declaring namespaces (other than std of course)?
If the system in C++ works, perhaps we should adopt a similar policy. If it
doesn't work, then we should not implement it. Basically, I am not real
adamant on how namespaces should be implemented, but I agree that they should
be implemented.
On the subject of name decoration, I have tried to do that as much as possible;
however, as I've come from a Pascal background, I have a habit of creating
those wonderful three-mile-long variable names ... so, a constant named
TRAVIS_NEWGRAPHIC_PIXELLOC_X doesn't scare me all that much (although *I*
wouldn't do that!!). However, the C'sters out there try to keep their variable
names as short as possible, I've found, so name decoration would undoubtedly
not be on their list of Utopic fixes.
> How do you prevent me from namespacing my include file in the "win"
> namespace also? You would just have to go in and change it - making things
> even more confusing, since your program code would have no indication that
> such a thing had been done.(assuming my code wasn't shrouded, in which case
> you
> would be s.o.l.)
You make a valid point here as well. I *suppose* that if that were done, of
course the symbols of your include file would be added to win32lib's namespace
come hell or high water, at which time name clashes could occur. And, if
you're code was shrouded, that would be a humdinger, wouldn't it? On one hand,
it would be a matter of "the meaner dog wins," because if you have a new seldom
used library clashing with win32lib.ew, chances are that the voice of the Grand
Euphorium would have the author of the new, seldom-used library change it. On
the other hand, if you have two libraries of equal use which clash, therein
lies the one nasty pickle. In that case, one could simply state as a
"Euphorian Code of Namespace Ethics" that whichever library was developed first
keeps the namespace name. Basically, seniority. If a coder does not wish to
follow this, and instead decides that he or she **will** use the win namespace,
then they will find that their library becomes little used or used only in
programs which do not incorporate win32lib.ew.
I guess an example of this would be if I wrote a library which did not have one
routine name shorter than 50 characters, and this library was shrouded. It
might be useful, but would people use it with routine names such as
thisHereIsAVeryVeryLongRoutineNameJustToPissPeopleOff()? Just as this would
irk people, so would the namespace clash cited above.
> Unless someone wants to set up an UNCLE (Universal Namespace CLearinghouse
> for Euphoria) Organization, with broad enforcement powers, I think it will
> work much better if we are allowed to rename at the time we do the include.
There would be no need for UNCLE ... the seniority rule would really be self-
policing, to an extent.
> There's no reason that doing so would make code harder to understand After
> all, the naming would take place right out in the open at the top of the
> file, where anyone could (and should) read it - not hidden away somewhere
> else, making you read
> all the include files to find it.
In some ways, this is certainly true. However, since half the time, our eyes
control our brains, it would be so easy to read this include file:
include win32lib.ew as win
win.getOpenFileName()
then read this include file:
include win32lib.ew as gui
gui.getOpenFileName()
and then instantly deduce that win.getOpenFileName() and gui.getOpenFileName()
are two different routines.
Just my two cents there ... I can still be talked into defecting! hehehe
Travis Beaty
Claude, Texas.
10. Re: Namespace Proposal
- Posted by aku at inbox.as
Jun 22, 2001
In My Humble Opinion:
include "misc.e" -- will include in global namespace
? PI
include "graphics.e" as abc -- include in abc namespace
abc.sound(500)
with abc
sound(500) -- same as abc.sound(500)
end with
namespace def
function func()
return 500
end function
global atom wow
wow = 400
namespace ghi
atom some
some = 123
end namespace
end namespace
? def.func() -- 500
? def.wow -- 400
? def.ghi.some -- 123
? def.ghi.wow -- 400 (because declared as global)
? wow -- error
with def
with ghi
? some -- 123
end with
end with
with def.ghi
? some -- 123
end with
# contents of file shape.e ---------------------
global object x = 50 -- i hope in 2.3 it is legal
namespace square
atom W = 100, L = 200
end namespace
namespace other
atom W = 111
function L() return 222 end function
end namespace
global atom GLOBALALL = 44444
# end contents --------------------
include "shape.e" as form
? form.x -- 50
? form.square.W -- 100
? form.other.L() -- 222
? form.other.x -- 50 (because global)
? GLOBALALL -- 44444 (if in the include file not in namespace,
-- variable will become global)
11. Re: Namespace Proposal
Here's my ideas:
Let files redefine functions, procedures, variavles etc. for example:
include somefile.e
-----------contents of somefile.e-----------------
global procedure someproc(integer a, sequence b)
? a+b
end procedure
-----------end of somefile.e--------------
someproc(10, {20, 30}) --refers to someproc in somefile.e
procedure someproc(integer a, sequence b)
? a-b
end procedure
someproc(10, {20,30}) --refers to local someproc
---end of file---
that way, if two files both have global procedures (functions, constants,
variables, types) of the same name, the most recently included file will
override the one included before it. If you want to use both, then this is
one way of doing it:
include somefile.e as sf
sf.someproc(10, {20, 30})
you can define namespaces, for example:
namespace xyz
include xyz.e
integer myvar
end namespace
xyz.myvar = xyz.myfunction() --where myfunction() is in xyz.e
This would have the same effect, but you could have any code in between
<namespace> and <end namespace>.
If two functions (procedures etc) are declared with the same name, each
taking a different number of parameters, allow function overloading. For
example:
------start of file---------
procedure myproc(integer a)
--some code here
end procedure
procedure myproc(integer a, object b)
--some code here
end procedure
myproc(1) --the first myproc
myproc(1, 2) --the second myproc
------end of file---------
This would allow you to have procedures or functions that take differing
numbers of parameters. Functions and procedures could also be on seperate
namespaces. For example:
-----start of file------
procedure abc(integer a, atom b)
--some code here
end procedure
function abc(integer a, atom b)
--some code here
end function
abc(1, 2.5) --call the procedure
? abc(1, 2.5) --call the function
constant const1 = abc(123, 456) --call the function
-------end of file---------
These enhancememts, together with <include x.e as y> and <namespace...end
namespace> will solve all name conflicts.
And here's another thing:
--------
include file.ew as file
---------file.ew----------
namespace name
integer xyz
end namespace
--------end of file.ew-------
file.name.xyz = 1
-------
In this example, there is "recursive namespaces". Would this be supported?
Or is it a bad idea?
I would apreciate any comments about these ideas.
Long live Euphoria
Daryl Van Den Brink
12. Re: Namespace Proposal
Dear Eu users,
Just my point of view.
If there is no conflict, there is no any problem. No ?
So, *interpreter* must see on situation, only if there
*is* the **concrete** conflict in the ***new*** program.
Suppose, I use library1.e and library2.e
-------prog1.ex
include library1.e
include library2.e
integer My
My=1
-------end prog1.ex
Run prog1.ex under Eu 2.3 control 
See warning message:
"Symbol My is defined as global in library1.e, rename yours new one
or use that old one as a.My"
"Symbol My is defined as global in library2.e, rename yours new one
or use that old one as b.My"
You can choice, rename new variable or use the old good symbol under
recommended simplest syntax.
Explanation of the notation char.My is very clear
a -- this is the first conflict of My symbols in the *new* program and in
library1.e
b -- this is the second conflict of My symbols in the *new* program and in
library2.e
c -- this is the next and so on.
I don't know, maybe this variant is well known and
an old one, but I like it.
I don't like the *superglobal* variant of automated
main-fail priority.
Global is global. No ?
Regards,
Igor Kachan
kinz at peterlink.ru
13. Re: Namespace Proposal
On Saturday 23 June 2001 05:28, Igor Kachan wrote:
<snip good idea>
> I don't like the *superglobal* variant of automated
> main-fail priority.
>
> Global is global. No ?
Not really - consider this:
------ file.a --------
global atom pi
pi = 3.14159
-------------------
------- main --------
include file.a
object pi -- won't work.
function f()
sequence pi -- works.
pi = "Apple"
return pi
end function
---------------------
Global or not, the mathmatic pi is overriden by the apple pi
in function f.
So the apple pi is local to the function, and takes priority
over the global while we are working within that namespace.
Why should we not be able to have a pi declared in the
main program which is local to "main", and also takes
priority over the global? Consistency is usually good.
For clarity, perhaps it might also be good to require
a specific declaration to prove that we knew what we
were doing when we declared "pi" in the main file.
If our variable is declared as:
"local atom pi" -- no conflict, takes precedence over
global, no warning issued.
"atom pi" -- still takes precedence for consistency's
sake, but a warning is issued if there's a global of the
same name.
If no global exists with the same name, then no warning,
no problem, and this syntax wouldn't break existing code.
Regards,
Irv
14. Re: Namespace Proposal
I think we really need some sort of import mechanism, maybe
with...without although I'd prefer something that just imports all
routines from a namespace into the current file (like "import
<namespace>")
Thomas Parslow (PatRat) ICQ #:26359483
Rat Software
http://www.rat-software.com/
Please leave quoted text in place when replying
15. Re: Namespace Proposal
Hello Irv,
> On Saturday 23 June 2001 05:28, Igor Kachan wrote:
>
> <snip good idea>
>
> > I don't like the *superglobal* variant of automated
> > main-fail priority.
> >
> > Global is global. No ?
>
> Not really - consider this:
>
> ------ file.a --------
> global atom pi
> pi = 3.14159
> -------------------
>
> ------- main --------
> include file.a
>
> object pi -- won't work.
>
> function f()
> sequence pi -- works.
> pi = "Apple"
> return pi
> end function
> ---------------------
>
> Global or not, the mathmatic pi is overriden by the apple pi
> in function f.
> So the apple pi is local to the function, and takes priority
> over the global while we are working within that namespace.
> Why should we not be able to have a pi declared in the
> main program which is local to "main", and also takes
> priority over the global? Consistency is usually good.
>
> For clarity, perhaps it might also be good to require
> a specific declaration to prove that we knew what we
> were doing when we declared "pi" in the main file.
> If our variable is declared as:
>
> "local atom pi" -- no conflict, takes precedence over
> global, no warning issued.
>
> "atom pi" -- still takes precedence for consistency's
> sake, but a warning is issued if there's a global of the
> same name.
>
> If no global exists with the same name, then no warning,
> no problem, and this syntax wouldn't break existing code.
OK, Irv, but there is no keywords "local", "as", "name",
"space" and so on in Eu now.
And for the better understandig we must see onto the
other symbols, i.e. declarations of procedures,
functions and so on.
We can not declare this sort of symbols in procedures
and functions, same as constants and types and
somewhat else.
Try your example for the *constant pi=3.14* or for the
"procedure pi()" and you will not have this
(global ! = global) almost every time now.
How can I explain to the readers of my Russian
translation of the future Eu docs these inconsistencies,
if global may not be global in the main file,
which contains almost nothing new, but includes
win32lib with 10000 global symbols, or all RDS
includes with global procedures and functions,
or Bernie Ryan's eu_engin ?
Really global is global in Eu now and this simple
conception is very well documented by RDS and
the contributors. No ?
Regards,
Igor Kachan
kinz at peterlink.ru
16. Re: Namespace Proposal
What's with structures? I would like to see them in Euphoria someday.
Language is good if code explains itself (if no comments needed).
structure COLOR
integer red
integer green
integer blue
end structure
COLOR color
color.red = 255
color.green = 0
color.blue = 0
? color.red
? color.blue
? color.green
---
In current version of Euphoria, closest I can get to structures is like
this:
constant COLOR_RED = 1
constant COLOR_GREEN = 2
constant COLOR_BLUE = 3
-- Here I describe my structure:
-- 1. integer red
-- 2. integer green
-- 3. integer blue
type COLOR (sequence s)
if length (s) != 3 then
return false
end if
if not integer (s [COLOR_RED]) then
return false
end if
if not integer (s [COLOR_GREEN]) then
return false
end if
if not integer (s [COLOR_BLUE]) then
return false
end if
return true
end type
COLOR color
color = {255, 0, 0}
? color [COLOR_RED]
? color [COLOR_GREEN]
? color [COLOR_BLUE]
17. Re: Namespace Proposal
One thing that Euphoria doesn't handle gracefully is large libraries. You
currently have two options:
1. Use a large file, and have local names.
2. Use several smaller files, and have global names.
Option 1 leads to things like the monolithic Win32Lib file. Option 2 leads
to pollution the global namespace with what rightfully should be locals.
I was hoping the namespace solution would address this, but it doesn't,
really. So I'd like to propose a modest addition:
include <filename> as <alias>
For example, if Win32Lib was broken up into 3 parts, you could write:
include win32lib1.ew as win32lib.ew
include win32lib2.ew as win32lib.ew
include win32lib3.ew as win32lib.ew
and it would treat these as if they were part of the same file. This would
allow local routines to remain local, instead of becoming global and
'polluting' the global namespace.
Likewise, if you wanted to override the namespace provided by Robert's
option, you could write:
include math_pkg.ex as math
and the routines could be prefixed as 'math' instead of 'math_pkg'.
Finally, I'm a bit concerned about using filenames to provide namespaces. As
people have mentioned, there are issues about case sensitivity on different
platforms. Plus, filenames don't necessarily make good prefixes.
-- David Cuny
18. Re: Namespace Proposal
I liked Jeff Fieldings idea for a common procedure/function
library that was brought up months ago.
Is this still on Source-Forge?
Euman
euman at bellsouth.net
