[p-dev] [docs] Document intentions for modules and interfaces.

[Paul Bone]

On Mon, Mar 14, 2016 at 11:57:25AM +1100, Paul Bone wrote:
> Hi,
> 
> I`'m seeking feedback on my ideas for modules and interfaces.  If anyone has
> any comments I'd appriciate them.  You can also read this online:
> http://www.plasmalang.org/docs/plasma_ref.html
> 

I received some feedback from ely-se/rightfold at 5am this morning.  I'll
answer it here where ely-se and I don't have to both be on IRC at the same
time to communicate:

< ely-se> Boney: is it possible to have interface expressions? Like you 
          can have lambdas instead of func definitions, you could have 
          instambdas instead of instance definitions
< ely-se> instance expressions, not interface expressions*

    That's part of my intention.  I haven't thought about how it will work
    and I don't plan on working on it for a while.  There's a small note at
    the bottom of that section saying "More powerful expressions may also be
    added."  This is one of the things that ought to be possible.

< ely-se> is it possible to pass instances as arguments to functions at 
          all?
< ely-se> I'm not sure I grok the diff between interfaces/instances and 
          structs except that the former can have type members

    The only difference is that interfaces and instances aren't tied to the
    module system (as much).  The thing that controls modularity and separate
    compilation is a "module" and the thing that provides this "method of
    abstraction" is interfaces instance.

    So even though it's quite similar to structs & functors from Ocaml I didn't
    want to call it that.  I want to avoid terms that come from category theory,
    because no-one should feel like they need to know CT in order to use
    Plasma[0] and avoid the term "struct" which probably has other meanings to
    most programmers (from the C language).  Interfaces and instances are the
    best names I've thought of so far.

    Therefore, it is not in my plans to make instances first class.  However a
    function can require that one or more of it's arguments have types that come
    from one or more interfaces.  Then a call to this function will use the same
    instance in the callee as in the caller.  Something like:

        bsearch(array : Array({Ord.t, x}), key : Ord.t) -> x
        {
            ...
        }

    I have also introduced tuple syntax with this example, using curly-braces.

< ely-se> also do we need two keywords for importing stuff? Instead of 
          use, why not import M.* ? Especially as * can already be used 
          with export

    My justification was that use and import do different things and
    therefore have different names.  However I think that's a good point
    with the "M.*" syntax import and use can have the same semantics
    (provided that overlapping names are handled carefully).  I think I'll
    follow this suggestion.

As always, if anyone has any suggestions I'd be happy to hear them.


-- 
Paul Bone