[Caml-list] petty complaints

[Caml-list] petty complaints

[Brian Rogoff]

Hi,
    In response to the recent query about string libraries I took my own
advice and ported the Mosml substring library to OCaml. This exercise
raised a question which I've had before but never seen asked or answered, 
namely, why doesn't OCaml use something like SML's order datatype
GREATER | EQUAL | LESS for comparison rather than an integer? It seems
against the spirit of static typing. What's the rationale? Efficiency? 
Hysterical raisins? 

    Another unrelated trifling question concerns the syntax of numerical 
literals. Would it be possible to allow a la Ada the insertion of _s in 
a numerical literal so instead of 1000000,10000000,and 100000000 we could 
write 1_000_000, 10_000_000, 100_000_000? Of course, as in Ada, you could 
allow wrongly positioned or superfluous _s (1_00_00_______0) but I think 
this trivial change can make reading numbers a bit nicer. 

-- Brian
       

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Xavier Leroy]

>     In response to the recent query about string libraries I took my own
> advice and ported the Mosml substring library to OCaml. This exercise
> raised a question which I've had before but never seen asked or answered, 
> namely, why doesn't OCaml use something like SML's order datatype
> GREATER | EQUAL | LESS for comparison rather than an integer? It seems
> against the spirit of static typing. What's the rationale? Efficiency? 
> Hysterical raisins? 

Mostly hysterical :-)  A long time ago, I thought that 
                fun x y -> x - y
was a suitable comparison function for integers.  Of course, it's not
because of overflow in subtraction, and one really needs to pay the
price for two comparisons.  So, from an efficiency standpoint,
there would really be no difference between the current OCaml approach
and the SML "order" datatype.

>     Another unrelated trifling question concerns the syntax of numerical 
> literals. Would it be possible to allow a la Ada the insertion of _s in 
> a numerical literal so instead of 1000000,10000000,and 100000000 we could 
> write 1_000_000, 10_000_000, 100_000_000? Of course, as in Ada, you could 
> allow wrongly positioned or superfluous _s (1_00_00_______0) but I think 
> this trivial change can make reading numbers a bit nicer. 

That's amusing, I didn't know about this feature of Ada.  For
integers, this would be trivial to implement; a bit more work for
floats, because we rely on the C library atof() function, which
doesn't know about the underscores.  What do other think?

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Brian Rogoff]

On Mon, 2 Apr 2001, Xavier Leroy wrote:
> >     Another unrelated trifling question concerns the syntax of numerical 
> > literals. Would it be possible to allow a la Ada the insertion of _s in 
> > a numerical literal so instead of 1000000,10000000,and 100000000 we could 
> > write 1_000_000, 10_000_000, 100_000_000? Of course, as in Ada, you could 
> > allow wrongly positioned or superfluous _s (1_00_00_______0) but I think 
> > this trivial change can make reading numbers a bit nicer. 

Arrghhh, the Ada syntax allows arbitrary placement but no additional _s,
let this serve as an example to those who don't go right for the formal
syntax :-(. Here's the relevant part

based_numeral ::=
        extended_digit {[underline] extended_digit}

extended_digit ::= digit | A | B | C | D | E | F

I was reminded of this feature of Ada when I was hacking some (OCaml, not
Ada!) config files and I had to look carefully at a params to make sure I
got the number of zeroes right. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Brian Rogoff]

On Mon, 2 Apr 2001, Chris Hecker wrote:
> Perl allows the same thing for ints and floats.  Not sure if that's an
> argument for or against.  :)

Thanks, it is Perl that allows multiple adjacent underlines in a numeric
literal. I was wondering why I had thought that Ada allowed that. While
I've never felt the desire to use underlines as anything other than comma 
replacements in a numeric literal, if this were going to be added to OCaml
I see no reason not to go with the Perl approach. 

Perl is certainly ugly, and even worse the Perlers stole our mascot. 
However, that shouldn't prejudice us against this feature. Even a broken
clock is right twice a day. :-)

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Chris Hecker]

>That's amusing, I didn't know about this feature of Ada.

Perl allows the same thing for ints and floats.  Not sure if that's an argument for or against.  :)

http://www.perl.com/pub/doc/manual/html/pod/perldata.html#Scalar_value_constructors

Chris

PS.  I'd like to take this opportunity to thank whoever is responsible for having the 0b syntax for ints in OCaml!  I'd also like to suggest that printf be modified to output a binary format int...except %b is taken, but apparently %B is not...

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[John Max Skaller]

Brian Rogoff wrote:

>     Another unrelated trifling question concerns the syntax of numerical
> literals. Would it be possible to allow a la Ada the insertion of _s in
> a numerical literal so instead of 1000000,10000000,and 100000000 we could
> write 1_000_000, 10_000_000, 100_000_000? Of course, as in Ada, you could
> allow wrongly positioned or superfluous _s (1_00_00_______0) but I think
> this trivial change can make reading numbers a bit nicer.

	I use the following lexer rules: note that the special
handling of 0 prefixed decimal numbers is to allow warnings
to be given for C heads that think 077 is octal :-)

(* integers *)
let bin_lit  = '0' ('b' | 'B') (underscore? bindigit) +
let oct_lit  = '0' ('o' | 'O') (underscore? octdigit) +
let dec_lit  = '0' ('d' | 'D') (underscore? digit) +
let nz_dec_lit  = nzdigit (underscore? digit) *
let z_dec_lit  = '0' (underscore? digit) *
let hex_lit  = '0' ('x' | 'X') (underscore? hexdigit)  +

(* floats *)
let decimal_string = digit (underscore? digit) *
let fixed_literal = decimal_string ? '.' decimal_string | 
  decimal_string '.' decimal_string?
let exponent = 'E' ('+'|'-')? decimal_string
let floating_literal = fixed_literal exponent? | decimal_string exponent

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Christian Lindig]

On Sun, Apr 01, 2001 at 09:26:59PM -0700, Brian Rogoff wrote:
>     Another unrelated trifling question concerns the syntax of numerical 
> literals. 

Now that the spring cleaning for OCaml's syntax (floats, labels,
constructors) is in full swing, here is my wish:  Haskell allows to
use any identifier as a binary operator when it is placed in
backquotes:  x `plus` y.  These operators are often more readable than
the classic infix operator symbols.  These terms have no associativity
and a low precedence, thus forcing to use parentheses.  An
implementation would only affect the lexer and should not be too hard. 
Would other people like this feature, too?

-- Christian

-- 
Christian Lindig          Harvard University - DEAS
lindig@eecs.harvard.edu   33 Oxford St, MD 242, Cambridge MA 02138
phone: +1 (617) 496-7157  http://www.eecs.harvard.edu/~lindig/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Brian Rogoff]

On Mon, 9 Apr 2001, Christian Lindig wrote:
> On Sun, Apr 01, 2001 at 09:26:59PM -0700, Brian Rogoff wrote:
> >     Another unrelated trifling question concerns the syntax of numerical 
> > literals. 
> 
> Now that the spring cleaning for OCaml's syntax (floats, labels,
> constructors) is in full swing, here is my wish:  Haskell allows to
> use any identifier as a binary operator when it is placed in
> backquotes:  x `plus` y.  These operators are often more readable than
> the classic infix operator symbols.  These terms have no associativity
> and a low precedence, thus forcing to use parentheses.  An
> implementation would only affect the lexer and should not be too hard. 
> Would other people like this feature, too?

I've expressed this wish here too. I wonder at this point though if the
use of backquotes will be confusing to human readers due to the syntax of 
polymorphic variants. Anyways, the answer from me is a resounding yes.

On the plus side for classic Caml, I have to admit that while beginners
stumble over the lack of an end for 'let', it is something that the
frequent Caml user really grows to love. As I said, I'm porting a bit of
SML to OCaml and this is something I really like about Caml (though I do
like their interCap naming convention a bit better than our under_scores :)

-- Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[David McClain]

> Haskell allows to
> use any identifier as a binary operator when it is placed in
> backquotes:  x `plus` y.  These operators are often more readable than
> the classic infix operator symbols.  These terms have no associativity
> and a low precedence, thus forcing to use parentheses.  An
> implementation would only affect the lexer and should not be too hard.
> Would other people like this feature, too?

Yes, indeed! I have implemented this in my NML which is a very simple
language in comparison to OCaml, but it borrowed the OCaml Lex and Yacc as
starting points. It was very easy to implement this feature and I tend to
use it most often with integer divide, modulo, and the bit twiddling
primitives, as in

    let x = y `mod` z in ...

I also have a syntax for list and vector comprehensions, a la Haskell. Very
convenient for terse programming, e.g.,

    let x = [(a,b) |: a <- [1 .. 100], b <- 100 - a] in ...

- DM

----- Original Message -----
From: "Christian Lindig" <lindig@eecs.harvard.edu>
To: "Caml Mailing List" <caml-list@inria.fr>
Sent: Monday, April 09, 2001 8:34 AM
Subject: Re: [Caml-list] petty complaints


> On Sun, Apr 01, 2001 at 09:26:59PM -0700, Brian Rogoff wrote:
> >     Another unrelated trifling question concerns the syntax of numerical
> > literals.
>
> Now that the spring cleaning for OCaml's syntax (floats, labels,
> constructors) is in full swing, here is my wish:  Haskell allows to
> use any identifier as a binary operator when it is placed in
> backquotes:  x `plus` y.  These operators are often more readable than
> the classic infix operator symbols.  These terms have no associativity
> and a low precedence, thus forcing to use parentheses.  An
> implementation would only affect the lexer and should not be too hard.
> Would other people like this feature, too?
>
> -- Christian
>
> --
> Christian Lindig          Harvard University - DEAS
> lindig@eecs.harvard.edu   33 Oxford St, MD 242, Cambridge MA 02138
> phone: +1 (617) 496-7157  http://www.eecs.harvard.edu/~lindig/
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] petty complaints

[Pierre Weis]

> On Sun, Apr 01, 2001 at 09:26:59PM -0700, Brian Rogoff wrote:
> >     Another unrelated trifling question concerns the syntax of numerical 
> > literals. 
> 
> Now that the spring cleaning for OCaml's syntax (floats, labels,
> constructors) is in full swing, here is my wish:  Haskell allows to
> use any identifier as a binary operator when it is placed in
> backquotes:  x `plus` y.  These operators are often more readable than
> the classic infix operator symbols.  These terms have no associativity
> and a low precedence, thus forcing to use parentheses.  An
> implementation would only affect the lexer and should not be too hard. 
> Would other people like this feature, too?
> 
> -- Christian
> 
> -- 
> Christian Lindig          Harvard University - DEAS
> lindig@eecs.harvard.edu   33 Oxford St, MD 242, Cambridge MA 02138
> phone: +1 (617) 496-7157  http://www.eecs.harvard.edu/~lindig/
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

For simplicity, this would require that polymorphic variant
constructors obey to the rule `UIDENT (meaning that a polymorphic
variant constructors must start with an upper case letter). Otherwise
we would depend on the ``longest match'' rule or careful use of
spaces, as exemplify by:

        Objective Caml version 3.01

# (fun _ _ -> 1) `poi`gee;;
- : int = 1

On the other hand, the new infix identifiers would start by a lower
case letter (as usual value identifiers).

As soon as those simple problems have been checked and resolved, I
think this notation is a reasonable way to have infix identifiers in
the spirit of the current syntax, i.e. with no infix declarations,
just based on lexical analysis.

Hope this helps,

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

Re: [Caml-list] petty complaints

[Marcin 'Qrczak' Kowalczyk]

Mon, 9 Apr 2001 18:29:46 +0200 (MET DST), Pierre Weis <Pierre.Weis@inria.fr> pisze:

> On the other hand, the new infix identifiers would start by a lower
> case letter (as usual value identifiers).

Well, in Haskell you may infixize constructor names too. Including patterns
and their definition. The name can be even qualified with a module (inside
backquotes), but nothing more complex is allowed there, and it doesn't apply
to types.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Petty complaints

[Fabrice Le Fessant]

>  You can create a module Types, where you define all the Pervasives
>  types, like this:
>  
>  type char = char
>  type int = int
>  and so on...
>  
>  Then, you can use Types.char instead of char, no ?

Sorry, you should probably do something like:

type my_char = char
type char = my_char

and so on... since type definitions are recusive.

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Petty complaints

[Fabrice Le Fessant]

You can create a module Types, where you define all the Pervasives
types, like this:

type char = char
type int = int
and so on...

Then, you can use Types.char instead of char, no ?

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Petty complaints

[Brian Rogoff]

Hi,
    I'd like to be able to treat the types "defined" in the Pervasives
module as if they really were defined there. This way I could reuse 
type names like array, char, string, and list cleanly by referring to 
the built-ins by their qualified names. Why doesn't it work that way now?
It would even be nice to be able to have the OCaml library modules be 
referable by qualified names, like Pervasives.List, Pervasives.Array, etc...

    Someone recently got bit by the mutable nature of the OCaml built in 
strings. I looked at the mailing list and there was mention that a long 
time ago Caml had immutable strings (ropes?) and arrays, but that no one
used them. I'm building some stuff using version arrays now (Martin
Erwig's Functional Graph Library) and while they're simple enough to write
in OCaml I bet built in immutable arrays would be much faster.

-- Brian
 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr