caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: cstork@ics.uci.edu
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Unquantifiable escaping type in variation of visitor pattern
Date: Fri, 25 Feb 2005 08:57:39 +0900 (JST)	[thread overview]
Message-ID: <20050225.085739.92345506.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <20050224121635.GA22511@anthony.ics.uci.edu>

From: Christian Stork <cstork@ics.uci.edu>

> It's not that I didn't try otherwise.  These are the reasons (I attached
> illustrative code):
> 
> - The mutable parts/alts/item fields in aggrRule/choiceRule/listRule
>   seem necessary since I cannot define grammars (ie recursively defined
>   objects).  Object instantiation is not allowed to the right of a let
>   rec!  
>   
>   "This kind of expression is not allowed as right-hand side of `let rec'"

The alternative is to use "lazy", which has the extra advantage of
being covariant.

> (Does that mean that 3.08.3 will be released soon?)

There was supposed to be a "Valentine day release", but clearly it
didn't happen.

> > But in your particular example there is no subtyping at all, so there
> > should be no problem anyway.
> 
> I don't know which particular subtyping you refer to, but, of course, I
> intend to subtype the rules and visitors.

Well, as long as you use refs in your definitions, subtyping is
impossible on nodes.
You may of course subclass rules, but then you won't need to use
explicit subtyping either, since it is already done in your make*Node
methods through a self-coercion.
So the specific problem I was writing about should not happen.

> > I attach the modified part of your example, which uses a few tricks to
> > make the code much less verbose.
> 
> Hmm, are these tricks documentd anywhere?  I didn't even see the option
> to use constraints in regular variant types in the official OCaml
> manual.  Anyway, thanks a lot for the improvements.

They are in the reference part of the manual.
In the tutorial, they only appear for objects, which is what they were
originally introduced for.
Somehow it's fortunate that these tricks are not well publicized,
since they trigger a bug. On the other hand the bug could have been
corrected earlier...

Jacques Garrigue


  reply	other threads:[~2005-02-24 23:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-08 22:55 Christian Stork
2005-02-09  0:16 ` [Caml-list] " John Prevost
2005-02-22 17:29   ` Christian Stork
2005-02-23  3:08     ` Jacques Garrigue
2005-02-24 12:16       ` Christian Stork
2005-02-24 23:57         ` Jacques Garrigue [this message]
2005-02-25  0:30         ` Jacques Garrigue
2005-02-09  1:53 ` Jacques Garrigue

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=20050225.085739.92345506.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=cstork@ics.uci.edu \
    /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).