[bitc-dev] RFC: interfaces

[Constantine Plotnikov]

First impression is that this proposal is an attempt to reinvent Ada 
packages. "Statefull interface" also contradict  other usages of word 
"interface". "Stateful" is an implementation property. I was not happy 
with stateful modules either, but I'm still waiting for memory model 
specification before I can comment on the issue.

On issue 1: Ada has separate keywords for importing other package and 
using names without qualification.

Constantine

Jonathan S. Shapiro wrote:

>This is a request for comments -- if we are about to mess this up we
>want to know!
>
>As I have thought more carefully about the current BitC module
>mechanism, I have become increasingly unhappy with it. There is nothing
>wrong with modules per se, but the module mechanism isn't really
>achieving what I was trying to achieve. What we needed was interfaces,
>not modules.
>
>Since "interface" is a term used in many ways, let me state what I mean:
>an interface is a contract between one or more *clients* and an
>implementation. It describes the attributes of the implementation that
>the client is entitled to rely on.
>
>So here is a proposal for how I think we should do interfaces in BitC.
>
>First, an interface is a compilation unit. One interface, one input
>file. This restriction is imposed so that the compiler will be able to
>successfully resolve IMPORT statements.
>
>An interface is introduced by either the INTERFACE or STATEFUL-INTERFACE
>top-level form, and has the format:
>
>  (INTERFACE ident
>    if-decl ... if-decl)
>
>Where "ident" is a namespace identifier.
>
>An if-decl can be any of the the following:
>
>  1. A DECLARE form, as described in my previous email
>  2. A type definition (DEFUNION, DEFSTRUCT, DEFTYPE)
>  3. A constant definition
>
>If the interface is not stateful, then all of the declarations must be
>deeply non-mutating.
>
>A client makes use of an interface by means of one of the following
>declarations:
>
>  (IMPORT if-name)
>  (STATEFUL-IMPORT if-name)
>
>with the meaning that following this declaration the identifier
>"if-name" will act as a namespace identifier. "if-name" must match the
>identifier given in the interface. Compatibility is required to achieve
>statefup import.; the IMPORT statement will not import stateful
>interfaces.
>
>The implementation of an interface proceeds by first using one of the
>declarations above, and additionally declaring
>
>  (PROVIDES if-name)
>
>The PROVIDES form indicates that the compilation unit defines one or
>more of the types or symbols that is declared in the interface.
>
>For example:
>
>  ;; Interface declaration:
>  (interface list
>    (defunion (list 'a):ref nil (cons 'a (list 'a)))
>
>    (declare length : (fn (list 'a) int32)))
>
>  ;; Provider:
>  (import list)
>  (provide list)
>
>  (define (length x)
>    (case x ((nil 0)
>            ((cons a b) (+ 1 (length b)))))
>
>  ;; Client:
>  (import list)
>
>  (define mylist (list::cons 3 list::nil))
>
>
>OPEN ISSUES
>
>There are two problems with this specification:
>
>1. It is somewhat awkward that the names published by an interface
>cannot be imported for unqualified use -- especially for commonly used
>types like list. It is possible to use DEFINE to achieve *nearly* the
>same result, but not quite. Consider:
>
>  (stateful-interface if
>    (declare x : (mutable int32)))
>
>  ;; client:
>  (stateful-import if)
>  (define x if::x)
>
>The intention here is to define a local alias for "x", but the actual
>effect is to create a copy.
>
>I think that we ultimately will need to resolve this, but for the moment
>I want to work without it and gain experience to determine how such
>aliases should work.
>
>2. Note that in contrast to the previous module import, interface import
>does NOT provide any means to rename the interface, and does NOT provide
>any means to re-export an interface. The namespace of interfaces is a
>global scope, and name collisions are possible. This is intentional,
>because it makes type names unambiguous for printing purposes. We will
>probably need a way to deal with this at some point.
>
>3. There is a problem with declaring opaque value types. For example:
>
>  (interface if
>    (declare x : val)
>    (declare instance : x))
>
>This is a declaration that "x" is a value type of arity zero, and that
>"instance" is an instance of this value type. Now consider some piece of
>code like:
>
>  (f instance)
>
>where we are attempting to pass "instance" to some function. This is
>only useful if "f" will eventually call some other function for which
>the type is translucent, but that is not a problem. The immediate
>problem is that the caller does not know the SIZE of "instance", and
>therefore cannot form a proper call frame for it. More generally, the
>caller does not know the copy or explicit free semantics of "instance".
>
>So there is a general problem hiding here in the declaration of opaque
>value types that we will ultimately need to solve. My intuition for the
>moment is that we simply should not support opaque value types in
>interfaces for now.
>
>
>shap
>
>_______________________________________________
>bitc-dev mailing list
>bitc-dev at coyotos.org
>http://www.coyotos.org/mailman/listinfo/bitc-dev
>  
>