[Caml-list] CamlP4 Revised syntax comment

[Caml-list] CamlP4 Revised syntax comment

[brogoff]

Skip this thread if syntax discussions don't interest you. 

    I was wondering what Revised users think about replacing comparison = with 
==, as in Haskell, and giving phys ref equality some other name? 

    Why? Well, = is overloaded in OCaml/Revised for both binding and  
comparison, and this change removes that overloading and uses a 
fairly common (C, Haskell, Clean,...) symbol == for equality. Physical 
reference equality should be used rather sparingly anyways so it is better 
perhaps that it not even be infix. 

    Besides the extra keystroke, I couldn't think of good reasons why not. 
Backwards compatibility is not much argument against changes in Revised 
syntax. 

    Another possible change along the same lines is having =/= or /= for 
inequality, which happens to look a little more like the mathematical 
symbol. 

-- 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] CamlP4 Revised syntax comment

[Oleg]

On Friday 25 October 2002 03:02 pm, brogoff@speakeasy.net wrote:
> Well, = is overloaded in OCaml/Revised for both binding and  
> comparison, and this change removes that overloading

And maybe then 'value a = b;' can be written as 'a = b;' ? 

Oleg
-------------------
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] CamlP4 Revised syntax comment

[Stefano Zacchiroli]

On Fri, Oct 25, 2002 at 12:02:47PM -0700, brogoff@speakeasy.net wrote:
> comparison, and this change removes that overloading and uses a 
> fairly common (C, Haskell, Clean,...) symbol == for equality.

It's an idea that is worth considering. It fits well with the consistent
use of the other C like operators as "||" and "&&" and the disposal of
"or".

> Physical reference equality should be used rather sparingly anyways so
> it is better perhaps that it not even be infix. 

I've seen somewhere the operator "===" for physical equality, infix
obviously. It's not really diffused but seems to me that is really
intuitive.

>     Another possible change along the same lines is having =/= or /= for 
> inequality, which happens to look a little more like the mathematical 
> symbol. 

Uhm ... I disagree here, changing an operator in favour of a more
diffused one is comfortable, adopting a new one from scratch just
because it look more like the mathematical symbol can be really
confusing ...

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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] CamlP4 Revised syntax comment

[Daniel de Rauglaudre]

Hi,

On Sat, Oct 26, 2002 at 11:27:37AM +0200, Stefano Zacchiroli wrote:

> > comparison, and this change removes that overloading and uses a 
> > fairly common (C, Haskell, Clean,...) symbol == for equality.
> It's an idea that is worth considering. It fits well with the consistent
> use of the other C like operators as "||" and "&&" and the disposal of
> "or".

This is a good idea, indeed, but I have two remarks:

- first, this is more a question of library than syntax; Camlp4 can do
  that, but it is a not really clean. Well, actually, it does it for the
  record label "contents" which is renamed "val" in the revised syntax
  (to be shorter).

- second, it is a semantic change, and if programs using the revised
  syntax used the physical equality ==, this change would change their
  code into normal equality.

Therefore, IMHO, this could be included only if there are several
other changes, a set of several changes being more acceptable.

> >     Another possible change along the same lines is having =/= or /= for 
> > inequality, which happens to look a little more like the mathematical 
> > symbol. 
> Uhm ... I disagree here, changing an operator in favour of a more
> diffused one is comfortable, adopting a new one from scratch just
> because it look more like the mathematical symbol can be really
> confusing ...

I agree with you, for the same reasons.

-- 
Daniel de RAUGLAUDRE
http://cristal.inria.fr/~ddr/
-------------------
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] CamlP4 Revised syntax comment

[David Brown]

On Sat, Oct 26, 2002 at 11:27:37AM +0200, Stefano Zacchiroli wrote:

> >     Another possible change along the same lines is having =/= or /= for 
> > inequality, which happens to look a little more like the mathematical 
> > symbol. 
> 
> Uhm ... I disagree here, changing an operator in favour of a more
> diffused one is comfortable, adopting a new one from scratch just
> because it look more like the mathematical symbol can be really
> confusing ...

