# 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