Language improvements (?)

Language improvements (?)

[Frank Christoph]

  Since we are griping about language features, allow me to put in my two
cents about a few (admittedly even more) trivial matters.

  First, it would be nice to be able to hide pervasives so that, in order to
use a pervasive, you would need to qualify it explicitly, e.g.,
"Pervasives.char".  I know that you can redefine a pervasive if you want to
(at least in the interpreter), but unless you can hide the Pervasives module,
you run into problems in recursive scopes like class definitions.  I ran into
this problem defining a unicode module where I wanted to reuse the names
"char" and "string" so I could refer to them as "Unicode.char" and
"Unicode.string".

  Second, if you are going to put objects in the language, it would be useful
to make some of the primitives objects as well.  For example, it would have
been nice to be able to coerce a "c:char" to a unicode character via the
coercion operator, "c:char :> Unicode.char".  Of course you can define your
own character class, but that introduces a new type so you can't use it with
all the library functions that operate on chars.  In fact, the same could be
said for most of the library as well.  I realize most of it was taken from
Caml Light and hasn't been fully converted yet, but many library modules are
well-suited to the object paradigm, for example, hash tables.

  Third, since the trend in O'Caml is toward curried function types, it would
be useful to be able to section binary operators as in Haskell, e.g., "(1+)"
would mean "(function x -> 1 + x)".  Also, and perhaps more importantly, it
would be useful to be able to refer to methods independently of a particular
object.  For example, if "f" is a method of class "t", and "x" is a "t list",
I would like to be able to write

  List.map #f x

or perhaps even

  List.map f x

