Re: [Caml-list] OCaml wishlist

Re: [Caml-list] OCaml wishlist

[Richard Jones]

[by accident, this didn't get sent to the list first time]

On Tue, Oct 21, 2003 at 10:38:52AM -0700, David Brown wrote:
> I'm curious what the argument for Ocaml objects being weaker is.  For
> the most part, the OCaml object system is much more flexible, mostly
> because class inheritance and type inheritance are kept seperate.  Are
> you complaining that coersion has to be explicit, and that you can't
> cast to a more specific type?

Thanks for your answer David. In response to the above, I'd say that
I've found OCaml objects to generally be OK, but sometimes they can be
really infuriating! Examples:

* Type inference doesn't work sometimes, so you need to add 'just the
  right' type declaration to an expression to get it to compile.

* Upcasting - sometimes it works, sometimes it requires an explicit
  :> to upcast. Once or twice I've had a really strange error where
  I've needed to do some sort of double upcast-and-type-declaration,
  IIRC it was (obj :> superclass : superclass)

* Polymorphic methods have a really odd & unintuitive syntax.

* It seems like you need to use a separate MLI file to be able to
  define completely private (as opposed to just protected) methods,
  which isn't really documented well.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

-------------------
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] OCaml wishlist

[Jacques Garrigue]

From: Richard Jones <rich@annexia.org>

> Thanks for your answer David. In response to the above, I'd say that
> I've found OCaml objects to generally be OK, but sometimes they can be
> really infuriating! Examples:
> 
> * Type inference doesn't work sometimes, so you need to add 'just the
>   right' type declaration to an expression to get it to compile.

Yes, that's most unfortunate.
There are two such difficulties with classes
* use of polymorphic or labelled methods (you need to know the type of
  the objects)
* escaping type variables in class definitions
For the first one, there is little to be done: whenever you call such
a method, you must make sure the type of the object is known.
For the second one, there is maybe some room for improvement.

> * Upcasting - sometimes it works, sometimes it requires an explicit
>   :> to upcast. Once or twice I've had a really strange error where
>   I've needed to do some sort of double upcast-and-type-declaration,
>   IIRC it was (obj :> superclass : superclass)

It should be  (obj : current :> superclass).
This is the only "guaranteed" cast.
Otherwise, you are trying your luck. Still, simple cast should work
for all non-recursive classes.

> * Polymorphic methods have a really odd & unintuitive syntax.

Sorry. My idea was that they would only be used in very special cases,
particularly considering the typing problem described above.

> * It seems like you need to use a separate MLI file to be able to
>   define completely private (as opposed to just protected) methods,
>   which isn't really documented well.

Not quite: you can also define a class type by hand and constrain your
definition with it.

class c : ct = object ... end

This may be surprising when coming from Java, but this is more
coherent with the rest of the language.

Overall, I would not characterize ocaml objects as weak, but rather
nonintuitive.

Jacques Garrigue

-------------------
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] OCaml wishlist -> my wish

[samsaga2]

It could be well that:

    let hello name = Printf.printf "Hello %s\n" name in
    let nooverride hello number = Printf.printf "You're only a number 
%d!!\n" number in
    hello "samsaga2";
    hello 666

And the output will be:

    Hello samsaga2
    You're only a number 666!!

nooverride label it's optional

Then functions as (+) and (+.) could be:

    let (+) number1 number2 = number1 + number2 in
    let nooverride (+) number1 number2 = number1 +. number2

even

    type vector3 = { x : float; y : float; z : float }
    let nooverride (+) v1 v2 = { x = v1.x + v2.x; y = v1.y + v2.y; z = 
v1.z + v2.z }

But... it's only a wish :-P


-------------------
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] OCaml wishlist

[brogoff]

On Wed, 22 Oct 2003, Jacques Garrigue wrote:
> Overall, I would not characterize ocaml objects as weak, but rather
> nonintuitive.

I agree. They're actually rather powerful. OCaml has multiple inheritance,
whereas Java doesn't.

