From: skaller <skaller@users.sourceforge.net>
To: IdeFX@Iname.com
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] troubles with polymorphic variant in class
Date: 14 Jun 2004 03:59:51 +1000 [thread overview]
Message-ID: <1087149590.16811.1342.camel@pelican.wigram> (raw)
In-Reply-To: <1087142756.10383.50.camel@Bess>
On Mon, 2004-06-14 at 02:05, François-Xavier HOUARD wrote:
> The method add_child has type ([> `Whatever ] as 'a) -> unit where 'a
> is unbound
> _Is there another way to make it ???
The notation [> `X] does not denote a type, but a family
of types (all types containing variant `X). Alternatively
you might say it is a type constraint.
But a list must have elements of a definite type.
You can define the type as for ordinary variants:
type widget = [ `Whatever | `Window of window | `Button of button]
and now make a widget list.
Unfortunately, you cannot add child widgets to a button
like this:
class button = object
val mutable (childs:widget list)
method add_child x = childs <- x::childs
end
because button isn't defined yet .. and neither
is window... so you can't define widget.
Unfortunately the obvious way to fix this doesn't
work due to a syntactic problem in Ocaml:
type widget = ...
and class window = ...
and class button = ...
is what you need: mutual recursion. But it isn't allowed
to mutually recurse types and classes (not even class types).
So a direct solution is unfortunately impossible.
You must add a type parameter to each class like this:
class ['w] button' = ... (childs: 'w list)
class ['w] window' = .. .(childs: 'w list) ...
and now you can define:
type 'w widget' = [`Window of ['w] window' | ...
Because these things all use a parameter,
they can all be defined without any mutual
recursion. So now you do this:
(* fixpoint *)
type widget = 'w widget' as 'w
which effectively solves the type equation
'w = 'w widget (and names the result widget).
Now define non-polymorphic classes:
class button = [widget] button'
class window = [widget] window'
This is not so bad for a single parameter 'w.
For multiple parameters the notation soon becomes
too unwieldy to be practical.
--
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2004-06-13 18:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-13 16:05 François-Xavier HOUARD
2004-06-13 17:59 ` skaller [this message]
2004-06-14 9:29 ` François-Xavier HOUARD
2004-06-14 9:48 ` Damien Doligez
2004-06-14 15:49 ` skaller
2004-06-14 9:37 ` Richard Jones
2004-06-14 14:48 ` nakata keiko
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=1087149590.16811.1342.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=IdeFX@Iname.com \
--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