[bitc-dev] Re: BitC issues

[Jonathan S. Shapiro]

Swaroop:

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)))

is unambiguous.

> 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))

or

	(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)

Both

	(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
anonymous datatype:

	(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[25] 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?

Yes.

> 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
past.
-- 
Jonathan S. Shapiro <shap at eros-os.org>