[Caml-list] Constructors as functions and tuples in constructors

[Caml-list] Constructors as functions and tuples in constructors

[Serge]

Gentlemen!

There are two features, which might it be useful to support in the 
language w/out modifying it much. And they both are about greater
generality of the language.

First, it would be nice to have constructors as functions like below:

List. map Some [17]

Second, it would also be nice not to have "the concept of constructor
arity", and treat the code below as correct:

type t = A of int * int
let _ = 
  match A (17, 0) with
    A z -> match z with (x, y) -> ()

Does anybody know, whether this is possible? Or, if not, what are the
prohibiting reasons?

-------------------------------------------------------------------------------
 Serge S. Bityukov, Moscow State University, Dept of Mechanics and Mathematics

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Dan Grossman]

Serge wrote:
> First, it would be nice to have constructors as functions like below:
> 
> List. map Some [17]

Leads to strange error messages and is trivially circumventable (replace 
Some with fun x -> Some x)

> Second, it would also be nice not to have "the concept of constructor
> arity", and treat the code below as correct:
> 
> type t = A of int * int
> let _ = 
>   match A (17, 0) with
>     A z -> match z with (x, y) -> ()

Works with type t = A of (int * int).  You put the parens in.  So the 
choice is yours.  The advantage of leaving them out is usually performance.

Others can give the long version of these answers...

--Dan



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Andreas Rossberg]

Dan Grossman wrote:
> 
>> Second, it would also be nice not to have "the concept of constructor
>> arity", and treat the code below as correct:
>>
>> type t = A of int * int
>> let _ =   match A (17, 0) with
>>     A z -> match z with (x, y) -> ()
> 
> Works with type t = A of (int * int).  You put the parens in.  So the 
> choice is yours.  The advantage of leaving them out is usually performance.

That is not true. It would be quite trivial for the compiler to translate

   A z -> e

into the equivalent of

   A(z1,z2) -> let z = (z1,z2) in e

without affecting performance of other programs in any way. Likewise,

   A z

could be transformed into

   let (z1,z2) = z in A(z1,z2)

instead of rejecting it. OTOH, your workaround certainly decreases 
performance for type t, as other pointed out.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Dan Grossman]

A good point, with these rebuttals:

(1) A pattern-match would have the potential of allocating memory, which 
some may judge poorly.  But the compiler could warn about this.

(2) This transformation does require the type A carries is transparent. 
  So we still couldn't relax the "other" restriction that a signature 
cannot hide an unparenthesized t1 * t2 variant.

(3) It's not clear how far this trivial transformation should be 
generalized.  For example, given
   type t = A of int * int * int * int
which of these should we allow
   A(1,2,3,4)
   A((1,2,3,4))
   A((1,2),(3,4))
   A(1,(2,3),4)
   ...

--Dan

Andreas Rossberg wrote:
> Dan Grossman wrote:
> 
>>
>>> Second, it would also be nice not to have "the concept of constructor
>>> arity", and treat the code below as correct:
>>>
>>> type t = A of int * int
>>> let _ =   match A (17, 0) with
>>>     A z -> match z with (x, y) -> ()
>>
>>
>> Works with type t = A of (int * int).  You put the parens in.  So the 
>> choice is yours.  The advantage of leaving them out is usually 
>> performance.
> 
> 
> That is not true. It would be quite trivial for the compiler to translate
> 
>   A z -> e
> 
> into the equivalent of
> 
>   A(z1,z2) -> let z = (z1,z2) in e
> 
> without affecting performance of other programs in any way. Likewise,
> 
>   A z
> 
> could be transformed into
> 
>   let (z1,z2) = z in A(z1,z2)
> 
> instead of rejecting it. OTOH, your workaround certainly decreases 
> performance for type t, as other pointed out.
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Andreas Rossberg]

Dan Grossman wrote:
> 
> (1) A pattern-match would have the potential of allocating memory, which 
> some may judge poorly.  But the compiler could warn about this.