instead of

  List.map (function obj -> obj#f) x.

Either way, this lets you separate overloading somewhat from the OO paradigm,
potentially making it more useful, IMHO.

  And, at the risk of instigating a syntax war, I would prefer a more
Haskell-like syntax overall; for example, offside scoping, uppercase types so
there is no need for quotes in front of type variables, and user-definable
symbolic binary operators... <sigh> Then again, I guess there's no point in
turning O'Caml into an eager Haskell.  Anyway, I suppose there is a
philosophical reason why there are no user-defined symbolic identifiers in
Caml although SML allows them.

------------------------------------------------------------------------
Frank Christoph                 Next Solution Co.      Tel: 0424-98-1811
christo@nextsolution.co.jp                             Fax: 0424-98-1500

Re: Language improvements (?)

[Pierre Weis]

>   Third, since the trend in O'Caml is toward curried function types, it would
> be useful to be able to section binary operators as in Haskell, e.g., "(1+)"
> would mean "(function x -> 1 + x)".

Wao! Is this so useful ?

>   And, at the risk of instigating a syntax war, I would prefer a more
> Haskell-like syntax overall; for example, offside scoping,

By ``offside scoping'', you mean a ``where'' construct, I presume ?

> uppercase types so
> there is no need for quotes in front of type variables,

No, no, we already exhausted uppercase conventions with modules, constructors,
labels, and let bound identifiers. You may add one more convention to
get rid of the ' for type variables, but it cannot be as trivial as
just ``the first character is lower (resp. upper) case''. You need
something a bit more complex, for instance ``the LAST character must
be lower (resp. upper) case'' (with the side condition ``the
identifier must be at least 2 characters long''. I prefer to write
some ' here and there in my programs.

> and user-definable
> symbolic binary operators... <sigh> Then again, I guess there's no point in
> turning O'Caml into an eager Haskell.  Anyway, I suppose there is a
> philosophical reason why there are no user-defined symbolic identifiers in
> Caml although SML allows them.

I don't know exactly what you mean by a ``symbolic identifier'', if
you mean an identifier entirely made of characters that are not
letters or parens (e.g. ++ or <=> or >>), then Caml support it.
These identifier are infix operators, and their precedence is the same
as the precedence of the operator corresponding to the first character
(e.g. +* gets precedence of +).
For instance you may like to define your own << operator as in C:

        Objective Caml version 1.01

#let (<<) x y = x lsl y;;
val << : int -> int -> int = <fun>
#1 << 4;;
- : int = 16

Or with a more imperative point of view:

#let (+=) r x = r := !r + x;;
val += : int ref -> int -> unit = <fun>
#let r = ref 0 in r += 2; !r;;
- : int = 2

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis

Re: Language improvements (?)

[Frank Christoph]

> I don't know exactly what you mean by a ``symbolic identifier'', if
> you mean an identifier entirely made of characters that are not
> letters or parens (e.g. ++ or <=> or >>), then Caml support it.

  Sorry, I just noticed that myself after looking at the sources.  Maybe it
should be mentioned more prominently and under the same heading as identifiers
in the lexical conventions section of the manual.  It's sort of easy to miss
it as the last part of the last sentence under the "Prefix and infix symbols"
heading: "... but otherwise behave much as identifiers."  I also noticed that
you cannot use such identifiers as method names, which makes sense as the
language stands now, but if you were able to syntatically separate method
invocations from their objects (owners), infix or prefix methods would be
sensible.  (Granted, I don't know if that suggestion was workable or not.)

>> Third, since the trend in O'Caml is toward curried function types, it would
>> be useful to be able to section binary operators as in Haskell, e.g., "(1+)"
>> would mean "(function x -> 1 + x)".
>
> Wao! Is this so useful ?

  If you get in the habit of defining symbolic identifiers it is.  Judging
from how often I see people write "leq" instead of something like "(<==)" (not
"<=", to avoid the keyword), I guess this is not so common in the ML world.
Anyway, it's a trivial extension, and it allows you to curry symbolic
identifiers in the same way as conventional identifiers.

>>   And, at the risk of instigating a syntax war, I would prefer a more
>> Haskell-like syntax overall; for example, offside scoping,
>
>By ``offside scoping'', you mean a ``where'' construct, I presume ?

  No, although that would be nice too.  :) I mean an indentation convention
for lexical scoping.  For example, instead of

if x = y then (do_a; if x = z then do_b) else do_the_other_thing

write:

if x = y then	do_a;
		if x = z then do_b
	 else	do_the_other_thing

Here the lexical analyzer can determine that the else-clause belongs to the
first "if" because the position of the "else" is to the left of the second
"if" (off-side) and thus must belong to an outer scope.

  Most people will not be convinced by this example because dangling if's
don't occur that often in practice, esp. in a mostly-functional language, but
it also helps in nested match's and let's, etc.  This convention enforces a
certain style of formatting, it's true, but it's a good style, and very
readable.

  The two major problems with the convention are easy to fix.  First, it makes
it more difficult to generate programs automatically because scoping is more
subtle.  You can fix this by mandating that the convention is not in effect
between an explicit "begin" and an "end".  (This requires some small
adjustments to the syntax, I suppose, like changing "sig ... end" to "sig
begin ... end".)  The second problem is more or less a non-issue in Objective
Caml.  In Haskell, modules need to start with an explicit declaration "module
ModuleName where ..."  (oh, is this what you meant by "where"?) which would
mean that, if the entire file is one module, all subsequent lines would need
to be indented at least one space.  This can be fixed by adopting the
convention that the first line of a file is considered to have a "negative"
indentation, or something similar.  In O'Caml the compiler inserts the
module declaration for you, so it's not a problem.

  Most people indent their code anyway, so off-side scoping just helps to
eliminate syntax noise.  Also, it helps prevent mistakes (like forgetting to
delimit nested match's, as I said, which I have gotten caught in more than
once now).  The convention is easy to get used to, and, for me, it was so
successful in Haskell that I really miss it in O'Caml.

------------------------------------------------------------------------
Frank Christoph                 Next Solution Co.      Tel: 0424-98-1811
christo@nextsolution.co.jp                             Fax: 0424-98-1500

Language improvements (?)

[Georg Bauer]

Hi!

FC>I mean an indentation convention
FC>for lexical scoping.  For example, instead of

Hmm. Actually the Haskell indention conventions are the one thing that
always drives me crazy when I look at Haskell sources. No, I would prefer
to stay with the more standard way of writing source, as O'Caml does.
Actually my indention scheme is sometimes different from that implied by
Haskell. Ok, as I see it there is a possibility in Haskell to have explicit
scoping by using { } and such things (at least it's available in Gofer and
Hugs).

But I wouldn't say that there aren't any features in Haskell I would like
to have in O'Caml, too. Typeclasses for example would be nice - but it
wouldn't be trivial to redesign the whole type-system, so I have to stay
with the available tools.

bye, Georg

Re: Language improvements (?)

[Ian T Zimmerman]

In article <9607240953.AA00610@sparc3.nextsolution.co.jp>
christo@nextsolution.co.jp (Frank Christoph) writes:

>   No, although that would be nice too.  :) I mean an indentation
> convention for lexical scoping.  For example, instead of

> if x = y then (do_a; if x = z then do_b) else do_the_other_thing
> 
> write:
> 
> if x = y then	do_a;
> 		if x = z then do_b
> 	 else	do_the_other_thing
> 

> Here the lexical analyzer can determine that the else-clause belongs
> to the first "if" because the position of the "else" is to the left
> of the second "if" (off-side) and thus must belong to an outer
> scope.

Hmm, I sincerely hope the Caml team will _not_ follow this suggestion,
or at the very least leaves an escape in the form of a compiler switch
for those of us who dislike it.

It is a religious issue, and I see little point in repating the
arguments made many times before in comp.compilers, among other
places.  I recognize the points of the other side, but this would be a
fundamental change in how the language `looks and feels' and so I
think prudence should prevail and scoping by keywords should be
preserved.

-- 
                  +-------------------------------------------+
                  I When the dead are left to bury the dead,  I
                  I the living remain alone.  Arthur Koestler I
                  +-------------------------------------------+

Re: Language improvements (?)

[Michel Mauny]

> > Third, since the trend in O'Caml is toward curried function types,
> > it would be useful to be able to section binary operators as in
> > Haskell, e.g., "(1+)" would mean "(function x -> 1 + x)".

Your example works in ocaml: (+) 1 denotes the function above. But,
the only way to partially apply (+) to its second argument is to give
a name to the first one as in (fun x -> x+2).

Personnally, I don't think sections are really useful.

> >   And, at the risk of instigating a syntax war, I would prefer a more
> > Haskell-like syntax overall; for example, offside scoping,

I don't like it either. (And it would be a really pain to implement it
with Yacc, I think -- if ever possible.)

> > [Type constructors with] uppercase types so
> > there is no need for quotes in front of type variables,

> No, no, we already exhausted uppercase conventions with modules,
> constructors, labels, and let bound identifiers.

Here, I disagree with Pierre: it would be possible because type
constructors occur only in very specific contexts. The parser just has
to consider that a type constructor (putting aside the arrow) is a
(possibly empty) module access path preceeding an uppercase
identifier, that is the type name. There is no conflict with the other
usage of uppercase idents (data constructors) because they occur in
different contexts.

However, writing type expressions as in Haskell is probably just a
cosmetic issue.

-- 
Michel

Re: Language improvements (?)

[Pierre Weis]

Date: Thu, 25 Jul 1996 20:14:18 +0900
From: christo@nextsolution.co.jp (Frank Christoph)
Message-Id: <9607251114.AA00849@sparc3.nextsolution.co.jp>
To: caml-list@pauillac.inria.fr
In-Reply-To: <199607250212.TAA04865@kronstadt.rahul.net> (message from Ian T Zimmerman on Wed, 24 Jul 1996 19:12:38 -0700)
Subject: Re: Language improvements (?)

[ Mode'rator's Note:

   Hi,

   Please note that from today to August the 26th, no messages from
   the Caml mailing list will be sent (vacations).

   Sorry for the inconvenience,

   Pierre Weis
]

>>>>> "Ian" == Ian T Zimmerman <itz@rahul.net> writes:

> Hmm, I sincerely hope the Caml team will _not_ follow this suggestion, or at
> the very least leaves an escape in the form of a compiler switch for those
> of us who dislike it.

> It is a religious issue, and I see little point in repating the arguments
> made many times before in comp.compilers, among other places.  I recognize
> the points of the other side, but this would be a fundamental change in how
> the language `looks and feels' and so I think prudence should prevail and
> scoping by keywords should be preserved.

  I agree 100%.  It's far too late for such a fundamental change; implementing
it in O'Caml would be rash and injudicious, and would probably take it
completely out of the realm of ML itself.

  So, uh, let's change the name of the language.  Yeah, that's it. How about,
oh, I dunno, "The-Language-Formerly-Known-As-Objective ML"?  :)

  No, seriously though, I don't expect such a drastic change at this point.  I
was just, shall we say, daydreaming?  Besides, I have a hundred *other*
syntactical improvements to suggest.  Now where was that list ... ?

  OK, OK -- I can see everyone starting to moan already.

  But I do have one humble little question concerning syntax and conventional
practice in the Caml world.  O'Caml seems to lack a succinct way of defining
functions that pattern-match multiple arguments.  For example, suppose I
wanted to define a function to exclusive-OR the integers 1 and 0 without using
the wildcard "_".  In Haskell, I could write

xor 1 1 = 0
xor 0 1 = 1
xor 1 0 = 1
xor 0 0 = 0

and apparently in SML it is possible to write

fun xor 1 1 = 0
  | xor 0 1 = 1
  | xor 1 0 = 1
  | xor 0 0 = 0

but, as far as I can tell, there is no simple way to do this in O'Caml.  If I
write

let xor 1 1 = 0
and xor 1 0 = 1
and xor 0 1 = 1
and xor 0 0 = 0

I get a duplicate binding error.  If I try

let xor = fun ...

or

let xor = function ...

then I need to nest pattern-matching constructs.

  Is there a pattern-matching construct like the Haskell and SML examples I
gave in O'Caml?  (Did I miss it?)  Or is there some reason why it has been
left out?

  I know that compiling pattern-matches perfectly isn't possible because it
requires parallel evaluation of arguments.  Is this why there is no such
construct, to force users to choose an evaluation order?  But then, "fun x y
..." is parallel.  (Granted, there is an O'Caml convention for its
evaluation.)

------------------------------------------------------------------------
Frank Christoph                 Next Solution Co.      Tel: 0424-98-1811
christo@nextsolution.co.jp                             Fax: 0424-98-1500