Unfortunately, they are also nonintuitive, complex, and don't really blend well
with the rest of the language, IMO. I'm thinking of pattern matching here. I
realize that the class system did evolve from an earleir approach based on
records, so it has been thought of before, and there are many issues to
consider...

Still, I hope some future ML variant will address these issues, either by
dispensing with the class system and providing alternative solutions, or maybe
by providing another OO approach (like CLOS/Dylan style) altogether. For now,
OCaml is the only game in town for the working programmer.

-- Brian


-------------------
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] OCaml wishlist

[Eray Ozkural]

On Wednesday 22 October 2003 04:14, Jacques Garrigue wrote:
> Overall, I would not characterize ocaml objects as weak, but rather
> nonintuitive.

Or simply not in accordance with certain conventions of so-called 
object-oriented imperative prog. languages. I don't believe we could say one 
of them is more intuitive.

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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] OCaml wishlist

[skaller]

On Wed, 2003-10-22 at 11:14, Jacques Garrigue wrote:

> Overall, I would not characterize ocaml objects as weak, but rather
> nonintuitive.

I found for basic use they're easy to use .. except for
the long winded type names ..


-------------------
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] OCaml wishlist

[Michal Moskal]

On Tue, Oct 21, 2003 at 09:52:17PM -0500, Brian Hurt wrote:
> On Wed, 22 Oct 2003, Jacques Garrigue wrote:
> 
> > Of course you have to be careful: you can shoot yourself in the foot
> > with wrong indentation:
> > 
> >   let quit _ =
> >     let icon = GMisc.image () in
> >     if !test_id = 0 then (GMain.Main.quit (); false) else
> >     icon#set_stock `DIALOG_QUESTION;
> >     icon#set_icon_size `DIALOG;
> >     [...]
> > 
> > In this case you're just going to jump over icon#set_stock...
> 
> This is a classic problem with dangling-elses, and you see it in C as 
> well:
> 
>     if (x == 3)
>         y = 7;
>         z = 8;

It's dangling semicolon problem :-) 

	if foo then bar
	else
	  let x = baz in 
	  qux;
	  quxx

is different from:

	let x = baz in 
	if foo then bar
	else
	  qux;
	  quxx

let in the beginning changes meaning of semicolon.

-- 
: 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] OCaml wishlist

[Brian Hurt]

On Wed, 22 Oct 2003, Jacques Garrigue wrote:

> Of course you have to be careful: you can shoot yourself in the foot
> with wrong indentation:
> 
>   let quit _ =
>     let icon = GMisc.image () in
>     if !test_id = 0 then (GMain.Main.quit (); false) else
>     icon#set_stock `DIALOG_QUESTION;
>     icon#set_icon_size `DIALOG;
>     [...]
> 
> In this case you're just going to jump over icon#set_stock...

This is a classic problem with dangling-elses, and you see it in C as 
well:

    if (x == 3)
        y = 7;
        z = 8;

Brian


-------------------
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] OCaml wishlist

[Jacques Garrigue]

From: Richard Jones <rich@annexia.org>

> I'm really looking for help on this! My working theory at the moment
> though is that writing UIs involves writing essentially imperative
> code. One small example from some real code:
> 
>   let quit _ =
>     if !test_id = 0 then (
>       GMain.Main.quit (); false
>     ) else (
>       let icon = GMisc.image () in
>       icon#set_stock `DIALOG_QUESTION;
>       icon#set_icon_size `DIALOG;
>       let buttons = [ "Quit"; "Cancel" ] in
>       let ans = GToolbox.question_box ~title:"Quit" ~icon ~buttons
>           ("Are you sure you want to quit? This may lose any\n" ^
>            "results from this assessment.") in
>       if ans = 1 then (
>         GMain.Main.quit (); false       (* User requested quit. *)
>        )
>       else
>         true                            (* Don't close the window. *)
>      )

This is only a problem of indentation:

  let quit _ =
    if !test_id = 0 then (GMain.Main.quit (); false) else
    let icon = GMisc.image () in
    icon#set_stock `DIALOG_QUESTION;
    icon#set_icon_size `DIALOG;
    let buttons = [ "Quit"; "Cancel" ] in
    let ans = GToolbox.question_box ~title:"Quit" ~icon ~buttons
        ("Are you sure you want to quit? This may lose any\n" ^
         "results from this assessment.") in
    ans <> 1 || (GMain.Main.quit (); false)

Of course you have to be careful: you can shoot yourself in the foot
with wrong indentation:

  let quit _ =
    let icon = GMisc.image () in
    if !test_id = 0 then (GMain.Main.quit (); false) else
    icon#set_stock `DIALOG_QUESTION;
    icon#set_icon_size `DIALOG;
    [...]

In this case you're just going to jump over icon#set_stock...

Jacques

-------------------
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] OCaml wishlist

[Alain.Frisch]

On Tue, 21 Oct 2003, Yaron Minsky wrote:

> This seems pretty easy to achieve, although it's a bit messy.  Seems like
> you might be able to clean it up with camlp4.  Here's the basic idea:

This is cleaner than my solution (exception with an argument), though
probably even slower (allocation of the reference, update, inspection).
And both solutions prevent tail calls in the body...

-- 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] OCaml wishlist

[Yaron Minsky]

This seems pretty easy to achieve, although it's a bit messy.  Seems like
you might be able to clean it up with camlp4.  Here's the basic idea:


exception Return

let f ... =
  let rval = ref None in
  try
    ....
      rval := Some ...;
      raise Return
    ....
  with
      Return ->
	match rval with
	    None -> "Bug! function ended without returning"
	  | Some x -> x


-------------------
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] OCaml wishlist

[Yaron Minsky]

Here's a simple way of approximating what you want.  It's ugly, but camlp4
could be used for providing the appropriate syntactic sugar, I imagine.

exception Return

let rval = ref None in
try


with
  Return ->
     match !rval with





> On Tue, Oct 21, 2003 at 01:28:13PM -0400, William Lovas wrote:
>> What you want is a return *statement*, but such a beast is incompatible
>> with O'Caml, since O'Caml is an expression-oriented language.  I don't
>> see
>> an easy way of making a `return' expression that behaves the way you
>> want
>> it to.
>
> Perhaps there's a misunderstanding here. I don't want to change the
> expression-oriented nature of the language. The 'return' would and
> must return the same type as the rest of the code.
>
>> Better, though, in my opinion, would be to adapt your
>> mental syntax to fit the functional style than to adapt the functional
>> language to cater to your imperative style.
>
> I'm really looking for help on this! My working theory at the moment
> though is that writing UIs involves writing essentially imperative
> code. One small example from some real code:
>
>   let quit _ =
>     if !test_id = 0 then (
>       GMain.Main.quit (); false
>     ) else (
>       let icon = GMisc.image () in
>       icon#set_stock `DIALOG_QUESTION;
>       icon#set_icon_size `DIALOG;
>       let buttons = [ "Quit"; "Cancel" ] in
>       let ans = GToolbox.question_box ~title:"Quit" ~icon ~buttons
>           ("Are you sure you want to quit? This may lose any\n" ^
>            "results from this assessment.") in
>       if ans = 1 then (
>         GMain.Main.quit (); false       (* User requested quit. *)
>        )
>       else
>         true                            (* Don't close the window. *)
>      )
>   in
>
>   window#connect#destroy ~callback:GMain.quit;
>   window#event#connect#delete ~callback:quit;
>   quit_item#connect#activate ~callback:(fun () -> quit (); ());
>
> I think there's definitely a case for being able to write:
>
>   if !test_id = 0 then (	(* Not in a test - can quit immediately. *)
>     GMain.Main.quit ();
>     return false
>   );
>
>   (* .. rest of code ... *)
>
> But perhaps, as you say, I'm missing the functional solution to this.
>
> (I can dig around and find some more examples like this if it would help).
>
> Rich.
>
> --
> Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
> Merjis Ltd. http://www.merjis.com/ - all your business data are belong to
> you.
> MAKE+ is a sane replacement for GNU autoconf/automake. One script
> compiles,
> RPMs, pkgs etc. Linux, BSD, Solaris.
> http://www.annexia.org/freeware/makeplus/
>
> -------------------
> 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
>

