To: gwydion-group+
Subject: creole comment summary
fcc: out-copy
--------

Here's a summary of comments on Creole so far...

  Rob

________________________________________________________________

C++ support:
    We feel it is important to be able to use C++ libraries, and would like to
    hear more about this.  There are both semantic and implementation problems.
    On the semantic side, compile-time overloading (especially on arg count)
    doesn't map well onto Dylan.  There implementation problems in integrating
    with any particular C++ implementation interms of guessing what renamings
    it has used, etc.  Is it even possible to reliably determine what class a
    C++ object is at runtime?

    Overall, we are not committed to supporting arbitrary C++ interfaces, but
    we don't have enough experience using C++ interfaces to know what is and
    isn't necessary.  We strongly suspect that overloading can't be ignored,
    and there probably needs to be a mechanism to name the different
    overloadings and map them onto different dylan functions.

Other language support:
    There are still non-C languages that have to be used.  In particular, we'd
    like to be able to use fortran-style numeric libraries.  The array support
    seems especially weak in this light.

Reciprocal (non Dylan-centric) programming:
    We not only want to be able to use existing application frameworks, we also
    want to be able to write new frameworks for others to use.  There needs to
    be a form similar to "define interface" which is used to implement the
    interface in Dylan.  The exported interface would still be specified via
    some standard IDL, but Dylan would generate a standard object file which
    could be linked into other applications.

Mac Specificity:
    It would be really useful to have a document that avoids spurious Mac
    specificity.  On close examination, much of the proposal isn't Mac
    specific, but it's hard to separate out.  For example, the whole "access
    path" mechanism could be omitted in portable uses.  Many aspects of how
    linkage is actually done (such as write-external-modules) should probably
    also be implementation dependent.

Time/space tradeoffs:
     "The Dylan programmer needs to be able to control the tradeoff
     between functionality and runtime memory consumption."  Although we
     can make informed guesses, it is not entirely clear what this
     means -- could you elucidate?

MacDylan questions:
 -- The seal-functions keyword is allowed to be "inline".  Is this a general
    Dylan feature, e.g. as a define adjective?
 -- We still await some information on what it means to be a "compile stage
    Dylan function" or a "macro".

Global variables & slot accessors:
    It is said that global variables & structure slots are treated the same,
    but it isn't exactly clear what this means.  We guess that a global
    variable foo has Dylan functions foo() and foo-setter(value), or if an
    array, has additional index arguments.  C++ member functions will
    presumably be mapped to a single dylan function variable which takes the
    object as the first argument.

sizeof/structure-size:
    Does structure-size only work on structs, or is it badly named?

Anonymous types:
    How can you call a function which has an anonymous type as an argument or
    return value?  Does **foo have a default name?

Arrays:
    The only mention of arrays seems to be in the discussion of structure slot
    accessors (and implicitly global variables.)  How do you deal with
    functions that accept or return array pointers?

    It is awkward not to be able to access array slots or globals as array
    pointers.  One idea is to make the indices optional to the accessor, and to
    make the effect similar to C, where no indices means the array pointer, and
    few indices means return the indexed sub-slice of the array (the vector of
    vector semantics.)

    Once you've got an array pointer, how do you index it?

    For numeric programming, much better support for manipulating external
    arrays is necessary.  Probably the best approach would to have Dylan array
    objects that alias external array data.
    
Untyped pointers:
    It's pretty random (probably mac toolbox specific) mapping long* to an
    untyped pointer.  Char* is also questionable, since the whole design
    depends on ANSI C, which uses only void as an untyped pointer.