caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Julian Assange <proff@iq.org>
To: caml-list@inria.fr
Cc: proff@iq.org
Subject: types, determination, seperate compilation and side effects
Date: 20 Mar 2000 14:10:00 +1100	[thread overview]
Message-ID: <wxityis5fb.fsf@suburbia.net> (raw)


It would be nice if the hindley-milner type system of ocaml were
extended to provide unioning of determination, world-state-changes,
mutagenic behavior etc as types. That is, if a function is discovered
to lack referential transparency, either because it has side effects
or calls functions which have side effects then that fact is reflected
in the type of the function.  This would permit the optimiser to
perform code-flow elimination accross modules (and might make flow
analysis within the same module easier).

It is quite interesting to consider multiple argument functions. In
ocaml multiple argument functions are rearranged into multiple curried
forms. Type analysis of each form, as above, could result in
elimination of that form if it has been typed as referentially
transparent and found not to contribute to the calculation it was
called from. Code flow analysis could do this already (theoretically),
but not accross seperately compiled modules.

It would be very useful for ocaml hackers to see if a non referentially
transparent type was inferred for a function (and whether the cause
was io, potential non-termination, or operation on mutables) or have
the compiler discover conflicts between functions hand annotated as
referentially transparent but inferred otherwise.

I'm not sure how functions which potentially raise exceptions should be
typed.

Mercury (souped up prolog with functional desires from Melbourne
University) supports determinacy annotations and checking, but the
methodes employed are verbose and visually unpleasant. However, the
designers do say that this has allowed them to catch several hundred
errors during the development of the Mercury compiler and given the
opimiser enough contraints to dramatically improve the speed of
generated code (and it does generate fast code in an absolute sense,
so there must be some truth in this).

Cheers,
Julian.



                 reply	other threads:[~2000-03-21 14:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=wxityis5fb.fsf@suburbia.net \
    --to=proff@iq.org \
    --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).