Re: [stack] Whither Joy? Modules
wtanksleyjr@cox.net — 2003-01-17 16:32:28
From: Manfred von Thun <
phimvt@...>
> 1. Explicitly list or annotate the funtions
>that are exported (made available outside the
>module). Any functions that are not so listed or
>annotated are hidden by default.
This is my preference. I would also recommend borrowing
from Oberon for these purposes, since it's a solid, small
language with lots of experience going into its design.
Thus, for a module "Math", the statement
IMPORT Math;
will allow Math to be used as a module; a statement like
IMPORT Math.PI;
will import just the public constant PI (which can be used
without a Math qualifier). Public symbols are identified
by an asterisk following their definition, as in
MODULE Math
CONST
PI* := 355.0/113.0;
END Math.
This is syntactic, but it seems appropriate because the
action of accessing modules is itself syntactic.
>I favour the second solution, because that would
>make MODULE and HIDE two orthogonal concepts.
No real difference in that respect, is there? I don't see
any.
>So, for the time being I favour the notation m.e1 m.e2 ..
>unless anybody can think of a notation which in some way
>or another is more suited for a concatenative language.
No, I think that's a great one. I'm sure : would be another
contender...
> - Manfred
-Billy
John Cowan — 2003-01-17 17:06:42
wtanksleyjr@... scripsit:
> No, I think that's a great one. I'm sure : would be another
> contender...
Colon has the advantage that it can be readily doubled in order to access
a private name in a foreign module, as in Common Lisp.
--
Said Agatha Christie / To E. Philips Oppenheim John Cowan
"Who is this Hemingway? / Who is this Proust?
jcowan@...
Who is this Vladimir / Whatchamacallum,
http://www.reutershealth.com
This neopostrealist / Rabble?" she groused.
http://www.ccil.org/cowan
--author unknown to me; any suggestions?
wtanksleyjr@cox.net — 2003-01-17 18:36:54
From: John Cowan <
cowan@...>
> wtanksleyjr@... scripsit:
>>No, I think that's a great one. I'm sure : would be
>>another contender...
>Colon has the advantage that it can be readily
>doubled in order to access
>a private name in a foreign module, as in
>Common Lisp.
No doubt true; it also carries the connotation of being
stronger than a dot (it's TWO dots), so we can visually
distinguish between structure and module accesses if we
wish to.
On the other hand, a dot can be doubled to become a colon
in order to access a private name. Lisp didn't use that;
was it because Lisp already used the dot to allow the
construction of improper lists?
Personally, I'd rather not allow private names to be
accessed ad-hoc; I'd like to allow them to be accessed,
but only when such access is predeclared. For example,
perhaps we could allow:
IMPORT Math; -- just a normal import
IMPORT *Math; -- import with private access permitted
In use, Math.PI would always get the symbol PI;
Math:PIApproximationCalculator would get the symbol
for that function in the second case, but would just
cause an error in the first.
(I'm using an asterisk because Oberon uses that to indicate
a public symbol.)
The advantage here is that "unsafe" modules are
pre-declared as unsafe, no ambiguity. (Oberon does this
for all things; if you IMPORT sys you're automatically
declaring your module as unsafe, and if you don't import
it you can't do unsafe things like reference arbitrary
memory.)
Oberon is worth a study.
So's Common Lisp, of course.
-Billy
John Cowan — 2003-01-17 18:50:24
wtanksleyjr@... scripsit:
> On the other hand, a dot can be doubled to become a colon
> in order to access a private name. Lisp didn't use that;
> was it because Lisp already used the dot to allow the
> construction of improper lists?
The dot was already in common use in pre-CL Lisp as a name
character, and couldn't be pre-empted. The improper-list-dot has
to be set off by whitespace to work: it is the symbol named ".", not
the character ".". Early Lisps may have interpreted (A.B) as
an improper list, but modern ones take it to be a list with a single symbol.
> Personally, I'd rather not allow private names to be
> accessed ad-hoc; I'd like to allow them to be accessed,
> but only when such access is predeclared. For example,
> perhaps we could allow:
So now we have three classes of names: public, "friend", and private.
I think this is overkill.
> The advantage here is that "unsafe" modules are
> pre-declared as unsafe, no ambiguity.
But no Joy module is really unsafe, because Joy can't do unsafe things.
We want to prevent accidental collisions, not intentional misuse, I think.
--
A mosquito cried out in his pain, John Cowan
"A chemist has poisoned my brain!"
http://www.ccil.org/~cowan
The cause of his sorrow
http://www.reutershealth.com
Was para-dichloro-
jcowan@...
Diphenyltrichloroethane. (aka DDT)
wtanksleyjr@cox.net — 2003-01-17 19:33:06
From: John Cowan <
cowan@...>
> wtanksleyjr@... scripsit:
>>Personally, I'd rather not allow private names to be
>>accessed ad-hoc; I'd like to allow them to be accessed,
>>but only when such access is predeclared. For example,
>>perhaps we could allow:
>So now we have three classes of names: public,
>"friend", and private. I think this is overkill.
Close. We have two classes of names, public and private;
and we have two classes of module variables, shielded
and unshielded.
Unshielded access to a module is a VERY significant
choice, tying your modules VERY closely together, and
should not be hidden.
>>The advantage here is that "unsafe" modules are
>>pre-declared as unsafe, no ambiguity.
>But no Joy module is really unsafe, because Joy
>can't do unsafe things.
Good. Now all we have to do is add a 'sys' module which
CAN do unsafe things. That is, if we want to imitate
Oberon.
I don't see any need for that, by the way; Oberon had to
do that because it's designed as a system implementation
language.
>We want to prevent accidental collisions, not
>intentional misuse, I think.
Who said anything about intentional misuse?
-Billy