[bitc-dev] Re: BitC issues

[Jonathan S. Shapiro]

On Fri, 2004-12-17 at 15:35 -0500, Swaroop Sridhar wrote:
>  > 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.
> 
> This probably is illegal according to current BitC grammar. But, I think 
> the the top level definition of an expression language should be a let* 
> (sequential binding). In this case, the second definition should 
> 'overrule' the first.

Definitely not! The top level binding should be an uncompleted LET. It
is very important not to allow identifiers to be redefined. It will
bugger separate compilation all to hell if we allow this.

> I know this. However, my question was: Do we want a facility to declare 
> new type-names that DO NOT unify, WITHOUT having to use constructors?

I do not think so.

However, your examples are thought-provoking, and I want to sleep on
them.

> I know that this can be done using datatypes. My only concern is about 
> the programmer, who has to write:
> 
> (let prq
>    (lambda x
>       (if (match x (PAGE y))
>          (if (match y[25] (PTE z))
> 	      z)
> 
> instead of
> 
> let pqr (lambda x:ppage x[25].addr)

Don't worry about the programmer. Worry first about arriving at a sound
and sensible language design.

> Another question about language implementation:
> Does the specification require that the vectors and tuples be packed, or 
>   is the compiler free to pad extra bytes for alignment?

This is a missing discussion in the pragmatics section. The compiler
packing rules should be identical to those of C.

>  I think we need 
> both kinds of data structures for correctness and efficiency (unless we 
> want to do manual alignment).

Packed records are a *really* bad idea. We don't want them.

-- 
Jonathan S. Shapiro <shap at eros-os.org>