1. RE: Namespace solution?
G'day all
Irv Mullins wrote:
> 1. Deprecate the 'global' keyword, and introduce the new keywords:
> export and import..
> example:
> export x,y -- in file a
> export x,y -- in file.b
>
> -- your program
> import x from file.a
> import y from file.b
> <snip>
Yep, that looks useful. However, what would I do if I wanted both values
of x, rather than one x and one y? There would have to be something like
the following available (a sort of "alias by stealth"):
import x from file.a
import y from file.b:x -- assign x from file.b to my local y
The above doesn't exactly stand out - it looks too easy to overlook the
":x" extension on the second import. To make it more visible, maybe
something like:
import file.a:x
import file.b:x as y
Thoughts, anyone?
Regards
Tony
2. RE: Namespace solution?
On Tue, 26 Jun 2001 03:35:43 -0700, Tony Bucholtz
<tony_bucholtz at hotmail.com> wrote:
>G'day all
>Irv Mullins wrote:
>> 1. Deprecate the 'global' keyword, and introduce the new keywords:
>> export and import..
>> example:
>> export x,y -- in file a
>> export x,y -- in file.b
>> -- your program
>> import x from file.a
>> import y from file.b
>> <snip>
>Yep, that looks useful. However, what would I do if I wanted both values
>of x, rather than one x and one y? There would have to be something like
>the following available (a sort of "alias by stealth"):
> import x from file.a
> import y from file.b:x -- assign x from file.b to my local y
>The above doesn't exactly stand out - it looks too easy to overlook the
>":x" extension on the second import. To make it more visible, maybe
>something like:
> import file.a:x
> import file.b:x as y
>Thoughts, anyone?
Irv's suggestion and yours both seem to be groping for the Modula-2
solution to the problem. In M2, one specifies the exported symbols in the
'Definition Module', but earlier versions required a further explicit
export:
DEFINITION MODULE Foo;
EXPORT Symbol1, Symbol2, Symbol3;
EXPORT QUALIFIED Symbol4;
would allow you to use Symbol1, Symbol2, Symbol3, and Symbol4 in another
program.
IMPORT Foo;
would let me refer to Foo.Symbol1, Foo.Symbol2, Foo.Symbol3 and
(equivalently) Symbol4 or Foo.Symbol4 (because Symbol4 was EXPORTed
QUALIFIED).
Alternatively,
FROM Foo IMPORT Symbol1, Symbol2, Symbol3, Symbol4;
would allow me to refer to Symbol1, Symbol2, Symbol3, and Symbol4, without
qualification - or, equivalently, Foo.Symbol1, Foo.Symbol2, Foo.Symbol3,
and Foo.Symbol4.
In such a situation, if two modules defined symbols with the same
identifier, I would have to explicitly qualify where it was ambiguous. If
they were of different types, M2 was smart enough to decide which one it
had to be, based on the context - or would return a compile-time error if
ambiguity couldn't be resolved.
Euphoria is not as strongly typed as M2. Thus, my recommendation would be
to require fully-qualified import at all times, so that Symbol1 would refer
to a locally-declared Symbol1, while Foo.Symbol1 refers to the Symbol1
imported into/from namespace Foo, and Bar.Symbol1 refers to the Symbol1
imported into/from namespace Bar. This leaves us with no ambiguity. I
would be inclined to allow syntaces equivalent to both forms of M2 IMPORT;
the FROM module/namespace IMPORT symbols would serve more as documentation
than as having a semantic difference from a straight IMPORT
module/namespace. As I said in my earlier post, however, I feel that it is
absolutely necessary for the namespace identity to be in control of the
module user, meaning that a M2-like equivalent would have to be along the
lines of
IMPORT moduleid INTO [NAMESPACE] namespaceid;
FROM moduleid IMPORT symbolids INTO [NAMESPACE] namespaceid;
or, closer to current Euphoria syntax,
include moduleid as [namespace] namespaceid
from moduleid include symbolids as [namespace] namespaceid
although perhaps it would be more natural to use "into" for "as" in the
second form (and not incorrect to do so in the first form).
--
Jeff Zeitlin
jzeitlin at cyburban.com
(ILink: news without the abuse. Ask via email.)
