caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Arturo Borquez <aborquez@altavista.com>
To: garrigue@kurims.kyoto-u.ac.jp
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Date: 3 Apr 2001 00:27:54 -0700	[thread overview]
Message-ID: <20010403072754.6490.cpmta@c012.sfo.cp.net> (raw)

Hi Jacques:
Some personal history with labels. At 70's I was involved in software development in CICS/VS (IBM/370) The IBM Macro-Assembler supported the use of labels and they were (are) very handly. That labels have the following properties (if my mind don't betray me)

1) In absolute abcence of labels the macros accepted parameters by position (as normal without labels).

2) Labeled parameters could be passed 'out of position' doing things very happy. (as in commuted mode)

3) Macros could be partial labeled, and all of those unlabeled parameters where (are) passed in order (after labeled parameters are assigned) in the 'empty holes' as in 1) by order.

4) the use of labels at the caller were (are) optative for labeled parameters (free or idiosincratic choice of the programmer).

ie:
(not OCaml code)

function1(text:t,pos:(x,y),mode:m,highlight:h)
body .......... etc

So we could write some variations:

1) function1("A Text",10,14,normal,on) completly by position with any label.

2) function1 (pos=(10,14),
              normal,on <-- mode & highligth
              text="A Text")
 Using labeling partially, so in this case unlabeled params at the caller are resolved after 'pos' and 'text' are filled taking the 'empty holes', first 'normal' is placed in 'mode' and second 'on' is places in 'highlight'.

By those years I coded a 8080 uCPU prepocessor copying this idea and worked fine.

Some experiments with OCaml showed me (if I am right) in the 'classic/normal' mode we can use labels always in order (position) and optional to use it or not.
ie;

# let f ~a b = a + b;;
val f : a:int -> int -> int = <fun>
# f 1 2;;
- : int 3

same result with f ~a:1 2, but drops error if we write f 1 ~a:2, so obviously classic mode not commute!. Also specifying defaults and partial application works! 

Now see labels in commuting mode (#labels true;;)

# f 2 ~a:1;;
- : int = 3;; commuting works! but
# f 1 2;; fails! (this arg. cannot be applied with...)

So in commuting mode labels must be always specified! you gain 'position freedom' and lose optional label use of 'classic mode'.

In my example of IBM Macro-Assembler you have both, optative labeling (of labeled functions) and arbitrary position for labeled arguments. 

For my 'personal taste' it would be very cool that the commuting mode preserve all properties of 'classic-mode'. Sorry but I don't know if there is a mathematical impediment (currying type inference or other) or only is an implementation issue. If this option 'is possible' it seems me that there is no need to change any 'labeled or unlabeled' library, and the goal to fit all in a single mode is achieved.

if I am wrong, please be indulgent with a beginner.

Best Regards.
Arturo Borquez


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


             reply	other threads:[~2001-04-03  7:28 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-03  7:27 Arturo Borquez [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-04-17 11:53 Poigné
2001-04-11 10:48 Francois-Rene Rideau
2001-04-04 16:37 Dave Berry
2001-04-03 16:39 John R Harrison
2001-03-31  3:40 [Caml-list] Future of labels Yaron M. Minsky
2001-04-02  3:39 ` [Caml-list] Future of labels, and ideas for library labelling Jacques Garrigue
2001-04-02  7:58   ` Judicael Courant
2001-04-02  8:50     ` Markus Mottl
2001-04-02 10:33     ` kahl
2001-04-03  0:35       ` Jacques Garrigue
2001-04-03  1:36         ` Kipton M Barros
2001-04-03  1:52         ` Patrick M Doane
2001-04-03  3:53           ` Jacques Garrigue
2001-04-03  5:10             ` Patrick M Doane
2001-04-03  9:30               ` Jacques Garrigue
2001-04-03  8:52             ` Xavier Leroy
2001-04-03  9:34               ` Judicael Courant
2001-04-03  9:54               ` Jacques Garrigue
2001-04-03 12:59                 ` Jean-Christophe Filliatre
2001-04-03 14:06                   ` Jacques Garrigue
2001-04-03 14:12                     ` Daniel de Rauglaudre
2001-04-03 14:42                       ` Claude Marche
2001-04-04 19:18                     ` Gerd Stolpmann
2001-04-03  9:55               ` Ohad Rodeh
2001-04-03 12:02               ` Dave Mason
2001-04-03 13:43               ` Francois-Rene Rideau
2001-04-03 14:23                 ` Daniel de Rauglaudre
2001-04-03 13:43               ` Frank Atanassow
2001-04-03 13:58               ` Joshua D. Guttman
2001-04-03 16:52               ` Eric C. Cooper
2001-04-09  9:05                 ` John Max Skaller
2001-04-09  7:29             ` John Max Skaller
2001-04-03  8:07         ` Judicael Courant
2001-04-03  6:55     ` Chris Hecker
2001-04-09  8:11       ` John Max Skaller
2001-04-09  9:21         ` Jacques Garrigue
2001-04-09 15:06           ` Fergus Henderson
2001-04-10 18:49           ` John Max Skaller
2001-04-09 19:54         ` Chris Hecker
2001-04-10  3:37           ` Jacques Garrigue
2001-04-10  7:42             ` Judicael Courant
2001-04-10  8:25               ` Jacques Garrigue
2001-04-10  8:46               ` Claude Marche
2001-04-10 10:09                 ` Jacques Garrigue
2001-04-10 14:42                   ` Lionnel Maugis
2001-04-10  9:06             ` François-René Rideau
2001-04-11 15:34               ` Jacques Garrigue
2001-04-11 17:48                 ` Dave Mason
2001-04-10 22:43             ` Brian Rogoff
2001-04-11  8:29               ` Jacques Garrigue
2001-04-11  9:44                 ` Anton Moscal
2001-04-11 13:16                 ` Didier Remy
2001-04-11 15:11                   ` Jacques Garrigue

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=20010403072754.6490.cpmta@c012.sfo.cp.net \
    --to=aborquez@altavista.com \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /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).