Re: Design sketch for Ior---a new type of Scheme interpreter

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

[about Ior]


Just for kicks:


* Specializers and types are two different things.

The Java method `int K.m (int a, string s)' has the three specializers
(K self) (ANY a) (ANY s).  This is orthogonal to the types it has (INT
for the return type, INT and STRING for the two arguments).

Cecil for example specifies a specializer with the "@" syntax
and types with the ":" syntax.  The above Java method for example
would be written as follows:

method m (self@K:ANY, a@ANY:INT, s@ANY:STRING): INT

[note that what the return type *cannot* be a specializer!]


I think one should not mix these two orthogonal concepts.

See -> http://www.cs.washington.edu/research/projects/cecil/www/Refman/wmwork/www/cecil-spec_1.html



* Modules and classes share the same concepts but they belong to two
different domains

-> http://sky.fit.qut.edu.au/~szypersk/pub/ECOOP92.ps.gz


** In Scheme both, modules and classes must be potentially open

-> Chambers & Leavens (Cecil Module System):
ftp://ftp.cs.washington.edu/tr/1995/08/UW-CSE-95-08-05.PS.Z    

-> Sho-Huan Simon Tung "Interactive Modular Programming in Scheme" In
Conference on Lisp and Functional programming, San Fancisco, June
92. bibtex, 85.1 kbytes postscript paper

* First class extents

The above simply means that we need two different constructs, a low- level
module type (forget the environment spec, it's incomplete) *and* an
orthogonal low-level struct type.  But their interfaces should look
similar. -- Actually we need three different constructs: module,
class, generic.

A unified low-level representation for both classes and generics may be
a "first-class extent" and the "first-class environment" proposal can
be adapted.

-> Lee&Friedman: iucstr350.ps.gz ("First class extends")


** The "with" or "open" problem

The FCE spec as well as the first-class environment proposal has the
problem that complete classes/modules are "opened".  This is not acceptable.

See page 71 in Blume's dissertation:
-> http://www.cs.Princeton.edu/~blume/thesis.ps.gz


* Modules

** Interfaces

There are no "outward" or "inward" interfaces.  Interfaces are
used to connect classes and modules together. 

** States

A module may be in two different states: opened or closed.
The environment proposal must be changed to reflect this.
(the scm_interface_environment tries hard to hide these states, but
I think it's better to fix the environment spec).



Jost