caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: calla@knuth.univ-poitiers.fr
To: Xavier.Leroy@inria.fr
Cc: caml-list@margaux.inria.fr, John.Harrison@cl.cam.ac.uk,
	John.Harrison@cl.cam.ac.uk
Subject: Irrelevant variables in patterns
Date: Mon, 30 May 94 19:20:50 +0100	[thread overview]
Message-ID: <9405301820.AA15655@knuth.univ-poitiers.fr> (raw)
In-Reply-To: John Harrison's message of Mon, 30 May 94 15:49:46 +0100 <"swan.cl.cam.:029090:940530144959"@cl.cam.ac.uk>


   Le probleme est excatement le meme en ADA qui a la meme philosophie des
  exceptions que caml, meme si le mecanisme est plus puissant en Caml.

   Le probleme de fond est le suivant me semble-t-il : on traite syntaxiquement
 et semantiquement  de la meme  facon  des exceptions de nature tres differentes
 quand au  comportement du  programme a l'execution :
 
  1)celles qui sont  definies par le programmeur comme un moyen de programmation
 qui evite des test dans des cas tordus et qui sont bien pratiques
 
  2) celles qui sont generees par le run-time du langage  mais qui sont de meme 
 utilite (du genre Failure "hd" et autres  Invalid_argument ..)
  
  et enfin celles qui viennent du systeme hote dont le plus bel exemple est 
  Out_Of_memory, mais qui peuvent etre moins catatrophiques comme celles
 liees aux entrees-sorties.

   Si on veut ecrire des softs robustes, on ne peut s'interdire de traiter
 ces dernieres, meme  Out_Of_memory, mais la solution serait une hierachisation
 des exceptions dans le langage, avec des constructions differentes pour
 le traitement. Certes ca complique certainement l'ecriture du compilateur,
 et je ne connais pas grand chose aux problemes semantiques poses par les 
 exceptions, mais ca me semble une solution plus serieuse que d'imposer des
 contraintes  de syntaxe un peu arbitraires. 
    Mais sans doute demande-je la lune.
            
            Pierre Calladine.






  reply	other threads:[~1994-05-30 17:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-05-26 13:03 Judicael Courant
1994-05-27 18:01 ` Christophe Raffalli
1994-05-28 10:16   ` Chet Murthy
1994-05-28 10:36     ` Christophe Raffalli
1994-05-28 10:43       ` Chet Murthy
1994-05-28 11:01         ` Christophe Raffalli
1994-05-28 11:05           ` Chet Murthy
1994-05-28 11:09             ` Christophe Raffalli
1994-05-28 11:08         ` Christophe Raffalli
1994-05-28 11:12           ` Chet Murthy
1994-05-30 14:49         ` John Harrison
1994-05-30 18:20           ` calla [this message]
1994-05-30  8:53 ` Xavier Leroy
1994-05-30 17:57   ` Christophe Raffalli
1994-05-27 18:58 Damien Doligez
1994-05-30 13:15 Judicael Courant

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=9405301820.AA15655@knuth.univ-poitiers.fr \
    --to=calla@knuth.univ-poitiers.fr \
    --cc=John.Harrison@cl.cam.ac.uk \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@margaux.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).