It isn't completely from scratch.  Ada uses /= for inequality.  They
probably had the same motivation, to make it look like the mathematic
symbol.

Dave Brown
-------------------
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] CamlP4 Revised syntax comment

[brogoff]

I was thinking of Ada with /=, but I agree with others that this isn't that 
important. You could make the argument that <> is better than /= since it is 
symmetric. I'm not fond of != in classic OCaml for that reason and since 
the ! usually makes me think of dereferencing. 

Anyways, the "=" change is really the one I care about. 

I'll have to check my Ada 83 Rationale to see why Ichbiah and the Green 
Team chose /= instead of <>, since Ada is based on Pascal. There's a 
similar syntactic quirkiness about Ada as in OCaml, where constants 
are given values with ":=" instead of "is". IMO, of course ;-)

-- Brian

On Sat, 26 Oct 2002, David Brown wrote:

> On Sat, Oct 26, 2002 at 11:27:37AM +0200, Stefano Zacchiroli wrote:
> 
> > >     Another possible change along the same lines is having =/= or /= for 
> > > inequality, which happens to look a little more like the mathematical 
> > > symbol. 
> > 
> > Uhm ... I disagree here, changing an operator in favour of a more
> > diffused one is comfortable, adopting a new one from scratch just
> > because it look more like the mathematical symbol can be really
> > confusing ...
> 
> It isn't completely from scratch.  Ada uses /= for inequality.  They
> probably had the same motivation, to make it look like the mathematic
> symbol.
> 
> Dave Brown
> -------------------
> 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] CamlP4 Revised syntax comment

[Kontra, Gergely]

>It's an idea that is worth considering. It fits well with the consistent
>use of the other C like operators as "||" and "&&" and the disposal of
>"or".

>> Physical reference equality should be used rather sparingly anyways so
>> it is better perhaps that it not even be infix. 
>
>I've seen somewhere the operator "===" for physical equality, infix
>obviously. It's not really diffused but seems to me that is really
>intuitive.
I guess it was ruby.
If we are at changes:
I really dislikes the do { } notation.
My suggestion is to use do end pairs, which is borrowed also from ruby.
And if we want more ruby-ish (ada-like?), the matching can be
match a with
| 0 ->
| n ->
end

And end is already a keyword, so it doesn't pollute the namespace, and
the square bracket will remain to the lists.

BTW who cares about the keywords used by the language? Rather to use one
more keyword, than to use weird syntax...

((( this one is not so important
If we are at lists, the current syntax is between sml and prolog:
1) sml uses head::tail, so the :: operator is common
2) prolog uses [Head|Tail], so requiring bracket is common

So, "closing more structures" idea is closer to the prolog syntax, one
could use it, ok, | is used in other contexts, so it couldn't be a too
good idea.
)))

I think this many changes is enough to release a new version with == and
=== included :-)

Gergo
+-[Kontra, Gergely @ Budapest University of Technology and Economics]-+
|         Email: kgergely@mcl.hu,  kgergely@turul.eet.bme.hu          |
|  URL:   turul.eet.bme.hu/~kgergely    Mobile: (+36 20) 356 9656     |
+-------"Olyan langesz vagyok, hogy poroltoval kellene jarnom!"-------+
.
Magyar php mirror es magyar php dokumentacio: http://hu.php.net

-------------------
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] CamlP4 Revised syntax comment

[Oleg]

On Monday 28 October 2002 03:38 am, Kontra, Gergely wrote:

> I think this many changes is enough to release a new version with == and
> === included :-)

I think "===" is too much. And where is this going to stop? "========" a 
couple of revisions later? Think of the poor dyslexic children forced to take 
O'Caml in some French schools! ;-)

Oleg
-------------------
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] CamlP4 Revised syntax comment

[Florian Douetteau]

I propose that the number of occurence
of the '=' symbol encodes the max depth
of the recursive walk, when > 3.

For instance (=============) would return
true on lists which first 13 elements are equals
(with depth 12, of course)

:)


> On Monday 28 October 2002 03:38 am, Kontra, Gergely wrote:
>
> > I think this many changes is enough to release a new version with == and
> > === included :-)
>
> I think "===" is too much. And where is this going to stop? "========" a
> couple of revisions later? Think of the poor dyslexic children forced to take
> O'Caml in some French schools! ;-)
>
> Oleg
> -------------------
> 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] CamlP4 Revised syntax comment

[Stefano Zacchiroli]

On Mon, Oct 28, 2002 at 05:28:32AM -0400, Oleg wrote:
> I think "===" is too much. And where is this going to stop? "========" a 

You have to find (String.length("========") - 1) different equalities
before ...

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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] CamlP4 Revised syntax comment

[Daniel de Rauglaudre]

Hi,

On Mon, Oct 28, 2002 at 09:38:04AM +0100, Kontra, Gergely wrote:

> I really dislikes the do { } notation.
> My suggestion is to use do end pairs, which is borrowed also from ruby.
> And if we want more ruby-ish (ada-like?), the matching can be
> match a with
> | 0 ->
> | n ->
> end

I like the way Ada ends its statements. However, as said in the
chapter about the revised syntax (tutorial), we took the option not to
end the statements with a keywork ("end", or "fi" or things like
that), in order to show that all of that is functionnal.

When you see:
      if e1 then e2 else e3 end

you don't have the impression that e2 or e3 are *results*: the "end"
gives you the impression that everything is terminated. Often, newbies
don't understand the functional way this statement must be read. If we
change the syntax with this "end", it is going to be more difficult to
explain then.

This way, I regret a little bit the "do { }" of the "for" loop. A
"do .. done" would have been more logical (same for "while").

-- 
Daniel de RAUGLAUDRE
http://cristal.inria.fr/~ddr/
-------------------
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] CamlP4 Revised syntax comment

[brogoff]

On Mon, 28 Oct 2002, Daniel de Rauglaudre wrote:
> I like the way Ada ends its statements. However, as said in the
> chapter about the revised syntax (tutorial), we took the option not to
> end the statements with a keywork ("end", or "fi" or things like
> that), in order to show that all of that is functionnal.

I mostly like Ada syntax too. It could use a few more characters, like [] 
for arrays and Pascalish ^ for access types; blame the Steelman requirements 
doc, not Jean Ichbiah, for this! 

As you point out though, Ada is far from functional so I don't agree that it 
should be a model for an MLish syntax. 

> When you see:
>       if e1 then e2 else e3 end
> 
> you don't have the impression that e2 or e3 are *results*: the "end"
> gives you the impression that everything is terminated. Often, newbies
> don't understand the functional way this statement must be read. If we
> change the syntax with this "end", it is going to be more difficult to
> explain then.
> 
> This way, I regret a little bit the "do { }" of the "for" loop. A
> "do .. done" would have been more logical (same for "while").

I like having the sequencing syntax being the same with or without the loop, 
but I certainly understand that there is a valid argument for seeing them 
differently, since in a non-looping sequence you typically return the value of 
the last expression. 

I thought that do { } was a compromise, since some users just wanted {} or () 
to be the non-optional bracketing for sequences. I remember some of that 
discussion, and I certainly wouldn't mind that solution, or the creation of 
special non-alphabetic brackets for imperative constructs. I'm not fond of 
do .. done myself. 

-- 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] CamlP4 Revised syntax comment

[Alexander V.Voinov]

Hi All,

From: "Kontra, Gergely" <kgergely@mlabdial.hit.bme.hu>
Subject: Re: [Caml-list] CamlP4 Revised syntax comment
Date: Mon, 28 Oct 2002 09:38:04 +0100 (CET)

> I really dislikes the do { } notation.
> My suggestion is to use do end pairs, which is borrowed also from ruby.
> And if we want more ruby-ish (ada-like?), the matching can be
> match a with
> | 0 ->
> | n ->
> end

I second this.

Alexander
-------------------
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] CamlP4 Revised syntax comment

[Pierre Weis]

>     I was wondering what Revised users think about replacing comparison = with 
> ==, as in Haskell, and giving phys ref equality some other name? 
> 
>     Why? Well, = is overloaded in OCaml/Revised for both binding and  
> comparison, and this change removes that overloading and uses a 
> fairly common (C, Haskell, Clean,...) symbol == for equality. Physical 
> reference equality should be used rather sparingly anyways so it is better 
> perhaps that it not even be infix. 
> 
>     Besides the extra keystroke, I couldn't think of good reasons why not. 
> Backwards compatibility is not much argument against changes in Revised 
> syntax. 
> 
>     Another possible change along the same lines is having =/= or /= for 
> inequality, which happens to look a little more like the mathematical 
> symbol. 
> 
> -- Brian

To remove overloading of = (predicate and definition symbol), we could
choose to write
  let pat be expression
instead of
  let pat = expression
(And seemingly fro other constructs: type foo is int * int.)

Let's go back to the operators per se.

The choice for operators = and == in Caml was not random, but based on
the semantics: the == operator in C implements physical equality
(hence the need for the strcmp predicate in C); hence, we chose the
same symbol in Caml to denote physical equality.

On the other hand, the = symbol is vastly known as a predicate for
equality that performs a semantic equality rather than a physical
equality (as does the = symbol in maths); hence the natural choice of
= to denote structural equality.

The opposite predicates names were chosen accordingly:
 from C: the negation of == is !=
 from Pascal: the negation of = is <>

You can argue that we do not need those 2 predicates, since you may
think that one ``subsumes'' the other (or is ``more powerful'' than
the other) but sorry, this is not true: we need both predicates to
express both semantics. (Look at the FAQ for a deeper discussion on
equality.)

You can argue that we do need a third predicate to express even deeper
semantic equality that = can check (say, for instance, equality as
graph equivalence of data), as in the comparison of co-inductive data
structures.

To illustrate this situation let's define two ``infinite'' lists of 1s:
let rec x = 1 :: x;;
val x : int list =
  [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
   1; 1; 1; ...]

let rec y = 1 :: y;;
val y : int list =
  [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
   1; 1; 1; ...]

Now, physical equality testing correctly returns false:

# x == y;;
- : bool = false

But structural equality just loops for ever trying to check the
equality of those seemingly infinite lists:

# x = y;;
Quit

We thus may need a deeper equality to test graph equivalence! (You can
argue that = could behave like that, but this is not easy to implement
efficiently.)

Since this new predicate is inherently costy (we need to keep track of
all already visited nodes), a longer name reminiscent of its equality
semantics could be ``===''.

Hence, we would have:

= is the casual equality
== is the physical equality
=== is the graph equivalence test

Best regards,

Pierre Weis

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


-------------------
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] CamlP4 Revised syntax comment

[brogoff]

On Tue, 29 Oct 2002, Pierre Weis wrote:
> To remove overloading of = (predicate and definition symbol), we could
> choose to write
>   let pat be expression
> instead of
>   let pat = expression
> (And seemingly fro other constructs: type foo is int * int.)

Right, that makes a lot of sense, even though it may be preferable to depart 
slightly from English grammar and just use "is" for both to save a keyword. 

Another place where classic OCaml could be a bit wordier is in the declaration 
of multiparameter data constructors; in Revised the cases of "constructor 
with a tupled parameter" and "constructor with several parameters" are more 
clearly distinguished than in OCaml, and in OCaml this is a gotcha since the 
implementation is different. 

> Let's go back to the operators per se.
> 
> The choice for operators = and == in Caml was not random, but based on
> the semantics: the == operator in C implements physical equality
> (hence the need for the strcmp predicate in C); hence, we chose the
> same symbol in Caml to denote physical equality.

Thanks to OCaml, I've forgotten a lot of C ;-), but is this really true? 
The way I understood it, == is just value equality, but it doesn't work 
with structures on account of alignment and packing issues which would make it 
too costly. Since strings and arrays are nothing more than pointers in C, 
== on strings or arrays is just value comparison of pointers. In the latest 
C, which has complex numbers, I'm pretty sure equality is structural, since 
complex numbers get their real and complex parts checked. 

> You can argue that we do need a third predicate to express even deeper
> semantic equality that = can check (say, for instance, equality as
> graph equivalence of data), as in the comparison of co-inductive data
> structures.
> 
> To illustrate this situation let's define two ``infinite'' lists of 1s:
> let rec x = 1 :: x;;
> val x : int list =
>   [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
>    1; 1; 1; ...]
> 
> let rec y = 1 :: y;;
> val y : int list =
>   [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
>    1; 1; 1; ...]
> 
> Now, physical equality testing correctly returns false:
> 
> # x == y;;
> - : bool = false
> 
> But structural equality just loops for ever trying to check the
> equality of those seemingly infinite lists:
> 
> # x = y;;
> Quit
> 
> We thus may need a deeper equality to test graph equivalence! (You can
> argue that = could behave like that, but this is not easy to implement
> efficiently.)
> 
> Since this new predicate is inherently costy (we need to keep track of
> all already visited nodes), a longer name reminiscent of its equality
> semantics could be ``===''.

I hadn't thought of that, and I'm not even sure if you're just pulling my leg, 
but it's a good argument anyways. Is this an abstract point, or has anyone 
really needed a graph equivalence test over recursively defiend values in 
practice? 

-- 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] CamlP4 Revised syntax comment

[Alessandro Baretta]

brogoff@speakeasy.net wrote:
> On Tue, 29 Oct 2002, Pierre Weis wrote:

>>We thus may need a deeper equality to test graph equivalence! (You can
>>argue that = could behave like that, but this is not easy to implement
>>efficiently.)
>>
>>Since this new predicate is inherently costy (we need to keep track of
>>all already visited nodes), a longer name reminiscent of its equality
>>semantics could be ``===''.
> 
> 
> I hadn't thought of that, and I'm not even sure if you're just pulling my leg, 
> but it's a good argument anyways. Is this an abstract point, or has anyone 
> really needed a graph equivalence test over recursively defiend values in 
> practice? 
> 
> -- Brian

I have a case where I actually need to test for structural 
equality over cyclic data structures--essentially top-down 
trees, with an upward link from nodes to their parents. 
These structures are necessary whenever the tree traversal 
starting point can be any node in the structure. This 
happens, for example, when you import a relational database 
and model foreign key fields with actual references between 
records.

Of course, it is fairly easy to devise a specific equality 
test for such cases, but, in general, one such equality 
function is needed for every datatype appearing in the 
graph. This can get painful if the number of different 
datatypes (tables) gets large. In such cases a "graph 
equivalence" operator would be a useful bonus. Still, I 
don't think this is a major issue with O'Caml.

Alex

-------------------
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] CamlP4 Revised syntax comment

[Gérard Huet]

Le lundi 28 octobre 2002, à 05:56 PM, Alexander V.Voinov a écrit :

> Hi All,
>
> From: "Kontra, Gergely" <kgergely@mlabdial.hit.bme.hu>
> Subject: Re: [Caml-list] CamlP4 Revised syntax comment
> Date: Mon, 28 Oct 2002 09:38:04 +0100 (CET)
>
>> I really dislikes the do { } notation.
>> My suggestion is to use do end pairs, which is borrowed also from ruby.
>> And if we want more ruby-ish (ada-like?), the matching can be
>> match a with
>> | 0 ->
>> | n ->
>> end
>
> I second this.
>
> Alexander
>

Frankly,
I do not think that design of a programming language (or any reasonably 
complex
scientific activity) can be seriously accomplished by exchanges through a
large mailing list using random criteria of taste and distaste. In other 
words,
there is no "motion" to second, we have no tradition of design by voting.

The revised syntax of Ocaml is certainly not the final satisfactory 
solution, but it is a well thought out experiment in improving the 
syntax of Ocaml along orthogonal principles. Its community may not be as 
large as the wider community using the standard syntax, but it is a 
community of users who appreciate stability,
upward compatibility, and principled discussion.

I personally believe that syntax, and notation in general, is important. 
Important
for guiding intuition consistently with the semantics, important for 
teaching the
language, important for avoiding mistakes such as case capture because 
of poor
bracketing. So it deserves a serious argumentation. Furthermore, it is 
not just
a matter of concrete syntax, it is also a matter of consistent tools for 
the edition and maintenance of programs in a spirit of literate 
programming.

Gérard Huet

-------------------
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] CamlP4 Revised syntax comment

[Alexander V.Voinov]

Hi 

From: Gérard Huet <Gerard.Huet@inria.fr>
Subject: Re: [Caml-list] CamlP4 Revised syntax comment
Date: Tue, 29 Oct 2002 19:15:02 +0100

> >> match a with
> >> | 0 ->
> >> | n ->
> >> end
> >
> > I second this.
> >
> > Alexander
> >
> 
> Frankly,
> I do not think that design of a programming language (or any reasonably 
> complex
> scientific activity) can be seriously accomplished by exchanges through a
> large mailing list using random criteria of taste and distaste. 

I agree completely. Here I only meant that a closing 'parenthesis' for
the match construction is desired. I don't use revised syntax and don't know it,
but in the standard syntax you have to use parentheses over the entire 'match...'
to resolve ambiguity.

Of course a masterpiece cannot be created by a referendum. :-)

> I personally believe that syntax, and notation in general, is important. 

Me too. BTW quite recently I made a presentation on FP in my company,
and one slide just showed two equivalent programs in Python and OCaml
side by side. This slide was crucial in the overall receiption of the
presentation.  My colleagues got a feeling that FP is not _that_ weird
(as one would infer from the previous slides ;-) after all. (Here in
biotech we use Python very intensively.)

> Important
> for guiding intuition consistently with the semantics, 

Especially when you promote the language among skillful users of some
other language be it C or Ada or Python.

WBR

Alexander
-------------------
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] CamlP4 Revised syntax comment

[Damien Doligez]

>>>> match a with
>>>> | 0 ->
>>>> | n ->
>>>> end

> but in the standard syntax you have to use parentheses over the entire 
> 'match...'
> to resolve ambiguity.

I find the following solution quite satisfactory, if a bit verbose:

   begin match a with
   | 0 -> ...
   | n -> ...
   end

-- Damien

-------------------
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] CamlP4 Revised syntax comment

[M E Leypold @ labnet]

Damien Doligez writes:

 >    begin match a with
 >    | 0 -> ...
 >    | n -> ...
 >    end


While we are at it, why don't we have something like:

   ok, man, we will be doing a match now.
   lets start matching:
   now, match the expression a against the following patterns

     first pattern is the  pattern 0, if that applies do ...
     else if not try the   pattern n, if that applies do ...
     ...

     ok, that were all the patterns
   and we are done matching now.

Sometimes a short notation has some merits. :-) Not to be understood
wrongly: I like the idea to experiment with different syntax. I like
CamplP4. But I prefer to use the 'old' syntax (doesn't force me to
write opening and closing stuff all the time, I can pretty well
understand my own code without all that). I like the idea of a
completedly different syntax (or even a Ada or Pascal like language,
which maps to OCaml at the backend) though.

Some contributors in this discussion seem to be driven by the idea, to
make the programming language 

  (a) either more similar to spoken English:

         Like: let a be expr1 in expr2

  (b) more understandable to the computer

         Like: while expr do { ... }

      (the idea is to have more syntactic elements, to make the block
      structure explicit)

I think there is merit on both efforts (really ambigous syntax is a
pain even for humans and too cryptic code -- like obfuscated C is also
a pain), but to tell the truth, I prefer to make things harder for the
computer and easier for me. And I think

     let a = expr1 in expr2

is simpler to read, it resembles common mathematical notation better.

I'm not really sure, wether I should take this discussion serious
... It's not even really about syntax, but replacement of single
keywords. I'll just wait for the day, when someone of the
radically-new-syntax school actually presents a working implementation
and shows some medium to large program written in it. I think this is
a good plan :-).


-------------------
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] CamlP4 Revised syntax comment

[brogoff]

I agree with Gerard's comments about using the list as a ballot box 
for Revised changes, as well as his other comments. I dismissed backward 
compatibility issues as a negative in my proposal about "=", and that was 
probably too strong. It would have been better if I'd said that this 
constraint is weaker than in classic OCaml. No doubt the constraints about 
syntax changes in classic OCaml are weaker than in an ANSI or ISO standard, 
or even a standard like SML. 

There does need to be a way for Revised users to discuss aspects of the syntax 
in order that the designer (Daniel) gets some feedback. It would be more 
fruitful if contributors could provide reasons for why they favor a particular 
syntactic choice, and if they can list the negatives. One thing that always 
impressed me about some of the Ada designers was that they were quite adept 
at arguing convincingly against their own pet proposals.

I particularly like Daniel's efforts at providing justification for his 
decisions in the tutorial. One thing that's still missing is a "theory of 
what makes a good syntax for a programming language". I think it's obvious 
that such a theory would have to account for the fact that a good shell 
syntax isn't a good syntax for a more general purpose language (there 
are many more categories than just these two!) and that such a theory would 
be largely heuristic, with incompatible rules, like the principles of good 
chess play, but still useful.

-- 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] CamlP4 Revised syntax comment

[Daniel de Rauglaudre]

Hi,

On Wed, Oct 30, 2002 at 12:49:48PM -0500, Arturo Borquez wrote:
> 
> I prefer the revised syntax despite extra verbosity because
> it overcomes some confusing situations of the official syntax.
> (if with or without else, { and begin, } and end, the match
> function ... among others).

It is exactly my position: more verbosity is a drawback, but the fact
that there is sometimes necessary in normal syntax to enclose statements
with parentheses is a bad property.

An example of that is the pretty print.

The pretty print in normal syntax is a difficulty, because of these
pending "else" and pending "vertical bar": we have sometimes to
enclose "if" and "match" statements with parentheses, sometimes not.

A solution could be to always print with parentheses, but the result
is ugly.

I found another solution by calling the pretty printing functions with
an extra parameter telling "what is printed after", and when I print a
"match" statement, if that parameter is "|", it means that this match
must be enclosed with parentheses "(..)" or "begin..end".

-- 
Daniel de RAUGLAUDRE
http://cristal.inria.fr/~ddr/
-------------------
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] CamlP4 Revised syntax comment

[Arturo Borquez]

Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> wrote:

>Hi,
>
>On Mon, Oct 28, 2002 at 09:38:04AM +0100, Kontra, Gergely wrote:
>
>> I really dislikes the do { } notation.
>> My suggestion is to use do end pairs, which is borrowed also from ruby.
>> And if we want more ruby-ish (ada-like?), the matching can be
>> match a with
>> | 0 ->
>> | n ->
>> end
>
>I like the way Ada ends its statements. However, as said in the
>chapter about the revised syntax (tutorial), we took the option not to
>end the statements with a keywork ("end", or "fi" or things like
>that), in order to show that all of that is functionnal.
>
>When you see:
>      if e1 then e2 else e3 end
>
>you don't have the impression that e2 or e3 are *results*: the "end"
>gives you the impression that everything is terminated. Often, newbies
>don't understand the functional way this statement must be read. If we
>change the syntax with this "end", it is going to be more difficult to
>explain then.
>
>This way, I regret a little bit the "do { }" of the "for" loop. A
>"do .. done" would have been more logical (same for "while").
>
>-- 
>Daniel de RAUGLAUDRE

I like and seems me a good compromise actual revised syntax,
also do { ... } is a good (and visible warning) that may be
side effects to care. No way to if ... else ... end as you
said it isn't FP (it is pure impertative style).
I prefer the revised syntax despite extra verbosity because
it overcomes some confusing situations of the official syntax.
(if with or without else, { and begin, } and end, the match
function ... among others).

Best regards. 

-- 
Arturo Borquez


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
-------------------
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