[Caml-list] function vs. parser

[Caml-list] function vs. parser

[SooHyoung Oh]

Hi!

Could anyone explain me why "parser" was introduced in Ocaml?
As you know, "function" is using in the caml light-instead of "parser".
"parser" must be a reserved word like "let" and "function", right?

I reviewed  "The Objective Caml system release 3.02", specially
  1.8 Pretty-printing and parsing
      it introduces lex and parser.
  7.1 Streams and stream parser
      it shows the syntax of parser and stream matching.

But I don't know why "parser" was introduced.
Here is an example.

# let next = parser
  [< 'x >] -> x
  | [<>] -> raise (Failure "end of stream")
  ;;
val next : 'a Stream.t -> 'a = <fun>

Thanks in advance for your help.

---
SooHyoung Oh

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Daniel de Rauglaudre]

Hi,

On Thu, Sep 13, 2001 at 05:20:11PM +0900, SooHyoung Oh wrote:

> Could anyone explain me why "parser" was introduced in Ocaml?
> As you know, "function" is using in the caml light-instead of "parser".
> "parser" must be a reserved word like "let" and "function", right?

Right: "parser" is used because they are not functions. In Caml Light,
we used "function", but it was an bad idea: the pattern matching rules
in parsers have nothing to do with the pattern matching rules in
functions and it was important to separate the notions.

Another reason is that in OCaml, after "parser" (and after the streams
patterns), you can put a pattern to bind the current stream count:

    parser bp
      [< .... >] ep -> (* bp: stream count before the matching;
                          ep: stream count after the matching *)
    | [< .... >] ep -> (* same... *)
    | ...

With "function", the language would be more complicated to parse.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Brian Rogoff]

On Thu, 13 Sep 2001, Daniel de Rauglaudre wrote:
> On Thu, Sep 13, 2001 at 05:20:11PM +0900, SooHyoung Oh wrote:
>
> > Could anyone explain me why "parser" was introduced in Ocaml?
> > As you know, "function" is using in the caml light-instead of "parser".
> > "parser" must be a reserved word like "let" and "function", right?
>
> Right: "parser" is used because they are not functions. In Caml Light,
> we used "function", but it was an bad idea: the pattern matching rules
> in parsers have nothing to do with the pattern matching rules in
> functions and it was important to separate the notions.

I have a petty complaint. Another name would have been better, say "parse"
to match "match" since "parser" is a good name for a type and at least in
English there are no good synonyms. If you start writing combinator
parsers you have to hack the keyword parser to be parser_t or _parser or
somesuch, which is a little ugly.

Hey, I said it is a *petty* complaint! ;-)

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Daniel de Rauglaudre]

Hi,

> I have a petty complaint. Another name would have been better, say "parse"
> to match "match"

But "parser" is like "function", not like "match".

> since "parser" is a good name for a type and at least in English
> there are no good synonyms. If you start writing combinator parsers
> you have to hack the keyword parser to be parser_t or _parser or
> somesuch, which is a little ugly.

Same problem with "type": in my parsers, I would like to have "expr",
"patt" and "type". I named it "ctyp", ugly too. And "constraint"...
which is named "constrain" in the OCaml parser. It has been the
problem with keywords since the Pascal language...

> Hey, I said it is a *petty* complaint! ;-)

Well, there is some syntactic preprocessor for OCaml - I don't
remember the name - which can do that...

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Brian Rogoff]

On Thu, 13 Sep 2001, Daniel de Rauglaudre wrote:
> > since "parser" is a good name for a type and at least in English
> > there are no good synonyms. If you start writing combinator parsers
> > you have to hack the keyword parser to be parser_t or _parser or
> > somesuch, which is a little ugly.
>
> Same problem with "type": in my parsers, I would like to have "expr",
> "patt" and "type". I named it "ctyp", ugly too. And "constraint"...
> which is named "constrain" in the OCaml parser. It has been the
> problem with keywords since the Pascal language...

It's funny that you should say that since the modern functional languages
play more tricks with lexical syntax than more mainstream languages in
order to carve up the limited namespace. We already use capitalization
and also funny 'identifiers for type variables. In Dylan they rely on a
bracketing convention for <types> to prevent clashes, but I think it's
only a convention. In MLs, people generally don't seem to like such
conventions (I've gotten disgusted looks when I use the C convention
of suffixing  _t to type names in order to create a unique namespace
for types :-) but the ugliness pops up somewhere else.

We'll not get into the Lisp vs Scheme debate here I think, but yeah,
you're right, managing the namespace is an old problem. Maybe in a
post-Unicode world everything will be OK.

> > Hey, I said it is a *petty* complaint! ;-)
>
> Well, there is some syntactic preprocessor for OCaml - I don't
> remember the name - which can do that...

Touche. Wow, I notice that the version of the manuals for that preprocessor
exceeds the OCaml version number. Now that is fast turnaround time!

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Pierre Weis]

[...]
> Well, there is some syntactic preprocessor for OCaml - I don't
> remember the name - which can do that...
> 
> -- 
> Daniel de RAUGLAUDRE

I can help: as far as I remember this tool is named Camlp4. However, I
don't remember who wrote it, but you may find some more information at
this URL

        http://pauillac.inria.fr/caml/camlp4/

PS: Sorry Daniel, I could not resist to advertize your (excellent) work!

Pierre Weis

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


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Gerd Stolpmann]

On Thu, 13 Sep 2001, Krishnaswami, Neel wrote:
>Anyway, for some Caml-related content, is there a way to use qualified 
>paths and infix notation together?
>
>I mean, if I have:
>
>  module Foo = struct let (+++) x y = List.append x y end
>
>Right now I have to write 
> 
>  Foo.(+++) [1; 2] [3; 4]
>
>Is there any way I can write something like 
>
>  [1; 2] Foo.+++ [3; 4]
>
>without using open or rebinding the Foo module's function in the local
>namespace?

As far as I know, it is not possible.

As a workaround, I use sometimes a submodule only for operators:

module Foo = struct
  let foo x y = ...
  
   module Operators = struct
      let (+++) = foo
   end
end

So you can open only the Foo.Operators module, and have more control over the
namespace.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Krishnaswami, Neel]

Brian Rogoff [mailto:bpr@best.com] wrote:
> On Thu, 13 Sep 2001, Krishnaswami, Neel wrote:
> >
> > Yeah, it's a convention, since types are first-class values 
> > in Dylan. Such conventions are easy to create in Dylan because 
> > it's way permissive about which characters are legal in identifiers 
> > than most languages are -- almost all punctuation is legal. This 
> > produces a different set of complaints, though: people are unhappy 
> > that they have to write "foo + bar", because "foo+bar" is a distinct
> > identifier.
> 
> This is a good thing IMO. The only exceptions of course being 
> things like (), ;, and ",".

I agree with you, but the sheer volume is astounding. If I were a 
language designer, I'd strongly consider restricting identifiers to 
[a-zA-Z0-9_] just to keep the noise level down! It sucks, but in a
traditional way. :)

> > > Maybe in a post-Unicode world everything will be OK.
> 
> I guess I really should have put a :-) there, huh?

Probably -- I've seen too many people seriously propose this to read
it as a joke anymore.

> > Doesn't Caml use such a convention to set the precedence of infix
> > functions, so that *.. has higher precedence that +..?
> 
> Yes, be careful with | vs || and stuff like that with infixes. I got
> burned there recently. Doh!

Ooh, that's nasty. 

> > I think that's pretty neat actually. I find it much more readable 
> > than Haskell's `backquote` mechanism.
> 
> But you can use names with backquotes.

That's -why- I find it more readable. Simple juxtaposition is usually
left-to-right function application, with the exception that things made
of nonalphabetic characters are infix. Seeing something like x `frob` y
is really hard for me to read, since I want to read it as the function
x taking two arguments. But maybe this just takes a little more practice 
than I've had.

Anyway, for some Caml-related content, is there a way to use qualified 
paths and infix notation together?

I mean, if I have:

  module Foo = struct let (+++) x y = List.append x y end

Right now I have to write 
 
  Foo.(+++) [1; 2] [3; 4]

Is there any way I can write something like 

  [1; 2] Foo.+++ [3; 4]

without using open or rebinding the Foo module's function in the local
namespace?
 
--
Neel Krishnaswami
neelk@cswcasa.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Brian Rogoff]

On Thu, 13 Sep 2001, Krishnaswami, Neel wrote:

> Brian Rogoff [mailto:bpr@best.com] wrote:
> > On Thu, 13 Sep 2001, Daniel de Rauglaudre wrote:
> > >
> > > Same problem with "type": in my parsers, I would like to
> > > have "expr", "patt" and "type". I named it "ctyp", ugly too.
> > > And "constraint"... which is named "constrain" in the OCaml parser.
> > > It has been the problem with keywords since the Pascal language...
> >
> > It's funny that you should say that since the modern functional
> > languages play more tricks with lexical syntax than more mainstream
> > languages in order to carve up the limited namespace. We already use
> > capitalization and also funny 'identifiers for type variables. In Dylan
> > they rely on a bracketing convention for <types> to prevent clashes,
> > but I think it's only a convention.
>
> Yeah, it's a convention, since types are first-class values in Dylan.
> Such conventions are easy to create in Dylan because it's way permissive
> about which characters are legal in identifiers than most languages
> are -- almost all punctuation is legal. This produces a different set
> of complaints, though: people are unhappy that they have to write
> "foo + bar", because "foo+bar" is a distinct identifier.

This is a good thing IMO. The only exceptions of course being things like
(), ;, and ",".
>
> > In MLs, people generally don't seem to like such conventions (I've
> > gotten disgusted looks when I use the C convention of suffixing  _t
> > to type names in order to create a unique namespace for types :-) but
> > the ugliness pops up somewhere else.
>
> Doesn't Caml use such a convention to set the precedence of infix
> functions, so that *.. has higher precedence that +..?

Yes, be careful with | vs || and stuff like that with infixes. I got
burned there recently. Doh!

> I think that's
> pretty neat actually. I find it much more readable than Haskell's
> `backquote` mechanism.

But you can use names with backquotes.

> > Maybe in a post-Unicode world everything will be OK.

I guess I really should have put a :-) there, huh?

> Yeah, right. Combining characters and different code values with
> identical glyphs and the like make certain that the only result of
> Unicode adoption will be to increase the amount of confusion. I wonder
> if there's a computer equivalent to the second law of thermodynamics:
> the incoherence of a computer system always increases, or something
> like that. :)

I heard Robert Dewar describe it as the ratchet effect of programming
language design. Nothing ever gets removed, just added.

Oh well, as our erstwhile moderator said, CamlP4 rocks for the syntax
whiner. Maybe we should have another mailing list, the
caml-syntax-whining-list, for people like me who like to complain about
syntax? :-)

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] function vs. parser

[Krishnaswami, Neel]

Brian Rogoff [mailto:bpr@best.com] wrote:
> On Thu, 13 Sep 2001, Daniel de Rauglaudre wrote:
> >
> > Same problem with "type": in my parsers, I would like to
> > have "expr", "patt" and "type". I named it "ctyp", ugly too.
> > And "constraint"... which is named "constrain" in the OCaml parser.
> > It has been the problem with keywords since the Pascal language...
>
> It's funny that you should say that since the modern functional
> languages play more tricks with lexical syntax than more mainstream
> languages in order to carve up the limited namespace. We already use
> capitalization and also funny 'identifiers for type variables. In Dylan
> they rely on a bracketing convention for <types> to prevent clashes,
> but I think it's only a convention.

Yeah, it's a convention, since types are first-class values in Dylan.
Such conventions are easy to create in Dylan because it's way permissive 
about which characters are legal in identifiers than most languages 
are -- almost all punctuation is legal. This produces a different set 
of complaints, though: people are unhappy that they have to write 
"foo + bar", because "foo+bar" is a distinct identifier.

> In MLs, people generally don't seem to like such conventions (I've
> gotten disgusted looks when I use the C convention of suffixing  _t
> to type names in order to create a unique namespace for types :-) but
> the ugliness pops up somewhere else.

Doesn't Caml use such a convention to set the precedence of infix
functions, so that *.. has higher precedence that +..? I think that's
pretty neat actually. I find it much more readable than Haskell's
`backquote` mechanism.

> Maybe in a post-Unicode world everything will be OK.

Yeah, right. Combining characters and different code values with 
identical glyphs and the like make certain that the only result of 
Unicode adoption will be to increase the amount of confusion. I wonder 
if there's a computer equivalent to the second law of thermodynamics: 
the incoherence of a computer system always increases, or something 
like that. :)
 
--
Neel Krishnaswami
neelk@cswcasa.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr