[bitc-dev] Re: BitC issues
Jonathan S. Shapiro
shap at eros-os.org
Fri Dec 17 14:10:01 EST 2004
These notes should go to bitc-dev at coyotos.org
On Fri, 2004-12-17 at 13:37 -0500, Swaroop Sridhar wrote:
> I have a few questions:
> 1) Consider the following example:
> (datatype t1 (N int))
> (datatype t2 (N int))
This is illegal. The second datatype is a syntax error.
The reason is that the *first* datatype binds the symbol N as an
indentifier in the scope containing the datatype declaration. Because
this identifier is bound, the second datatype is redefining a bound
identifier, which is illegal.
Given this, the meaning of
> (let p (lambda x (N 1)))
> i) Impose the rule that type constructors should be unique (like ML)
This is the intended rule.
> 2) I think the only way of creating new type-names (not type-aliases) is
> by using datatype. But this may be painful in large scale coding. ex:
> (datatype pte (PTE long * char)) // addr and perm,
> // PTE should not unify with any other long * char
This is a syntax error. I believe that you mean:
(datatype pte (PTE long char))
alternatively, one could write
(typealias PTE (tuple long char))
(typealias PTE (long, char))
> However if there was a way to declare new types, then
> type pte (addr: long, perm: char)
> type page (vector pte 1024)
(typealias pte (addr : long, perm: char))
(typealias page (vector pte 1024))
are legal. See section 2.5.1 and section 2.5.3. By the way, I am fairly
certain that you want 'byte', not 'char'.
> However, in introducing such a facility, we widened the problem in point
> 1 to tuples, records and vectors.
Nope. The scope of the name defined in a tuple is that of a member
selector. Following the above:
(let ((mypte (5, #\c)))
mypte.addr) => 5
However, this is stylistically very unfortunate, because we really want
the constructor here. I think that what we actually would want is an
(datatype _ (PTE long char))
and then use pattern matching.
> 3) I am probably missing something, but I could not find a way to index
> into a vector in the BitC spec.
> I made up a syntax for vector indexing as y in the above example,
> but I do not know how it is intended to be done.
The traditional scheme syntax would be
(vector-fetch some-vec some-index)
However, I like your syntax much better, and I think we should use it.
> 4) From the spec, it is not clear as to how function types should be
> written ex: tuple(x: 'a -> 'b) ?
Good catch. Yes, that is the intention. Needs to be added to the types
section of the spec.
> 5) The spec is also not clear as to how the types of tuples with named
> fields are written. Do the tuples (25) and (x: int) unify?
Yes, they do. See section 2.5.3.
> 6) The Identifiers section (2.1) says that +, -, etc are identifiers. I
> think this is to done to facilitate (something like) overloading. Will
> the declaration (let + - (+ 1 1)) override the built in + function and
> produce 0?
> 7) If I am right, you wanted me to implement the lexer and parser by
> hand in the first compiler itself, so that it will be easy transform it
> into BitC later. Also, it was decided that the first compiler will
> depend on libgc for garbage collection. Now, will the BitC->C compiler
> in BitC also rely on libgc for garbage collection? If not, do you want
> the garbage collector also implemented in the first (BitC->C compiler in
> ML) itself?
For now, I think we should defer the garbage collector as long as
possible and rely on libgc.
> 8) I think, for an expression language the 'in place' symbol table
> (within ast) that you mentioned is a good idea. I read in Cooper's book
> that this was how it used to be done originally, and that later hash
> tables were used to save space. We will have to maintain some book
> keeping information (for error reporting) along with type and definition
> information within each symbol. So, if you are concerned with space
> explosion, we need to move towards two-dimensional hash tables.
> Otherwise maintaining symbol information within the ast will suffice.
The space concerns that motivated that are now a thing of the distant
Jonathan S. Shapiro <shap at eros-os.org>
More information about the bitc-dev