From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA00117 for caml-red; Thu, 8 Feb 2001 00:25:15 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA03988 for <caml-list@pauillac.inria.fr>; Wed, 7 Feb 2001 23:02:36 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f17M2W901864;
	Wed, 7 Feb 2001 23:02:32 +0100 (MET)
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA05588; Wed, 7 Feb 2001 23:02:31 +0100 (MET)
From: Pierre Weis <Pierre.Weis@inria.fr>
Message-Id: <200102072202.XAA05588@pauillac.inria.fr>
Subject: Re: compilation of lablgl examples.
In-Reply-To: <3A80A4DB.E3CA3FA9@ozemail.com.au> from John Max Skaller at "Feb 7, 101 12:28:59 pm"
To: skaller@ozemail.com.au (John Max Skaller)
Date: Wed, 7 Feb 2001 23:02:31 +0100 (MET)
Cc: caml-list@inria.fr
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis@pauillac.inria.fr

> > Could you explain a bit why ``the use of standard variant
> > constructors is extremely heavy'' (I thought it was on the contrary
> > extremely light and elegant!) ?
> 
> 	Excuse my poor English -- what I meant was
> "A very large percentage of symbols in the source code
> are variant constructor names". A very large amount of code
> consists of match .. with statements where the expression
> is a variant type, and the result expressions are another
> variant. 

May be it is my understanding of English which is bad, not your way to
write it :(

> 	For example, something like this happens:
> the type of a function declaration in the Abstract Syntax Tree is:
> 
>   | AST_function of id_t * parameter_t list * typecode_t * statement_t
> list
> 
> which is converted to:
>  
>   | DCL_function of   parameter_t list * typecode_t * asm_t list
> 
> which is converted to:
> 
>   | SYMDEF_function of parameter_t list * typecode_t * int list * exe_t
> list * name_map_t
>  
> which is converted to:
> 
>   | BDCL_function of   bparameter_t list * btypecode_t * int list *
> exe_t list * name_map_t
> 
> which is converted to:
> 
>   | BBDCL_function of   bparameter_t list * btypecode_t * int list *
> bexe_t list * name_map_t

This is very often considered good practice. However, I agree with you
that is can be heavy to code. Sometimes you can use polymorphism to
help for instance defining

| Function of 'parameter list * typecode_t * 'b

could be used to modelize both
| DCL_function of   parameter_t list * typecode_t * asm_t list
| BDCL_function of   bparameter_t list * btypecode_t * int list *
 exe_t list * name_map_t

and similarly

| Bfunction of 'parameter list * btypecode_t * int list * 'exe list *
name_map_t

coulod serve for:
| BDCL_function of   bparameter_t list * btypecode_t * int list * exe_t list * name_map_t
and
| BBDCL_function of   bparameter_t list * btypecode_t * int list * bexe_t list * name_map_t

This does not jeopardize static typing and lowers the needs for type
declarations ...

[...]
> I.e., polymorphic variants are more useful for prototyping,
> since types do not need to be declared before writing
> algorithms, yet the declarations can still be added later
> when the design is solider to check just how solid it really is.

This is an interesting idea, worth a try. I'm still not sure the
static type checker could handle gracefully the ``partial and
exhaustive match'' problem, but I may be wrong...

[...]
You should try on a small example, not on a huge optimizing compiler
for a full fledged language!

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/