Good point, but I don't think anybody would really care.

> (2) This transformation does require the type A carries is transparent. 
>  So we still couldn't relax the "other" restriction that a signature 
> cannot hide an unparenthesized t1 * t2 variant.

Of course, no change there.

> (3) It's not clear how far this trivial transformation should be 
> generalized.  For example, given
>   type t = A of int * int * int * int
> which of these should we allow
>   A(1,2,3,4)
>   A((1,2,3,4))
>   A((1,2),(3,4))
>   A(1,(2,3),4)
>   ...

Not sure what your getting at. OCaml makes otherwise redundant 
parentheses around constructor argument types significant. That is a 
hack to allow for a more efficient representation. The idea is to make 
that hack as transparent as possible.

But that aim of course is unrelated to changing the meaning of the 
multifix type operator * itself. So the first two of your examples 
should certainly be legal (and they are already), while the others 
should not, no more than

   ((1,2),(3,4)) : int * int * int * int  (* eek! *)
   (1,(2,3),4) : int * int * int * int   (* ouch! *)

- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Alain.Frisch]

On Wed, 8 Oct 2003, Andreas Rossberg wrote:

> That is not true. It would be quite trivial for the compiler to translate
>
>    A z -> e
>
> into the equivalent of
>
>    A(z1,z2) -> let z = (z1,z2) in e

Maybe:

   A _ as z -> e

would be enough (well, not for typechecking, of course) and avoid an extra
allocation. The idea is that any piece of code working on a pair (z1,z2)
can also work on A(z1,z2) since the runtime repsentation is the same,
except the tag which is not used.

-- Alain

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Marcin 'Qrczak' Kowalczyk]

W liście z śro, 08-10-2003, godz. 20:28, Alain.Frisch@ens.fr pisze:

> The idea is that any piece of code working on a pair (z1,z2)
> can also work on A(z1,z2) since the runtime repsentation is the same,
> except the tag which is not used.

Equality would break.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Michal Moskal]

On Wed, Oct 08, 2003 at 07:57:03PM +0400, Serge wrote:
> 
> Gentlemen!

Well, maybe there are some ladies here? :-)

[...]

> Second, it would also be nice not to have "the concept of constructor
> arity", and treat the code below as correct:
> 
> type t = A of int * int
> let _ = 
>   match A (17, 0) with
>     A z -> match z with (x, y) -> ()

Just need to use () after "of", like this:

# type t = A of (int * int);;
type t = A of (int * int)
# let _ = match A (17, 0) with A z -> z;;
- : int * int = (17, 0)
# 

However constructing A of int * int takes one allocation (it's
<tag_of_a> <int> <int>), while A of (int * int) -- two (it's <tag_of_a>
<ptr_to_int_int>). Referencing it also takes one indirection more.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Constructors as functions and tuples in constructors

[Nicolas Cannasse]

> Gentlemen!
>
> There are two features, which might it be useful to support in the
> language w/out modifying it much. And they both are about greater
> generality of the language.
>
> First, it would be nice to have constructors as functions like below:
>
> List. map Some [17]

This is only syntaxic sugar. First class constructors are easy to add to the
language, that's just a matter of will from the INRIA team to choose to add
it or not ( meaning : since they didn't put the feature in the language yet,
they might have good reasons to do so. ).

> Second, it would also be nice not to have "the concept of constructor
> arity", and treat the code below as correct:
>
> type t = A of int * int
> let _ =
>   match A (17, 0) with
>     A z -> match z with (x, y) -> ()
>
> Does anybody know, whether this is possible? Or, if not, what are the
> prohibiting reasons?

This is possible :
type t = A of (int * int)

Notice the difference :
- in the first case, you alloc a block with tag "A" of size 2
- in the second, you alloc a block with tag "A" of size 1 containing a tuple
(a block of size 2 with tag 0 containing the two ints). There is then one
more indirection in your integers access but the tuple can be returned
directly without any added allocation.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners