1. Namespaces?
There are lots of potential problems with modifying the interpreter,
one could introduce undefined behavior or some bugs into the interpreter
itself.
I know some of the keywords will improve the experience of EUPHORIA but
changing namespace behavior so that you can use builtin names without
overriding must be too difficult for those who are getting into the
interpreter guts to do or we would have seen it already. :)
I would like to point out that you can use namespaces without overriding
builtins. Sure connecting to an ftp site is abstractly similiar to opening
a file but you can use the function name 'connnect' instead. Consider these
psuedocode
These identifiers you can use over and over again in some
ftp.e, http.e, map.e etc.:
type kind( object x )
-- verifies that x is the type that would be returned by connect() or new().
function connect( UnicodeString resource_string, sequence data_sequence )
-- connect to some resource that already exists.
procedure disconnect( object connectionhandle )
-- disconnect to a resource.
function new( sequence data )
-- create a new instance of something.
function set( object x, object key, object y ) -- Sets x of key, key, to y.
-- As in a map class.
function get( object x, object key )
function exists( object x, object key )
Okay, none of these use reserved names and they are short you use namespaces
with them all. There is no need to modify how EUPHORIA does namespacing
because they do not use any names from the builtins.
include get.e as get
include ftp.e as ftp
include http.e as http
-- everyone is happy. Right?
Shawn Pringle
2. Re: Namespaces?
Shawn Pringle wrote:
>
> There are lots of potential problems with modifying the interpreter,
> one could introduce undefined behavior or some bugs into the interpreter
> itself.
>
On the dev list we have exchanged over 130 emails thus far amongst the
developers talking about any impact. We are still working on the final changes if
any.
> I know some of the keywords will improve the experience of EUPHORIA but
> changing namespace behavior so that you can use builtin names without
> overriding must be too difficult for those who are getting into the
> interpreter guts to do or we would have seen it already. :)
>
It's actually already done. Matt changed ~8 lines of code to make this work.
> I would like to point out that you can use namespaces without overriding
> builtins. Sure connecting to an ftp site is abstractly similiar to opening
> a file but you can use the function name 'connnect' instead. Consider these
> psuedocode
>
First, the technically correct term for ftp is not connect, it is open(). Even
in your FTP client, you type ftp> open ftp.gnu.org. So, due to limitations in
Euphoria's namespacing you are suggesting we cannot wrap a library correctly, we
must alter correct names to incorrect names due to Euphoria's limitations.
Secondly, there are all sorts of other examples such as sqlite:open (again you
*are* opening a file, not connecting to a file or connecting to a database
server), zip:open(), stream:open(), etc...
Secondly, the whole idea of allowing the overriding w/o replacing built-ins is
summed up pretty well by a post by Derek. It deals with creative naming as you
are suggesting:
"I want to locate a certain letter in a line of text, so do I use 'search',
'find', 'locate', 'match', 'inquire', 'whereis', 'scan', 'lookup', 'index', ... ?
Even today, how many people continue to confuse the usage of the built-in
functions 'find' and 'match'?"
> These identifiers you can use over and over again in some
> ftp.e, http.e, map.e etc.:
>
As was discussed on the mailing list, what we do in the standard library is
going to be mimiced by Euphoria programmers for a long time to come. Creative
naming is what they will see.
> type kind( object x )
> -- verifies that x is the type that would be returned by connect() or new().
>
> function connect( UnicodeString resource_string, sequence data_sequence )
> -- connect to some resource that already exists.
> procedure disconnect( object connectionhandle )
> -- disconnect to a resource.
>
> function new( sequence data )
> -- create a new instance of something.
>
> function set( object x, object key, object y ) -- Sets x of key, key, to y.
> -- As in a map class.
>
> function get( object x, object key )
>
> function exists( object x, object key )
>
> Okay, none of these use reserved names and they are short you use namespaces
> with them all. There is no need to modify how EUPHORIA does namespacing
> because they do not use any names from the builtins.
>
You have given an example of something very easy. Please try something like
ftp.e, stream.e, zip.e, regexp.e.
> include get.e as get
> include ftp.e as ftp
> include http.e as http
> -- everyone is happy. Right?
>
I do not see where it solves anything, sorry.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: Namespaces?
Jeremy Cowgar wrote:
>
> Shawn Pringle wrote:
> > I know some of the keywords will improve the experience of EUPHORIA but
> > changing namespace behavior so that you can use builtin names without
> > overriding must be too difficult for those who are getting into the
> > interpreter guts to do or we would have seen it already. :)
> >
>
> It's actually already done. Matt changed ~8 lines of code to make this work.
>
This was preferable state to me. I was suggesting we could over and over again
the same routine names for things that are common to most classes libraries:
a constructor called new(), a type function kind(). The benefit of this
is you do not have to reinvent and the user doesn't have to remember constructor
names.
Naming to new() & kind() instead of the include name adds a kind of flexibility.
As an example:
One map may be implemented with a two-element sequence: one with the keys and
the other with the values in mapskv.e. Another may be implemented as a sequence
of key,value pairs: mapkvs.e. You can use
include mapkvs.e as Process_map_t
, and use
that for everything using kind() and new(). As long as these two libraries use
the same routine names you can drop in one for the other simply by changing
the include line to say:
include mapskv as Process_map_t
.
So, I guess I want to say when you have two things that are different
implementations of the same abstract thing, it is beneficial to use the same
routine names in both. Ofcourse, you could name kind() as map() and new() as
new_map but I think using kind() and new() is more elegant.
Shawn Pringle
