1. Revised Namespace Proposal
I read through the suggestions that people put forward
last week regarding the namespace issue, and
I've come up with a fairly minimal solution
based on what various people seemed to agree on.
Thanks to all who contributed. I'm not going to try to
attach people's names to the various ideas,
since I'd probably get it wrong.
Scope of Symbols:
private: symbols visible within one routine
local: symbols visible within one file
(after the point of declaration)
global: symbols declared with "global" keyword,
they are visible within the whole program
(after the point of declaration)
New Rules:
1. A local symbol will override any global symbol
with the same name. This is currently an error. Everybody seems
to agree that this would be a good thing. It will eliminate many
conflicts. A (suppressible) warning will be issued.
2. You can have multiple global symbols with the same name declared
in different files. This is currently an error. It will no longer
be an error, and no warning will be issued either, since you can't
harm yourself until you actually reference one of the symbols.
If there are two or more globals defined in other earlier files
you'll get an error unless you qualify the name.
e.g.
graphics:x += 1
win32lib:foo()
The ':' symbol is probably a better choice than '.' , in case we
ever get into OOP, structures etc.
A namespace qualifier is created by adding a name to an include
statement, e.g.
include mygraphics.e as graphics
include win32lib.ew as win32lib
I'll also allow quotes around included file names,
in case someone wants to include a name with blanks in it, e.g.
include "Program Files\\myfile.e"
Otherwise the quotes aren't needed,
and blank (whitespace) terminates the file name.
The scope of a namespace qualifier is the file in which it
is created. By specifying a namespace qualifier, you can
later say explicitly which file contains a particular
global symbol you are referencing. Other than creating a
qualifier symbol, this type of include statement is just the
same as other include statements.
A qualifier may only be used to refer to a *global* symbol.
Local symbols can't be accessed from other files.
Within the scope of a local symbol x, or private symbol x,
you can also reference a global x as long as you qualify it,
e.g. myfile:x
Symbol Lookup Algorithm:
Qualified Symbol - namespace:x
1. It must match a previously-declared global symbol in the specified
namespace (included file), otherwise it's an error.
Unqualified Symbol - x
1. Look for x as a private variable in the current routine (if any).
Private vars in a routine are all unique.
2. Look for x as a local or global symbol declared earlier in the current
file. local/global symbols in a file are all unique.
3. Look for x as a global symbol declared earlier in another file.
If there is more than one such x, it's an error since you didn't
qualify it.
This is what I'm prepared to implement for 2.3.
It may be possible to refine this in future releases
once we gain some experience with it.
I know that this doesn't do much to help with breaking up
Win32Lib.ew, since you'll still get a large number of
new globals "polluting" the user's namespace, but
the user can now resolve any global vs. global conflicts
that might occur, and the more common global vs. local
conflicts will be resolved automatically.
If anyone can see a simple way to improve
on this proposal that won't take too much time,
please post it to this list.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
2. Re: Revised Namespace Proposal
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Revised Namespace Proposal
>
> I read through the suggestions that people put forward
> last week regarding the namespace issue, and
> I've come up with a fairly minimal solution
> based on what various people seemed to agree on.
>
> Thanks to all who contributed. I'm not going to try to
> attach people's names to the various ideas,
> since I'd probably get it wrong.
Thanks Robert.
> Scope of Symbols:
>
> private: symbols visible within one routine
>
> local: symbols visible within one file
> (after the point of declaration)
>
> global: symbols declared with "global" keyword,
> they are visible within the whole program
> (after the point of declaration)
>
> New Rules:
>
> 1. A local symbol will override any global symbol
> with the same name. This is currently an error. Everybody seems
> to agree that this would be a good thing. It will eliminate many
> conflicts. A (suppressible) warning will be issued.
This is fine.
> 2. You can have multiple global symbols with the same name declared
> in different files. This is currently an error. It will no longer
> be an error, and no warning will be issued either, since you can't
> harm yourself until you actually reference one of the symbols.
>
> If there are two or more globals defined in other earlier files
> you'll get an error unless you qualify the name.
> e.g.
> graphics:x += 1
> win32lib:foo()
>
> The ':' symbol is probably a better choice than '.' , in case we
> ever get into OOP, structures etc.
Good choice.
> A namespace qualifier is created by adding a name to an include
> statement, e.g.
>
> include mygraphics.e as graphics
> include win32lib.ew as win32lib
What will happen in this case?
include graphics.e as RDS
include machine.e as RDS
> I'll also allow quotes around included file names,
> in case someone wants to include a name with blanks in it, e.g.
>
> include "Program Files\\myfile.e"
>
> Otherwise the quotes aren't needed,
> and blank (whitespace) terminates the file name.
This is a good, except that the quote symbol might imply to some that the
syntax is :
INCLUDE ==> "include" (STRINGLITERAL | STRINGSEQUENCE)
because everywhere else in the language, a string literal can be replaced by
a sequence without error. I can live with this because I'm used to the C
language syntax :
#include "stdlib.h"
but you might want to also consider using a different delimiter than a
quote. Maybe the angle brackets like C also uses, this would also mean you
don't have to "escape" the back-slash character.
include <Program Files\myfile.e>
> The scope of a namespace qualifier is the file in which it
> is created. By specifying a namespace qualifier, you can
> later say explicitly which file contains a particular
> global symbol you are referencing. Other than creating a
> qualifier symbol, this type of include statement is just the
> same as other include statements.
Fine. This will, of course, mean that existing code is not effected.
> A qualifier may only be used to refer to a *global* symbol.
> Local symbols can't be accessed from other files.
Excellent. We need this protection.
> Within the scope of a local symbol x, or private symbol x,
> you can also reference a global x as long as you qualify it,
> e.g. myfile:x
I don't suppose you can stretch this have some mechanism to allow accessing
a local symbol x within the scope of a private symbol x? Just for
orthoganality reasons if nothing else? Maybe a NULL namespace qualifier...
object x
procedure abc()
object x
x = :x
. . .
end procedure
> Symbol Lookup Algorithm:
>
> Qualified Symbol - namespace:x
>
> 1. It must match a previously-declared global symbol in the specified
> namespace (included file), otherwise it's an error.
Makes sense.
> Unqualified Symbol - x
>
> 1. Look for x as a private variable in the current routine (if any).
> Private vars in a routine are all unique.
>
> 2. Look for x as a local or global symbol declared earlier in the
current
> file. local/global symbols in a file are all unique.
>
> 3. Look for x as a global symbol declared earlier in another file.
> If there is more than one such x, it's an error since you didn't
> qualify it.
Does this last rule mean that this would work? ...
include graphics.e as gr
text_color(RED)
or *must* we use the namespace if we declared one?...
gr:text_color(gr:RED)
> This is what I'm prepared to implement for 2.3.
> It may be possible to refine this in future releases
> once we gain some experience with it.
Wise move.
> I know that this doesn't do much to help with breaking up
> Win32Lib.ew, since you'll still get a large number of
> new globals "polluting" the user's namespace, but
> the user can now resolve any global vs. global conflicts
> that might occur, and the more common global vs. local
> conflicts will be resolved automatically.
Well it doesn't make it worse. The largest area of name clashes is in the
use of the standard Microsoft symbol names. If two files, independantly
written by two different people, both declare
global constant WM_KEYDOWN = #333
under the current rules we get an error, and under the new rules somebody is
forced to qualify their references. But clearly the interpreter can see that
these CONSTANTS have both the same name AND the same value so therefore
represent the same thing. It should help us coders out here by silently
allowing references to this symbol go without interrupting us with silly
error messages.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
3. Re: Revised Namespace Proposal
Just had another thought.
> A namespace qualifier is created by adding a name to an include
> statement, e.g.
>
> include mygraphics.e as graphics
> include win32lib.ew as win32lib
>
In my mind, the "as" keyword suggests the wrong metaphor. In English, "as"
seems to denote a renaming or alias operation, like "I know John as Bob".
Whereas I view the namespace as a type of container. A very different
metaphor. Thus when I see
include graphics.e as RDS
I'm thinking along the lines that the global names inside graphics.e are
being placed into the container called RDS, and not that graphics.e has an
alias of RDS. This means that the sentence
RDS:text_color(RED)
to me reads like "find the symbol called 'text_color' inside the container
called 'RDS'"
All this ramble is just a long way of saying that I would prefer a different
keyword than "as". Maybe "into"? But that all depends on the metaphor that
you are espousing I suppose.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
4. Re: Revised Namespace Proposal
Hi Bernie,
----- Original Message -----
From: "Bernie Ryan" <xotron at localnet.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Revised Namespace Proposal
>
> Robert Craig wrote:
> > I'll also allow quotes around included file names,
> > in case someone wants to include a name with blanks in it, e.g.
> >
> > include "Program Files\\myfile.e"
> >
> > Otherwise the quotes aren't needed,
> > and blank (whitespace) terminates the file name.
>
> Rob:
> I think this is NOT a good idea.
I don't understand your concern, Bernie. And definitely not the strength of
your concern!
> I see no necessary use for this feature.
The Microsoft operating systems that I use support blanks in directory
names. And I believe that Linux also supports them. Are you saying that
Euphoria should not support the capabilities of the Operating Systems that
it run on?
> I think it is going to come back to haunt you
> and cause errors for your DOS users.
Under what circumstances would this "haunt" Robert? I can't think of any
off-hand.
What specific errors would it cause DOS users? I can't think of any of those
either?
> This create unnecessary questions and errors.
Like what "questions"? My reading of Robert's proposal is that the quotation
marks are optional. If you don't use them, that's fine. If you do, then
that's fine too!
Like what "errors"? It won't break any existing code.
> I will bet if you conduct a survey not .05% of
> the users will need this.
I believe that this proposal comes under the heading of "low hanging fruit".
Its almost trivial to upgrade Euphoria to have this ability to support the
native Operating System thus.
What would happen if we applied your criteria to other features of Euphoria?
Anyone voting for "float64_to_atom", "arccos", "set_vector", "xor_bits"?
And what exactly is wrong with meeting the needs of 0.05% of your customers
if it doesn't cost much nor affect anybody else?
One side effect of this proposal is that people might actually start taking
advantage of the naming capabilities of the Operating System they are using
rather than Euphoria forcing them to use a subset of the possibilities. Is
that what you are concerned about?
> Please only add the features that everyone really needs.
Must Robert only add features the "everybody" needs? That is very
restrictive, in my opinion.
Maybe you could help me out by explaining your concerns in a little more
detail.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
5. Re: Revised Namespace Proposal
- Posted by rforno at tutopia.com
Jul 05, 2001
Excellent, Rob! I followed with interest the discussion on namespaces,
though I didn't provide any suggestions, but I think your proposal is simple
enough and solves most of the problems.
By the way, I have not seen any answer to my request relating to 'trace'. (I
asked that, once one selects variables to trace, they do not get replaced by
others by the interpreter. Moreover, I suggested that at least expressions
of the form variable[index1][index2]... be allowed as traceable).
Thanks in advance for your comments.
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Revised Namespace Proposal
>
>
> I read through the suggestions that people put forward
> last week regarding the namespace issue, and
> I've come up with a fairly minimal solution
> based on what various people seemed to agree on.
>
> Thanks to all who contributed. I'm not going to try to
> attach people's names to the various ideas,
> since I'd probably get it wrong.
>
> Scope of Symbols:
>
> private: symbols visible within one routine
>
> local: symbols visible within one file
> (after the point of declaration)
>
> global: symbols declared with "global" keyword,
> they are visible within the whole program
> (after the point of declaration)
>
> New Rules:
>
> 1. A local symbol will override any global symbol
> with the same name. This is currently an error. Everybody seems
> to agree that this would be a good thing. It will eliminate many
> conflicts. A (suppressible) warning will be issued.
>
> 2. You can have multiple global symbols with the same name declared
> in different files. This is currently an error. It will no longer
> be an error, and no warning will be issued either, since you can't
> harm yourself until you actually reference one of the symbols.
>
> If there are two or more globals defined in other earlier files
> you'll get an error unless you qualify the name.
> e.g.
> graphics:x += 1
> win32lib:foo()
>
> The ':' symbol is probably a better choice than '.' , in case we
> ever get into OOP, structures etc.
>
> A namespace qualifier is created by adding a name to an include
> statement, e.g.
>
> include mygraphics.e as graphics
> include win32lib.ew as win32lib
>
> I'll also allow quotes around included file names,
> in case someone wants to include a name with blanks in it, e.g.
>
> include "Program Files\\myfile.e"
>
> Otherwise the quotes aren't needed,
> and blank (whitespace) terminates the file name.
>
> The scope of a namespace qualifier is the file in which it
> is created. By specifying a namespace qualifier, you can
> later say explicitly which file contains a particular
> global symbol you are referencing. Other than creating a
> qualifier symbol, this type of include statement is just the
<snip>
> file. local/global symbols in a file are all unique.
>
> 3. Look for x as a global symbol declared earlier in another file.
> If there is more than one such x, it's an error since you didn't
> qualify it.
>
> This is what I'm prepared to implement for 2.3.
> It may be possible to refine this in future releases
> once we gain some experience with it.
>
> I know that this doesn't do much to help with breaking up
> Win32Lib.ew, since you'll still get a large number of
> new globals "polluting" the user's namespace, but
> the user can now resolve any global vs. global conflicts
> that might occur, and the more common global vs. local
> conflicts will be resolved automatically.
>
> If anyone can see a simple way to improve
> on this proposal that won't take too much time,
> please post it to this list.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
>
6. Re: Revised Namespace Proposal
- Posted by rforno at tutopia.com
Jul 05, 2001
I don't see why the feature will cause problems to DOS users. Please
explain.
----- Original Message -----
From: "Bernie Ryan" <xotron at localnet.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Revised Namespace Proposal
>
>
>
> Robert Craig wrote:
> > I'll also allow quotes around included file names,
> > in case someone wants to include a name with blanks in it, e.g.
> >
> > include "Program Files\\myfile.e"
> >
> > Otherwise the quotes aren't needed,
> > and blank (whitespace) terminates the file name.
>
> Rob:
> I think this is NOT a good idea.
> I see no necessary use for this feature.
> I think it is going to come back to haunt you
> and cause errors for your DOS users.
> This create unnecessary questions and errors.
> I will bet if you conduct a survey not .05% of
> the users will need this.
> Please only add the features that everyone really needs.
>
> Bernie
>
>
>
>
>
7. Re: Revised Namespace Proposal
Couldn't a lfn (including blanks) be converted to the internal DOS 8.3 name,
which is what Windows actually does? Then 'Program Files' becomes
'progra~1', and everybody's happy...
Gerardo
----- Original Message -----
From: "Bernie Ryan" <xotron at localnet.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Revised Namespace Proposal
> Robert Craig wrote:
> > I'll also allow quotes around included file names,
> > in case someone wants to include a name with blanks in it, e.g.
> >
> > include "Program Files\\myfile.e"
> >
> > Otherwise the quotes aren't needed,
> > and blank (whitespace) terminates the file name.
>
> Rob:
> I think this is NOT a good idea.
> I see no necessary use for this feature.
> I think it is going to come back to haunt you
> and cause errors for your DOS users.
> This create unnecessary questions and errors.
> I will bet if you conduct a survey not .05% of
> the users will need this.
> Please only add the features that everyone really needs.
>
> Bernie
8. Re: Revised Namespace Proposal
rforno writes:
> By the way, I have not seen any answer to my
> request relating to 'trace'. (I asked that, once one
> selects variables to trace, they do not get replaced by
> others by the interpreter.
> Moreover, I suggested that at least expressions
> of the form variable[index1][index2]... be allowed as traceable).
These requests have been recorded, but I don't think
I'll get around to them for 2.3. The trace facility already
attempts to keep the most recently referenced variables
displayed, but I'll see if I can take into account whether
the user asked for them or not.
Displaying subscripted variables is also something
I'd like to do eventually, but probably not for 2.3.
On the bright side, I've already implemented
trace(3). It records executed Euphoria statements in a
trace file, like the Translator does, so if a machine-level crash
occurs, you can see the last 500 Euphoria statements executed,
in particular the statement that was being executed when the
crash ocurred (maybe a poke into a bad address or something).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Revised Namespace Proposal
Robert Craig wrote:
> include win32lib.ew as win32lib
Was there a reason you didn't consider allowing multiple files to share the
same namespace? ie:
include win32a.ew as win32lib
include win32b.ew as win32lib
include win32c.ew as win32lib
That would allow large files (like Win32Lib) to be broken up into several
smaller files, and still conform to the rules you laid out.
-- David Cuny
10. Re: Revised Namespace Proposal
Robert Craig wrote:
> I read through the suggestions that people put forward
> last week regarding the namespace issue, and
> I've come up with a fairly minimal solution
> based on what various people seemed to agree on.
>
> Thanks to all who contributed. I'm not going to try to
> attach people's names to the various ideas,
> since I'd probably get it wrong.
>
> Scope of Symbols:
>
> private: symbols visible within one routine
>
> local: symbols visible within one file
> (after the point of declaration)
>
> global: symbols declared with "global" keyword,
> they are visible within the whole program
> (after the point of declaration)
>
> New Rules:
>
> 1. A local symbol will override any global symbol
> with the same name. This is currently an error. Everybody seems
> to agree that this would be a good thing. It will eliminate many
> conflicts. A (suppressible) warning will be issued.
>
> 2. You can have multiple global symbols with the same name declared
> in different files. This is currently an error. It will no longer
> be an error, and no warning will be issued either, since you can't
> harm yourself until you actually reference one of the symbols.
>
> If there are two or more globals defined in other earlier files
> you'll get an error unless you qualify the name.
> e.g.
> graphics:x += 1
> win32lib:foo()
>
> The ':' symbol is probably a better choice than '.' , in case we
> ever get into OOP, structures etc.
>
> A namespace qualifier is created by adding a name to an include
> statement, e.g.
>
> include mygraphics.e as graphics
> include win32lib.ew as win32lib
>
> I'll also allow quotes around included file names,
> in case someone wants to include a name with blanks in it, e.g.
>
> include "Program Files\\myfile.e"
>
> Otherwise the quotes aren't needed,
> and blank (whitespace) terminates the file name.
>
> The scope of a namespace qualifier is the file in which it
> is created. By specifying a namespace qualifier, you can
> later say explicitly which file contains a particular
> global symbol you are referencing. Other than creating a
> qualifier symbol, this type of include statement is just the
> same as other include statements.
>
> A qualifier may only be used to refer to a *global* symbol.
> Local symbols can't be accessed from other files.
>
> Within the scope of a local symbol x, or private symbol x,
> you can also reference a global x as long as you qualify it,
> e.g. myfile:x
>
> Symbol Lookup Algorithm:
>
> Qualified Symbol - namespace:x
>
> 1. It must match a previously-declared global symbol in the specified
> namespace (included file), otherwise it's an error.
>
> Unqualified Symbol - x
>
> 1. Look for x as a private variable in the current routine (if any).
> Private vars in a routine are all unique.
>
> 2. Look for x as a local or global symbol declared earlier in the
current
> file. local/global symbols in a file are all unique.
>
> 3. Look for x as a global symbol declared earlier in another file.
> If there is more than one such x, it's an error since you didn't
> qualify it.
>
> This is what I'm prepared to implement for 2.3.
> It may be possible to refine this in future releases
> once we gain some experience with it.
>
> I know that this doesn't do much to help with breaking up
> Win32Lib.ew, since you'll still get a large number of
> new globals "polluting" the user's namespace, but
> the user can now resolve any global vs. global conflicts
> that might occur, and the more common global vs. local
> conflicts will be resolved automatically.
>
> If anyone can see a simple way to improve
> on this proposal that won't take too much time,
> please post it to this list.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Just my point of view about the possible simplest solution
(I repeate my old mail to list and add the basic part
of my private mail to Robert ) :
If there is no name 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 ?
Then.
a -- this is prefix for the global name space of library1.e
b -- this is prefix for the global name space of library2.e
a then b -- this is just alphabetic order of comparison,
when compare() is used.
So, for name spaces, there is no need to enter new
commands or keywords into Eu.
And this *order* just the same as libraries are included.
*Order* of including is important to define prefixes.
You can create file:
-----my_names.e
include win32lib.ew -- prefix A -- these are just comments
include misc.xyz -- prefix B -- to remember prefixes
include misc.abc -- prefix C
include misc.abc.xyz -- prefix D
----- end of file
Then :
--- my_new_1.exw
include my_names.e
integer My
My=1
A.My=1000
B.My=2000
C.My=3000
sequence S
S={My, A.My,B.My,C.My}
? S
---- end of file
Delimiter '.' is the most convenient due to it exists
in Eu just now.
You see, separate global names may be implemented
without any new keywords and delimiters and without
change of 'global' keyword definition in docs.
Nobody needs to relearn Eu. New syntax is simplest.
But, Rob, only you can see the whole of situation ...
Best regards,
Igor Kachan
kinz at peterlink.ru
11. Re: Revised Namespace Proposal
> Couldn't a lfn (including blanks) be converted to the internal DOS 8.3
name,
> which is what Windows actually does? Then 'Program Files' becomes
> 'progra~1', and everybody's happy...
>
> Gerardo
What if you have \Program Files and \Program Files2
They get translated to \progra~1 and \progra~2 and you don't know which is
which.
12. Re: Revised Namespace Proposal
Dear Eu users:
<snip>
> Nobody needs to relearn Eu. New syntax is simplest.
>
> But, Rob, only you can see the whole of situation ...
>
> Best regards,
> Igor Kachan
> kinz at peterlink.ru
The single important thing in the name space
problem is the *prefix* for the second global
symbol whith the same name.
I'll use the following method for namespaces,
if Rob will implement his proposal :
1. rename win32lib.ew as a.e
2. rename misc.abc as b.e
3. rename misc.abc.xyz as c.e
4. create the file
-----my_names.e
a.e ---- win32lib.ew -- comments to remember file names
b.e ---- misc.abc
c.e ---- misc.abc.xyz
-----end of file
5. write and run my new program
---- my_prog1.exw
include my_names.e
integer My
My=1
a:My=2
b:My=3
c:My=4
---- end of file
Why not ?
No any problem. No ?
This is just the simple power of
The Euphoria Programming System.
Regards,
Igor Kachan
kinz at peterlink.ru
13. Re: Revised Namespace Proposal
Sorry:
Must be:
-----my_names.e
include a.e ---- win32lib.ew -- comments to remember file names
include b.e ---- misc.abc
include c.e ---- misc.abc.xyz
-----end of file
sorry again and again
Best regards,
Igor Kachan
kinz at peterlink.ru
14. Re: Revised Namespace Proposal
Howdy!
On 5 Jul 2001, at 16:55, Robert Craig wrote:
> I read through the suggestions that people put forward
> last week regarding the namespace issue, and
> I've come up with a fairly minimal solution
> based on what various people seemed to agree on.
<kersnip>
> I'll also allow quotes around included file names,
> in case someone wants to include a name with blanks in it, e.g.
>
> include "Program Files\\myfile.e"
>
> Otherwise the quotes aren't needed,
> and blank (whitespace) terminates the file name.
This is a wonderful idea, Mr. Craig, however I must agree with Derek that
quotations may not be the best delimiters, cause some goofy programmer, like
me, might try this ...
CONSTANT theFile = "program files/thisun.e"
include theFile
I also like Derek's C-like approach, using <> as delimiters.
Also, can this syntax also be used when invoking the interpreter on an ex(w)
file that is located in a directory with the space in the name?
> If anyone can see a simple way to improve
> on this proposal that won't take too much time,
> please post it to this list.
Everything else looks great!
Travis Beaty,
Claude, Texas
15. Re: Revised Namespace Proposal
- Posted by gertie at ad-tek.net
Jul 06, 2001
On 6 Jul 2001, at 10:28, Travis Beaty wrote:
>
> Howdy!
>
>
> On 5 Jul 2001, at 16:55, Robert Craig wrote:
>
> > I read through the suggestions that people put forward
> > last week regarding the namespace issue, and
> > I've come up with a fairly minimal solution
> > based on what various people seemed to agree on.
>
> <kersnip>
>
> > I'll also allow quotes around included file names,
> > in case someone wants to include a name with blanks in it, e.g.
> >
> > include "Program Files\\myfile.e"
> >
> > Otherwise the quotes aren't needed,
> > and blank (whitespace) terminates the file name.
>
> This is a wonderful idea, Mr. Craig, however I must agree with Derek that
> quotations may not be the best delimiters, cause some goofy programmer, like
> me, might try this ...
>
> CONSTANT theFile = "program files/thisun.e"
>
> include theFile
HEY!!! I *like* that one, Travis, great idea!!! Then when we can re-include
files, we are a
step closer to executing variables! Speaking of such,, and turbo pascal,,
let me
toss in the idea of unlinked dynamic overlays for Eu. They could be altered
while
unlinked, and reincluded while running to exec new code?
Btw, one reason i like DDE is that a program that has a DDE name can be shut
down,
recoded, and fired back up with no complaints by the OS when another programs
tries
to send it something while not running. I don't know if windoze drops the bits
into $null
or what, but i routinely kill off DDE instances to free up resources on the
puter in a
crunch, and restart them with no errors. Naturally, the DDE programs handshake
and
know when the other hasn't replied, and deal with it. Executing vars is one way
a
singlethreaded Eu could accomplish the same thing, simply by reloading Travis's
theFile above.
> I also like Derek's C-like approach, using <> as delimiters.
Except that the filename is a sequence, and using <> would break the rule that
sequences are bounded by ". How about {} instead of <>? Since they are a
sequence,
i'd go so far as to make it mandatory that the filename be in "". I use them as
default,
so i don't have to exec the rule "if equal(SpaceInFilename,TRUE) then use quotes
end
if" in my limited wetware.
Kat
16. Re: Revised Namespace Proposal
David Cuny writes:
> Was there a reason you didn't consider
> allowing multiple files to share the
> same namespace? ie:
>
> include win32a.ew as win32lib
> include win32b.ew as win32lib
> include win32c.ew as win32lib
>
> That would allow large files (like Win32Lib) to be
> broken up into several smaller files, and still conform
> to the rules you laid out.
I considered it, but I couldn't see enough advantage to it.
I know you'd like to split Win32Lib.ew into several
separate files, yet somehow group those files together
under the same banner so they can still somehow
act like one file.
I see a superficial way of allowing this, and
a deeper way. Neither seems worth it to me.
Superficially, it would be possible to let many files have the
same namespace qualifier, with no error issued.
Users could write several include statements,
as you've done above, and then refer to *all*
Win32Lib-related symbols as win32lib.xxx.
That would (sort of) hide the
names of the individual Win32Lib files in case
files are removed or new files are added in
the future. It would mean that a namespace
qualifier in the symbol table would refer to a *list*
of files, not one file. Globals would have to be unique
within a list of files. Presumably a
file could belong to many different lists at
various points during the compile. This is
messy to implement. It also means the reader
of the code would have to search through many
different source files when he wanted to
locate the source code for a qualified symbol.
The way that you would code the individual
files would not change. You would still have
to create many new global symbols, polluting
the global namespace.
A deeper way of grouping files would
bind them more tightly,
knocking down the barriers between them.
i.e. they could access the local symbols
of files (in the group) that were included earlier,
without those files having to declare lots of globals.
The existence of a group would
not be declared within the files themselves.
It would be created by the user who lists a bunch of
include-as (or include-into as Derek prefers)
statements. This could get very complicated.
Euphoria compiles an included file when it first sees it,
then ignores subsequent includes of the
same file (this will change in 2.3 so that the namespace
qualifier can be assigned, but we still won't recompile
anything).
Euphoria may have already read in and compiled
aaa.e, then bbb.e, as separate files, and made decisions
about which global symbols bbb.e is supposed to access.
Now you come along with a couple of include-as
statements and you expect that the intermediate code for
bbb.e must be changed retroactively, so it will
pick up local symbols in aaa.e that were
ignored when bbb.e was compiled.
What are you gaining from the added complexity
in the language manual and the implementation?
You are avoiding the introduction of new global
symbols, but we now have a way to resolve any
global conflict. Conversely, you may also be
missing useful opportunities to *hide* locals within
one file from access by all the other files in the group.
I'm just guessing here.
Maybe you had some other idea in mind.
We could add your idea, or something like it,
in the future, but I'd like to go ahead and implement
the basic (not Basic!) stuff first.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: Revised Namespace Proposal
Hi Robert,
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Revised Namespace Proposal
> David Cuny writes:
>
> > Was there a reason you didn't consider
> > allowing multiple files to share the
> > same namespace? ie:
> >
> > include win32a.ew as win32lib
> > include win32b.ew as win32lib
> > include win32c.ew as win32lib
> >
> > That would allow large files (like Win32Lib) to be
> > broken up into several smaller files, and still conform
> > to the rules you laid out.
>
> I considered it, but I couldn't see enough advantage to it.
> I know you'd like to split Win32Lib.ew into several
> separate files, yet somehow group those files together
> under the same banner so they can still somehow
> act like one file.
Another way of do this, without causing issues with the interpreter, is to
allow the "insert" concept as oppossed to the "include" concept. In other
words, allow a file to be inserted at a spot in another file as if it was
actually a part of that file.
For example, in the win32lib.ew file we could have ...
#wina32.ew#
#winb32.ew#
#winc32.ew#
and the interpreter would just have to push the current file handle (or save
the file offset and close the file) then open the "inserted" file and
continue reading from there until EOF, then pop the old file handle back and
continue reading. Logically, the inserted file is a part of the containing
file.
This would then have the effect of "combining" different files at runtime
into a single file and having the normal scoping rules apply. At almost no
cost to the interpreter. I'm assuming of course that you have isolated the
tokenising process to one place and not scattered it around the interpreter.
As a neat side-effect, the syntax I used above allows for the insertion to
take place at ANY spot in the containing file, not just at line boundaries.
Eg.
A file called "w32copyright.ew" contains the single line ...
"Win32lib (c) 2001 David Cuny and " &
then in the file wina32.ew we could have a line like
constant copyrighttext = #w32copyright.ew# " Matt Lewis"
and in the file winb32.ew we could have a line like
constant copyrighttext = #w32copyright.ew# " Paul McCartney"
and in the file winc32.ew we could have a line like
constant copyrighttext = #w32copyright.ew# " Robert Craig"
well, you get the picture.
Later, when you put in v2.4 when you add some fancy stuff, you could allow
"parameters" to be used in inserted file references to implement a sort of
inlining of code.
A file called "dropend.e" contains ...
$1[1 .. length($1) - 1]
then we could use it as ...
seq1 = #dropend.e(seq1)#
seq2 = #dropend.e(seq2)#
but I'm getting ahead of myself.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
18. Re: Revised Namespace Proposal
Robert Craig wrote:
> I'm just guessing here.
> Maybe you had some other idea in mind.
No, that pretty well covers it, and I've got a better grasp of the
complexities. All I really wanted to be able to do was stitch together the
includes as a single file, so a restriction that they includes all be
adjacent wouldn't be an issue.
But the Really Huge(tm) libraries were implemented without the benefit of
namespaces. I suspect that I would have made a number of different design
decisions if namespaces had been available.
> We could add your idea, or something like it,
> in the future, but I'd like to go ahead and implement
> the basic (not Basic!) stuff first.
Thanks. And I'll take care of implementing the Basic stuff.
-- David Cuny
19. Re: Revised Namespace Proposal
Derek Parnell writes:
> Another way of do this, without causing issues
> with the interpreter, is to allow the "insert" concept
> as oppossed to the "include" concept. In other
> words, allow a file to be inserted at a spot in
> another file as if it was actually a part of that file.
This C-style raw include would be easy to implement,
since it's just a subset of what I'm doing now with includes,
and it's kind of hard to argue against it (although
Bjarne Stroustrup himself wishes C didn't have it),
but I think it would muddy the waters as far as the whole include
concept is concerned. Beginners would see that
there are "many" different ways to combine source
files, and they'd be confused. They'd use the raw
include everywhere in their programs because it would
be easier for them to understand. Soon you'd have
a confusing mix of raw vs regular includes everywhere
in the Euphoria world and the whole global vs local
concept would get seriously undermined.
> Later, when you put in v2.4 when you add
> some fancy stuff, you could allow "parameters"
> to be used in inserted file references to implement
> a sort of inlining of code.
We've survived for many years without raw includes,
and without C-like #define preprocessor macros.
Let's see if we can keep going a while longer.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
20. Re: Revised Namespace Proposal
Tone,
----- Original Message -----
From: "Tone Skoda" <tone.skoda at siol.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Revised Namespace Proposal
> > Couldn't a lfn (including blanks) be converted to the internal DOS 8.3
> name,
> > which is what Windows actually does? Then 'Program Files' becomes
> > 'progra~1', and everybody's happy...
> >
> > Gerardo
>
> What if you have \Program Files and \Program Files2
> They get translated to \progra~1 and \progra~2 and you don't know which is
> which.
Of course. Right now a DOS DIR of my Program Files folder includes
MICROS~1 <DIR> 30/07/99 16.41 Microsoft NetShow
MICROS~2 <DIR> 30/07/99 17.10 Microsoft Office
MICROS~3 <DIR> 04/11/99 13.19 Microsoft Batch 98
MICROS~4 <DIR> 21/10/00 21.38 Microsoft GIF Animator
...
NORTON~1 <DIR> 29/08/99 22.27 Norton Utilities
NORTON~2 <DIR> 29/08/99 22.30 Norton Crashguard
NORTON~3 <DIR> 29/08/99 22.30 Norton Web Services
This is obviously not a good solution, but it allows for lfn's without any
basic changes. Most people are running Windows, even if they sometimes work
in DOS, so this is a common occurrence for them. Straight Windows users
wouldn't even notice.
Gerardo
21. Re: Revised Namespace Proposal
Hi Rob,
<snip>
> If there are two or more globals defined in other earlier files
> you'll get an error unless you qualify the name.
> e.g.
> graphics:x += 1
> win32lib:foo()
>
> The ':' symbol is probably a better choice than '.' , in case we
> ever get into OOP, structures etc.
>
> A namespace qualifier is created by adding a name to an include
> statement, e.g.
>
> include mygraphics.e as graphics
> include win32lib.ew as win32lib
<snip>
OK. But it seems now, a namespace qualifier
may contain *delimiter just in the qualifier's body*,
when a namespace qualifier is created.
For example :
'graphics-' or 'graphics.' or 'graphics*'
as user choices.
So syntax may be
include mygraphics.e as a/
include win32lib.ew as b-
include misc.abc.xyz as c.
Delimiter ' : ' is not the best one
due to it requires
two keystrokes -- Shift and key.
No pressure, just a question! (by Travis Beaty
Regards.
Igor Kachan
kinz at peterlink.ru
22. Re: Revised Namespace Proposal
Igor Kachan writes:
> OK. But it seems now, a namespace qualifier
> may contain *delimiter just in the qualifier's body*,
> when a namespace qualifier is created.
>
> For example :
>
> 'graphics-' or 'graphics.' or 'graphics*'
>
> as user choices.
>
> So syntax may be
>
> include mygraphics.e as a/
> include win32lib.ew as b-
> include misc.abc.xyz as c.
Namespace qualifiers would be identifiers,
just like any others in Euphoria (e.g. variable names, routine names.)
They could only consist of letters, digits and underscores,
and upper/lower case would be significant.
All of your examples above would be illegal.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
23. Re: Revised Namespace Proposal
Robert Craig writes:
> Igor Kachan writes:
> > OK. But it seems now, a namespace qualifier
> > may contain *delimiter just in the qualifier's body*,
> > when a namespace qualifier is created.
> >
> > For example :
> >
> > 'graphics-' or 'graphics.' or 'graphics*'
> >
> > as user choices.
> >
> > So syntax may be
> >
> > include mygraphics.e as a/
> > include win32lib.ew as b-
> > include misc.abc.xyz as c.
>
> Namespace qualifiers would be identifiers,
> just like any others in Euphoria (e.g. variable names, routine names.)
> They could only consist of letters, digits and underscores,
> and upper/lower case would be significant.
> All of your examples above would be illegal.
Thanks. OK. But syntax 'abc:xyz' is illegal now for *any*
identifiers. We only can write 'abc' or 'xyz' or 'abcxyz'
So, *new* full identifiers will consist of letters, digits,
underscores *plus* *delimiter* before the second part of
double global name.
This *delimiter* is absolutely *new* legal element of any
new identifier.
What is a reason which makes this new legal element
of a name so rigid ?
This element is only new in the new legal syntax of identifier.
Why new interpreter can not parse
legal_old_name & any_delimiter_is_new_element & second_old_legal_name
if I write for interpreter:
include file.e as legal_old_name&any_delimiter_is_new_element
My question is - is it a complex solution for the parser?
Anyway *delimiter* is not an old legal element of a name.
You must develope new block of your parser for this
delimiter, not for the old good names, I think.
So, this my question is about the new parser's algorithm.
See what I want:
include|blank|file.e|blank|as|blank|qualifier|delimiter|blank
Parser looks for 'include' and the *last blank*.
Delimiter is a byte *before* the *last blank*.
Qualifier is *before* the delimiter.
And delimiter *can be* *any* for the following work
of the parser, parser knows it for the first 'include' now,
same as parser knows qualifier for this 'include'.
And so on.
Why not ?
Sorry, Rob, this question is very interesting for me.
Answer please, if you can.
Regards,
Igor Kachan
kinz at peterlink.ru
24. Re: Revised Namespace Proposal
Igor Kachan writes:
> include file.e as legal_old_name&any_delimiter_is_new_element
>
> My question is - is it a complex solution for the parser?
I'm not sure what you are asking.
You seem to be suggesting that we should allow
more than just ':' as a delimiter on qualified names.
This would confuse people, and could confuse the parser
as well. Imagine if '+' or '-' or '*' or '&' or '/'
were allowed as a delimiter:
x = y+z -- Is that actually y:z or y + z ???
By the way, it is *not* now legal to create symbols
that contain ':', e.g.
integer asdf:xxx -- this is illegal
The rules for forming an identifier remain the same.
We have just created a new kind of "qualified symbol"
that consists of:
identifier:identifier
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
25. Re: Revised Namespace Proposal
Robert Craig writes:
> > include file.e as legal_old_name&any_delimiter_is_new_element
> >
> > My question is - is it a complex solution for the parser?
>
> I'm not sure what you are asking.
> You seem to be suggesting that we should allow
> more than just ':' as a delimiter on qualified names.
Yes, I try to get more than just ':' as a delimiter
on qualified names and get available maximum of new
syntax and keyword abilities now.
The most real new candidates to delimiters are
'.' , '^' , '!', '~' , '@', '%' ,'$' , '|' , '`'.
But delimiter may be almost any sign (not letter, not
digit and not underscore), I am sure now.
> This would confuse people, and could confuse the parser
> as well. Imagine if '+' or '-' or '*' or '&' or '/'
> were allowed as a delimiter:
>
> x = y+z -- Is that actually y:z or y + z ???
Before you ask yours -- Is that actually y:z or y + z ???
interpreter prints 3 error messages about the bad syntax
and 2 run time error messages without any confusion
on your example
To be accurate in the frame of my question about
the Eu parser, see please below :
----file.e
global integer y
----end of file
----prog.ex
include file.e as a+ -- this is delimiter +
integer x, y, z
z=1
y=2
a+y=3 -- this is resolved names conflict
x=a+y+z+y -- this is the wonderful expression
----end of file
Well, I think I am not extravagant enough to choice
'+' as a delimiter, but why not *other convenient*
signs above ? Or just '.' and ':' ?
> By the way, it is *not* now legal to create symbols
> that contain ':', e.g.
>
> integer asdf:xxx -- this is illegal
Yes, Rob, I know, thank you.
> The rules for forming an identifier remain the same.
> We have just created a new kind of "qualified symbol"
> that consists of:
> identifier:identifier
This is the main point. The first part of this new
kind of "qualified symbol" *and* delimiter both keep
too little functional amount of work to be done,
I think.
The identifier&delimiter construction may be not just
a name's prefix now. If you have the new keyword 'as'
in Eu, this construction may be a kind of namespace
operator or special mark up operator.
See what I want now, my appetite grows, sorry, but
this is an example of a flexibility, when you can
*define* *two* or *one* delimiters
with the 'as' operator :
include|blank|file.e|blank|as|blank|
delimiter|qualifier|delimiter|blank|
include|blank|file.e|blank|as|blank|
qualifier|delimiter|blank|
include|blank|as|blank|
qualifier|delimiter|blank|
include|blank|file.e|blank|
---my_lib_file.e
global integer My -- in the current file, scope to the 'include as a:'
My=0 -- this is My #1
include as
a: -- *see one delimiter*
global integer My -- in the current file, scope to the 'include as b:'
My=1 -- this is My #2
include as
b:
global integer My -- in the current file, scope to the end of file
My=2 -- this is My #3
---end of file -- this scheme allows merge libraries into
-- standard big one.
---my_main_file.ex
integer My -- this is My #4,
include my_lib_file.e as :a. -- *see two delimiters*
My=3 -- My #4
a.My=4 -- My #1
a:a.My=5 -- My #2 -- see basic-like "label" a: in file.e
b:a.My=6 -- My #3 -- see basic-like "label" b: in file.e
? {My, a.My, a:a.My, b:a.My}
---end of file
And if you can *define* the *delimiters* with "as" command
and parse them, various notations of some other languages
become available in Eu, if you want these
all notations
Rob, I know that scheme above and real coding
of interpreter are too different things,
but that scheme may be useful too, as
many others, I think.
The new key idea is *defining* of the *delimiters*
with 'as' command. There may be two delimiters
in this scheme -- the first and the second
in the order of blanks from left to right.
And any pair from the set of legal new delimiters
may be parsed and compiled into the internal code
just as 'a' and 'b' to get the new identifier
from the qualifier and the qualified name.
Rob, is this idea too complicated thing for
updating the existent parser and compiler?
Sorry, I know, this *concrete* question is not
simple, so, this is the last *my question* on this
subject and I am patient to wait and get an answer
when 2.3 is ready
Thanks.
Regards,
Igor Kachan
kinz at peterlink.ru
