caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <Pierre.Weis@inria.fr>
To: skaller@ozemail.com.au (John Max Skaller)
Cc: caml-list@inria.fr
Subject: Re: compilation of lablgl examples.
Date: Wed, 7 Feb 2001 23:02:31 +0100 (MET)	[thread overview]
Message-ID: <200102072202.XAA05588@pauillac.inria.fr> (raw)
In-Reply-To: <3A80A4DB.E3CA3FA9@ozemail.com.au> from John Max Skaller at "Feb 7, 101 12:28:59 pm"

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




  reply	other threads:[~2001-02-07 23:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-03 22:35 Peter Ronnquist
2001-02-05 17:41 ` John Max Skaller
2001-02-06 15:55   ` Pierre Weis
2001-02-07  1:28     ` John Max Skaller
2001-02-07 22:02       ` Pierre Weis [this message]
2001-02-08  5:55         ` Patrick M Doane
2001-02-08 16:33         ` John Max Skaller
2001-02-08 19:15           ` Pierre Weis
2001-02-08  2:06       ` Jacques Garrigue
2001-02-06  2:34 ` Jacques Garrigue
2001-02-06 18:00   ` Sven LUTHER
2001-02-07 12:09   ` Peter Ronnquist
2001-02-08  7:22     ` Sven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200102072202.XAA05588@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=skaller@ozemail.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).