Changes between Version 17 and Version 18 of CompilerDesignNotes

Timestamp:

09/16/09 13:53:50 (2 months ago)

Author:

dr2chase

Comment:

--

CompilerDesignNotes

@@ -51 +51 @@
 where ''API'' is the api name, ''name'' is the top-level function or opr name, and ''type'' is the fortress type of the closure (an arrow type, Arrow⟦''domain'',''range''⟧).  Ond-demand generation is used to cut down on the creation of unused classes (each closure results in a class).  For generic functions, each instantiated top-level generic function will result in a class, so it might as well do double-duty as a closure.
 
+''Question: is it really API.whatever, or is it API$whatever (i.e., subpackage, or inner class)?''
+
 The proposed encoding of a generic function is a class named
    ''API'' "." mangle("⚙" ''name'' ''parameters'' "✉" ''type'')
@@ -72 +74 @@
  * because an overloaded function may have the same signature as one of the functions that it overloads, there has to be a way to mangle one of the names out of the way;
  * because an overloaded implementation is not necessarily evident at the API level (the type of the overloaded function could be a simple Fortress type), (exported) overloaded functions within components;
- * overload dispatch can occur twice; once within the component, and again within the API (and if the chosen overloaded function happens to be a functional method, one more time after that).
+ * overload dispatch can occur twice; once within the component, and again within the API (and if the chosen overloaded function happens to be a functional method, one more time after that).  Flattening it into a single dispatch is not trivial; because component-level overloadings behind the API may not be visible, it is possible that a naively combined overloading would not satisfy the meet rule; that is, there would be ambiguities, and dispatch order would matter.
 
 ASIF dispatching is an interesting special case.  It separates into several simpler cases: