From: skaller <skaller@maxtal.com.au>
To: Pierre Weis <Pierre.Weis@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: Rebinding exception declarations
Date: Sun, 17 Oct 1999 21:15:04 +1000 [thread overview]
Message-ID: <3809AFB8.F6CF5FB2@maxtal.com.au> (raw)
In-Reply-To: <199910150712.JAA01968@pauillac.inria.fr>
Pierre Weis wrote:
> > Actually, I think there is a more syntactic problem: ocaml uses
> > special 'kinds' of bindings, for some reason that escapes me:
> >
> > type X = ..
> > class X = ..
> > exception ..
> > let X = ..
> > let rec X =
> > module X =
> >
> > which permit recursion with an 'and' option. Unfortunately,
> > this syntax does not permit these kinds of bindings to be
> > mutually recursive (quite aside from the semantic issues).
>
> Not aside from, but due to semantic issues.
>
> > I find this syntax strange, I would have expected
> >
> > let X =
> >
> > be enough for all kinds of bindings, determined by the
> > kind of the right hand side.
>
> I understand: you start everything by let and then distinguish the
> construction you are using by some keyword to determine the kind of
> the right hand side. It would ressemble something like:
>
> let x = type ..
> let c = class ..
> let E = exception ..
> let M = module ..
> let _ = .. (for expression only)
>
> I think the regular syntax of Caml is simpler and more intuitive.
But if that is the only argument, then your
previous claim:
> Not aside from, but due to semantic issues.
is not quite correct.
> Apart from syntax, once more it is a semantic problem: modules are not
> values, values are not types, exception are not classes, classes are
> not functors. We prefer to have a direct reflection of these semantics
> distinctions in the syntax: we hope it may induce a clear distinction
> in the programmer's ideas.
I accept the intuition, but this leaves the problem
that recursions between say, a class and an algebraic type,
cannot be expressed directly using the 'and' option.
Had the syntax been:
let class X = ..
and class Y =
we could have added
and type algebraic = ..
There are cases where this can be proved to work.
For example, by first abstracting the algebraic
types out of the classes (making them type parameters),
then declaring the algbraic types, and then
instantiating the classes with the appropriate
types. I'm not certain, but it seems this is general,
so that mixing class and algebraic types recursively should
be OK .. if only there were a syntax for it.
--
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller
next prev parent reply other threads:[~1999-10-18 14:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-13 16:59 Manuel Fahndrich
1999-10-14 22:52 ` skaller
1999-10-15 7:12 ` Pierre Weis
1999-10-17 11:15 ` skaller [this message]
1999-10-17 14:22 ` Xavier Leroy
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=3809AFB8.F6CF5FB2@maxtal.com.au \
--to=skaller@maxtal.com.au \
--cc=Pierre.Weis@inria.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