-------------------
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] OCaml wishlist

[Alain.Frisch]

On Tue, 21 Oct 2003, William Lovas wrote:

> I don't think it would be beneficial in the long run to clutter up the core
> language with these sorts of purely syntactic issues

Not quite. Even without escaping loops, the "return" statement is more
than syntax. Consider:

let f x =
  ...
  match .. with
   | .. ->
       let .. = (if ... then return "Booh!" else ...)

In some cases, GOTOs^Wstatic exceptions are just a decent solution to
shortcut the normal functional control flow, and much more efficient than
dynamic exceptions. Internally, OCaml has such a mechanism (see
bytecomp/lambda.mli, Lstatic* constructors, used for the compilation of
pattern matching), which, I guess, could be quite easily be exposed in a
type-safe way to the surface language. Note that I'm not really asking for
such a feature.

-- 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] OCaml wishlist

[Richard Jones]

On Tue, Oct 21, 2003 at 01:28:13PM -0400, William Lovas wrote:
> What you want is a return *statement*, but such a beast is incompatible
> with O'Caml, since O'Caml is an expression-oriented language.  I don't see
> an easy way of making a `return' expression that behaves the way you want
> it to.

Perhaps there's a misunderstanding here. I don't want to change the
expression-oriented nature of the language. The 'return' would and
must return the same type as the rest of the code.

> Better, though, in my opinion, would be to adapt your
> mental syntax to fit the functional style than to adapt the functional
> language to cater to your imperative style.

I'm really looking for help on this! My working theory at the moment
though is that writing UIs involves writing essentially imperative
code. One small example from some real code:

  let quit _ =
    if !test_id = 0 then (
      GMain.Main.quit (); false
    ) else (
      let icon = GMisc.image () in
      icon#set_stock `DIALOG_QUESTION;
      icon#set_icon_size `DIALOG;
      let buttons = [ "Quit"; "Cancel" ] in
      let ans = GToolbox.question_box ~title:"Quit" ~icon ~buttons
          ("Are you sure you want to quit? This may lose any\n" ^
           "results from this assessment.") in
      if ans = 1 then (
        GMain.Main.quit (); false       (* User requested quit. *)
       )
      else
        true                            (* Don't close the window. *)
     )
  in

  window#connect#destroy ~callback:GMain.quit;
  window#event#connect#delete ~callback:quit;
  quit_item#connect#activate ~callback:(fun () -> quit (); ());

I think there's definitely a case for being able to write:

  if !test_id = 0 then (	(* Not in a test - can quit immediately. *)
    GMain.Main.quit ();
    return false
  );

  (* .. rest of code ... *)

But perhaps, as you say, I'm missing the functional solution to this.

(I can dig around and find some more examples like this if it would help).

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
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] OCaml wishlist

[David Brown]

On Tue, Oct 21, 2003 at 03:29:21PM +0100, Richard Jones wrote:

> 1. 'return' from a function. eg:
> 
>   let foo x =
>     if x < 0 then return "OSL";
>     (* long & complex code *)
>     return "some other string"

let return x = x

> 2. abstract data type syntactic sugar:
> 
>    let hash = Hashtbl.create 16 in
>    hash#add "foo" 10;		or:   hash->add "foo" 10;
>    hash#add "bar" 20;		or:   hash->add "bar" 20;
> 
>    The syntactic sugar is that if a module contains a type called
>    M.t (literally "type t"), and obj has type M.t, then:
> 
>    obj#call		      [	or:   obj->call ]
> 
>    is exactly equivalent to:
> 
>    M.call obj

As pointed out in another post, there are type issues with this.  These
new constructs have to be polymorphic in the same ways that objects are.
If you want an object interface to something, it is probably best to
just do it that way.

>    I think this change would help a lot of Java programmers (<gr>) who
>    would otherwise tend to jump immediately on using objects, which are
>    an area where OCaml is weaker.

I'm curious what the argument for Ocaml objects being weaker is.  For
the most part, the OCaml object system is much more flexible, mostly
because class inheritance and type inheritance are kept seperate.  Are
you complaining that coersion has to be explicit, and that you can't
cast to a more specific type?

