caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Pietro Abate <Pietro.Abate@pps.jussieu.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] elegant subtyping?
Date: Fri, 4 Nov 2011 15:12:07 +0100	[thread overview]
Message-ID: <CAPFanBGcb5oWoF-0rSS+XwOGq0MM9NhROaOs+NS=0mrHDO4AVg@mail.gmail.com> (raw)
In-Reply-To: <20111104134342.GA9248@pps.jussieu.fr>

In theory, polymorphic variants are the right tool for the job : they
allow to express exactly what is asked for -- even in presence of
recursive datatypes, if carefully formulated using open recursion and
fixpoint. See Jacques Garrigue paper "Code reuse through polymorphic
variants" for an introduction and interesting examples :
  http://www.math.nagoya-u.ac.jp/~garrigue/papers/fose2000.html

In practice, they come with the downside of being more difficult to
use than closed variants. I personally keep using your solution (1) to
preserve simplicity; that usually means a finite number of
dumb-looking "| Ast.Assign -> Cfg.Assign" branches in each pattern
matching, but nothing really problematic for code quality or
maintenance.

The problem with polymorphic variants is that they are so flexible
that type inference cannot help you a lot with errors in polymorphic
variants code. For example, if you mistype one constructor name, the
compiler won't be able to flag an error, it will only infer a slightly
different types with the usual constructors, plus the misspelled one.
Errors will only be spotted later, when you try to combine the faulty
code with a function with strict assumptions on the variants (closed
pattern matching), with an unwieldy error message.

My advice for polymorphic variant beginners is to massively use
annotations to control type-checking : every time you take a
polymorphic variant as input, or output one, the function should be
annotated with a precise type for the variant part. This will shield
you from most inference issues, and force you to build an expressive
set of type definitions (as Pietro demonstrated) that can be composed
and help reason about your program.


On Fri, Nov 4, 2011 at 2:43 PM, Pietro Abate
<Pietro.Abate@pps.jussieu.fr> wrote:
> hello,
> using polymorphic variants maybe ?
>
> # module Cfg =  struct type statement = [ `Assign | `Guard ] end;;
> module Cfg : sig type statement = [ `Assign | `Guard ] end
>
> # module Ast =  struct type statement = [ Cfg.statement | `Goto | `Label ] end;;
> module Ast : sig type statement = [ `Assign | `Goto | `Guard | `Label ] end
>
> p
>
> On Fri, Nov 04, 2011 at 02:06:23PM +0100, Markus Weißmann wrote:
>> Hello everyone,
>>
>> I'm writing on a compiler and want to subtype the "statements" that can
>> occur in my code:
>> At first I have an abstract syntax tree that can hold any statement of the
>> language. From that I create a control flow graph that will only have
>> non-control-flow statements (a true subset of the Ast-statements).
>> Whats the best way to realize that?
>>
>> Basically I have:
>>
>> module Ast: type statement = Assign | Guard | Goto | Label
>> module Cfg: type statement = Assign | Guard
>>
>>
>> I see three -- not so elegant -- solutions to this:
>>
>> 1.) type-safe but imho quite ugly code:
>> module Cfg: type statement = Assign | Guard
>> module Ast: type statement = Base of Cfg.statement | Goto | Label
>>
>> 2.) use the same type for both and give up the safety that wrong types
>> cannot show up in the Cfg
>>
>> 3.) use objects
>>
>> Did I miss the type-safe, elegant, module-based solution somehow? Or is
>> 1.) as good as it gets?
>>
>>
>> Best regards
>>
>> -Markus
>>
>> --
>> Markus Weißmann, M.Sc.
>> Institut für Informatik
>> Technische Universität München
>> Raum 03.07.054, Boltzmannstr. 3, 85748 Garching
>>
>> Tel. +49 (89) 2 89-1 81 05
>> Fax +49 (89) 2 89-1 81 07
>>
>> mailto:markus.weissmann@in.tum.de
>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
> --
> ----
> http://en.wikipedia.org/wiki/Posting_style
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


  reply	other threads:[~2011-11-04 14:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 13:06 Markus Weißmann
2011-11-04 13:27 ` Matthias Puech
2011-11-04 13:43 ` Pietro Abate
2011-11-04 14:12   ` Gabriel Scherer [this message]
2011-11-04 14:50     ` Vincent Aravantinos
2011-11-06 22:08       ` "Markus W. Weißmann"

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='CAPFanBGcb5oWoF-0rSS+XwOGq0MM9NhROaOs+NS=0mrHDO4AVg@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=Pietro.Abate@pps.jussieu.fr \
    --cc=caml-list@inria.fr \
    /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).