On Fri, 2005-06-10 at 09:13 -0400, Swaroop Sridhar wrote:
> Jonathan S. Shapiro wrote:
>
> > On Fri, 2005-06-10 at 00:22 -0400, Swaroop Sridhar wrote:
> >
> >
> >> That is,
> >>
> >> (module list
> >> (defunion (lst 'a) Nil (Cons 'a))
> >> (append ...)
> >>
> >> (export lst append)
> >> )
> >>
> >> Can the importer of this module also do a Cons independent of the
> append interface?
> >
> >
> >
> > Yes, this is a mess. I think the answer must be either
> >
> > a) no, because Cons has not been exported, or
> > b) yes, because exporting a union type necessarily implies
> > exporting all of its constructors. This is a special case.
> >
> > My current thought is that (b) is the correct behavior. It is not useful
> > in this example to export a list that I cannot pattern match.
>
>
> I thought you would say (a). Because, the point is that the importer of
> the list module should NOT be able to independently pattern match the
> list, but should use other functions of the list module like
> delete(ith element), find, sort, etc.
If the importer of the module should not be able to pattern match the
type, then why is the type being exported?
> ... there is
> currently no mechanism if somebody really wants to export lst
> transparently. However, I feel that we should fix that issue rather than
> make everything transparent. Am I missing something?
Why doesn't
(export lst Nil Cons)
suffice?
> > The problem, however, is that we then have no way to state the type of
> > "alst".
>
>
> This is very simple. The type of alst in the importer will be the
> abstract type alst::t (unifies only with other alst::t) [**]
>
> This is why I had initially asked for
> (export ident:type ident:type ident:type ...)
>
> Then the list module can write
> (export alst:t)
I am still not understanding why the :type is helpful. It seems to me
that this can be completely automated.
> I think we should have 2 kinds of exports...
If we need two kinds of exports, things have become too complicated and
we need to rethink.
> For convenience, we might also add (deep-transparent-export a, b, c, d),
> depth obviously restricted to the visibility of the defining module itself.
>
> This is now on the border of ML like signatures.
Not really. The flaw in ML signatures is that the types of *internal*
items also get exported. By "internal", I mean "things that are not part
of the function/value type, but are local to its implementation."
> [**]Now I have another issue. Because of the way BitC does import, if
> some body imports the module :
>
> >>(module list
> >>
> >> (defunion (lst 'a) Nil (Cons 'a))
> >> (append ...)
> >>
> >> (define alst Nil)
> >>
> >> (export alst) )
>
> TWICE, as in
>
> ex:
> (import l1 list)
> (import l2 list)
>
> This will create
> l1::alst : l1::t and
> l2::alst : l2::t
>
> One possibility is to make l1::t an l2::t compatible. Other possibility
> is to keep them different, and now, the situation is very interesting
> because I have one value alst with 2 alias names and 2 incompatible but
> equally powerful types.
The types are identical. Renaming them must not make them incompatible.
This is no different than DEFTYPE in this regard.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
