[nem-en] recursive types

[Michal Moskal]

On Wed, Sep 22, 2004 at 04:30:04PM +0200, Wiktor Zychla wrote:
> 1. The binary modules produced by ncc compiler are dependent of
> Nemerle.dll library. From the perspective of an experienced developer
> this could be a major inconvenience for many reasons. Would it be possible
> to add an option to link the contents of the library with the binaries?

I guess it would be hard to do. There are two easy ways to get this done:
a/ compile nemerle.dll sources along with your sources (and -no-stdlib
option), b/ run your compiled program and nemerle.dll through ildasm, glue
it together and ilasm it. The second option is the usual way to link .net
dlls together. I also heard there are some external (commercial?) tools
to do this.

> 2. In my opinion, 'module' and 'variant' keywords are redundant and
> could be dropped from the language (thus following Ockham's Razor
> Rule). Especially in the case of "variants", is there a sensible
> explanation why the "class" keyword could not be used in case of
> recursive types?

I guess there is no reason to have the module now, we can use "static
class" for this (that would automatically add static modifier, unlike in
C#). Maybe we could also drop the variant keyword. It really seems
redundant, as I see now.

> Several issues about recursive types. 
> 
> 3. Why following declarations are not equivalent:
> 
> class Base {
>  public ID : int;
> }
> 
> variant Tree : Base {
>  | Node { left : Tree; right : Tree; v : object; }
>  | Empty
>   
>  public override ToString() : string
>  {
>   match( this ) {
>    | Node( left, right, v ) =>
>     string.Format( "[{0} {1} {2}]", left, v, right );
>    | Empty =>
>     string.Empty;
>   }
>  }
> }
> 
> and 
> 
> variant Tree : Base {
>  | Node { left : Tree; right : Tree; v : object; }
>  | Empty
> 
>  public ID : int;
>   
>  public override ToString() : string
>  {
>   match( this ) {
>    | Node( left, right, v ) =>
>     string.Format( "[{0} {1} {2}]", left, v, right );
>    | Empty =>
>     string.Empty;
>   }
>  }
> }
> 
> in the former case we got Tree() public constructor while in the latter
> we got Tree( int ) public constructor that forces the client code to
> initialize the ID field. Could you explain it?

This is a bug. There should be no possibility of getting public
constructor in the variant class. Public ctors should be allowed only in
variant options.

However back to your problem, if the Tree class had Tree() and Tree(int)
ctors, then Node would have Node(Tree, Tree, object) and Node(int, Tree,
Tree, object). However in the second case, there is some automagically
created ctor, that messes things up.

Could you please report it in our bug tracker, so we don't loose it?

> 4. What's wrong with this code (does not compile with "unbounded type name Term" message):
> 
> variant Lambda {
>  | Abs { Name : Id; Term : Lambda; }
>  | App { Term1 : Lambda; Term2 : Lambda; }
>  | Id { Name : string; } 
>  
>  public override ToString() : string
>  {
>   match( this ) {
>    | Abs( Name, Term ) =>

Pattern variables need to be lowercase[1]. The error message should be
improved, so it's again a bug -- please report it.

The reason for [1] is the problem of variant option matching vs variable
that matches everything. We decided to choose which one is the case at
the lexical level.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?