I would suspect most instances of needing these casts in Java is due to
Java's much weaker type system.

There are some problems where an OO solution maps well to the problem.
There are many other problems where trying to force it into an OO model
only obscures the problem.  Ocaml is nice in that it gives you a choice.
The flexibility occasionally means that a particular model may not be as
easy to use as in a language where that is the only model available.

Dave

-------------------
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] OCaml wishlist

[William Lovas]

> On Tue, Oct 21, 2003 at 03:29:21PM +0100, Richard Jones wrote:
On Tue, Oct 21, 2003 at 04:55:31PM +0200, Michal Moskal wrote:
> > 2. abstract data type syntactic sugar:
> >    obj#call		      [	or:   obj->call ]
> > 
> >    is exactly equivalent to:
> > 
> >    M.call obj
> 
> let f a b c = a->add b c
> 
> What type does f have? 

You could disambiguate by adding a module qualifier: `a->M.add b c'.  But
then, this can be done with an ordinary infix operator:

    # let (=>) obj meth = meth obj;;
    val ( => ) : 'a -> ('a -> 'b) -> 'b = <fun>
    # let l = [(1, "abc")];;
    val l : (int * string) list = [(1, "abc")]
    # l=>List.length;;
    - : int = 1
    # l=>List.assoc 1;;
    - : string = "abc"

... as long as you don't mind using a slightly different arrow, anyway --
`->' isn't a valid identifier due to O'Caml's lexical conventions.

Viewed in this way, though, this is really no more than an obfuscation of
code.  Providing multiple syntaxes for the same concept starts one down the
slippery slope of creating a write-only language (witness Perl).

> > After writing a fair bit of OCaml in commercial situations (although
> > I'm by no means an expert, and really should learn camlp4), here's my
> > wishlist:
> > 
> > 1. 'return' from a function. eg:
> > 
> >   let foo x =
> >     if x < 0 then return "OSL";
> >     (* long & complex code *)
> >     return "some other string"
> > 
> >   I know I can do this using if ... else, but when you have multiple
> >   levels of if ... else you end up being indented so far across the
> >   screen as to make coding unpleasant. 

This one's quite a bit more difficult, though: what is the type of a
`return'?  Under the current typing rules for if-then-else expressions, it
must be `unit', since the `else' branch has been omitted.  But if it's
unit, then the function returns unit, which is incorrect.

What you want is a return *statement*, but such a beast is incompatible
with O'Caml, since O'Caml is an expression-oriented language.  I don't see
an easy way of making a `return' expression that behaves the way you want
it to.

However, i will point out that code indentation is merely a programmer
convention, and is not enforced by the syntax of the language -- so you
could do what you want using ordinary O'Caml if-then-else expressions and
*still* not have your code be too indented:

    let foo x =
        if x < 0 then
            (* special case for negative x *)
            "OSL"
        else
        (* normal case *)
        <long and complex code>
        "some other string"


I don't think it would be beneficial in the long run to clutter up the core
language with these sorts of purely syntactic issues -- that's why we have
camlp4, isn't it?  Better, though, in my opinion, would be to adapt your
mental syntax to fit the functional style than to adapt the functional
language to cater to your imperative style.  That way, you end up producing
clearer code that can be read by any competent O'Caml programmer -- a major
win for the poor maintainer 10 years down the road! :)

cheers,
William

-------------------
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] OCaml wishlist

[Richard Jones]

On Tue, Oct 21, 2003 at 04:55:31PM +0200, Michal Moskal wrote:
> This is however religious issue.

It wasn't meant to be (honest!). I just want to write code in whatever
paradigm is best for the moment, be that OO, functional or imperative.
My point is actually just that if you're writing user interface code,
then what you're doing is essentially going to be imperative most of
the time.

> > 2. abstract data type syntactic sugar:
> >    obj#call		      [	or:   obj->call ]
> > 
> >    is exactly equivalent to:
> > 
> >    M.call obj
> 
> let f a b c = a->add b c
> 
> What type does f have? 

Several correspondents asked the same question, and I understand that
you can't infer the type in this case. So the answer would be that
it's an error.

This makes sense because the -> syntax isn't meant to be a substitute
for object oriented programming / late binding :-)

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/

-------------------
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] OCaml wishlist

[Alain.Frisch]

On Tue, 21 Oct 2003, Richard Jones wrote:

> 1. 'return' from a function. eg:
>
>   let foo x =
>     if x < 0 then return "OSL";
>     (* long & complex code *)
>     return "some other string"
>
>   I know I can do this using if ... else, but when you have multiple
>   levels of if ... else you end up being indented so far across the
>   screen as to make coding unpleasant. This is particularly a concern
>   with writing basically imperative UI code.
>
>   Is it possible to do something like this with camlp4? (as a stopgap -
>   I still think it should go into the language)

With Camlp4 and the Obj module, yes, it should be possible, but
inefficient. I assume you want to be able to escape from loops,
so you have to use exceptions (if you don't want to escape from loops,
I guess you can avoid using exceptions, with a lot of extra option types).

You can use Camlp4 to expand

fun x -> ... (return e1) ... (return e2) ... e

(the return statements are not under abstractions)

to:

fun x -> (try ... (raise (Return (Obj.repr (e1 : 'a))))
              ... (raise (Return (Obj.repr (e1 : 'a))))
              ... e2
          with Return x -> Obj.magic x) : 'a

with a global definition:

exception Return of Obj.t

You need the 'a annotation to ensure type-safety (btw, would the above
version be correct in all cases?). Of course the 'a name should be unique
for the abstraction.

AFAIK, it is not possible to define in a syntax extension a local
exception (inside a "let module M = struct ... end in ...") with an
argument of the return type (which is unknown at preprocessing time,
and moreover it might be polymorphic).

Needless to say, this will be inefficient.

> 2. abstract data type syntactic sugar:

How does it interact with type inference?


Cheers,

 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] OCaml wishlist

[Michal Moskal]

On Tue, Oct 21, 2003 at 03:29:21PM +0100, Richard Jones wrote:
> After writing a fair bit of OCaml in commercial situations (although
> I'm by no means an expert, and really should learn camlp4), here's my
> wishlist:
> 
> 1. 'return' from a function. eg:
> 
>   let foo x =
>     if x < 0 then return "OSL";
>     (* long & complex code *)
>     return "some other string"
> 
>   I know I can do this using if ... else, but when you have multiple
>   levels of if ... else you end up being indented so far across the
>   screen as to make coding unpleasant. 

You can try guarded patterns. I have to admit that OCaml makes
imperative programming somewhat harder then it strictly have to. This is
however religious issue.

> 2. abstract data type syntactic sugar:
>    obj#call		      [	or:   obj->call ]
> 
>    is exactly equivalent to:
> 
>    M.call obj

let f a b c = a->add b c

What type does f have? 

-- 
: 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

[Caml-list] OCaml wishlist

[Richard Jones]

After writing a fair bit of OCaml in commercial situations (although
I'm by no means an expert, and really should learn camlp4), here's my
wishlist:

1. 'return' from a function. eg:

  let foo x =
    if x < 0 then return "OSL";
    (* long & complex code *)
    return "some other string"

  I know I can do this using if ... else, but when you have multiple
  levels of if ... else you end up being indented so far across the
  screen as to make coding unpleasant. This is particularly a concern
  with writing basically imperative UI code.

  Is it possible to do something like this with camlp4? (as a stopgap -
  I still think it should go into the language)

2. abstract data type syntactic sugar:

   let hash = Hashtbl.create 16 in
   hash#add "foo" 10;		or:   hash->add "foo" 10;
   hash#add "bar" 20;		or:   hash->add "bar" 20;

   The syntactic sugar is that if a module contains a type called
   M.t (literally "type t"), and obj has type M.t, then:

   obj#call		      [	or:   obj->call ]

   is exactly equivalent to:

   M.call obj

   I think this change would help a lot of Java programmers (<gr>) who
   would otherwise tend to jump immediately on using objects, which are
   an area where OCaml is weaker.

What do other people think?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

-------------------
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