Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Future of labels, and ideas for library labelling
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Arturo Borquez <aborquez@a...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
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).

(not OCaml code)

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.

# 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!
To unsubscribe, mail  Archives: