[Caml-list] Different types of streams

[Caml-list] Different types of streams

[Nicolas George]

Is there any deep reason to have two incompatible types of streams in the
same Caml type: those built using [< >] expressions and those built with
Stream.from Stream.of_channel? I can not see anything in the source code,
and I indeed managed to modify it to remove this distinction. It has a
small cost: I had to add an `index' field in the gen structure, because the
global `count' field could not be used anymore, and of_stream streams are
slower by about 5%. But I think the stream type would be really more useful
like that.
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

Hi,

On Sun, Aug 26, 2001 at 08:23:17PM +0200, Nicolas George wrote:

> Is there any deep reason to have two incompatible types of streams in the
> same Caml type: those built using [< >] expressions and those built with
> Stream.from Stream.of_channel?

I am the implementor of the streams. Actually, I have never been interested
in the streams themselves, but more in parsing. I would have preferred that
streams were just a couple of functions: (unit -> 'a) * (unit -> unit) where
the first function returns the first element of the stream and the second
function throws the first element away.

I am not sure that streams built with [< >] are so interesting, especially
if they are destinated to a real parser.

-- 
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] Different types of streams

[Nicolas George]

Le lundi 27 août 2001 à 11:49, Daniel de Rauglaudre a écrit :
> I am not sure that streams built with [< >] are so interesting, especially
> if they are destinated to a real parser.

I was thinking to streams not used as input for a parser, but as generic
data channel: a dumb sequence of values passed from one function to
another. Like some sort of list, but with fast concatenation and optionnal
lazy evaluation.
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

Hi,

On Mon, Aug 27, 2001 at 07:47:36PM +0200, Nicolas George wrote:

> I was thinking to streams not used as input for a parser, but as generic
> data channel: a dumb sequence of values passed from one function to
> another. Like some sort of list, but with fast concatenation and optionnal
> lazy evaluation.

In this case, if you don't use parsers, it is not necessary to use the
streams of the Stream library. Why not define your own streams?

   type 'a stream =
      Nil
    | Cons of 'a Lazy.t * 'a stream Lazy.t
    | App of 'a stream Lazy.t * 'a stream Lazy.t

-- 
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] Different types of streams

[Nicolas George]

Le mardi 28 août 2001 à 10:20, Daniel de Rauglaudre a écrit :
>    type 'a stream =
>       Nil
>     | Cons of 'a Lazy.t * 'a stream Lazy.t
>     | App of 'a stream Lazy.t * 'a stream Lazy.t

This is approximatively what I have done. And aftr realizing that this was
almost the same structure as Stream.t, I wondered "why reinvent the wheel
every?".
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

Hi,

On Tue, Aug 28, 2001 at 11:33:10AM +0200, Nicolas George wrote:

> This is approximatively what I have done. And aftr realizing that this was
> almost the same structure as Stream.t, I wondered "why reinvent the wheel
> every?".

Perhaps I do that when we move the streams and parsers from OCaml to Camlp4.
We plan to do that one day.

-- 
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] Different types of streams

[Christian RINDERKNECHT]

Hi Daniel,

On Mon, Aug 27, 2001 at 11:49:06AM +0200, Daniel de Rauglaudre wrote:
> 
> I am the implementor of the streams. Actually, I have never been interested
> in the streams themselves, but more in parsing. [...]
> 
> I am not sure that streams built with [< >] are so interesting, especially
> if they are destinated to a real parser.

As you may remember, I wrote a fairly complex and big parser (~4000
lines) using the streams [< >]. The story is that I first computed by
hand the EBNF grammar, and then the streams [< >] were of great help
because their syntax is close to the BNF one. This made maintenance
easier too.

As an aside: the performance of my parser was not a concern,
feasability was the main challenge. I nevertheless understand it can
be an important issue. I understood there was a plan to remove the [<
>] from OCaml, and to request users using camlp4, is it correct?

Best regards,


Christian

-----------------------------------------------------------------------
Christian Rinderknecht                     Phone +33 (0)1 60 76 44 43
Institut National des Télécommunications   Fax   +33 (0)1 60 76 47 11
Département Logiciels Réseaux (LOR)        WWW
9, Rue Charles Fourier, F-91011 Évry Cedex
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

Salut Christian,

On Wed, Sep 05, 2001 at 03:03:35AM +0200, Christian RINDERKNECHT wrote:

> As you may remember, I wrote a fairly complex and big parser (~4000
> lines) using the streams [< >]. The story is that I first computed by
> hand the EBNF grammar, and then the streams [< >] were of great help
> because their syntax is close to the BNF one. This made maintenance
> easier too.

When I said streams are not so interesting, I meant only the ones built
with [< >], not the ones built with Stream.from, Stream.of_string and
Stream.of_channel. And of course, I am still using parsers, especially
in the grammars of Camlp4 using streams as input.

> As an aside: the performance of my parser was not a concern,
> feasability was the main challenge. I nevertheless understand it can
> be an important issue. I understood there was a plan to remove the [<
> >] from OCaml, and to request users using camlp4, is it correct?

Yes. Is it a problem?

-- 
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] Different types of streams

[STARYNKEVITCH Basile]

>>>>> "Daniel" == Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:
    Daniel>  On Wed, Sep 05, 2001 at 03:03:35AM +0200,
    Daniel> Christian RINDERKNECHT wrote:

[...]

    >> As an aside: the performance of my parser was not a concern,
    >> feasability was the main challenge. I nevertheless understand
    >> it can be an important issue. I understood there was a plan to
    >> remove the [< >] from OCaml, and to request users using camlp4,
    >> is it correct?

    Daniel> Yes. Is it a problem?

Perhaps. standard Ocaml input is done (with the exception of low level
input such as Pervasives.read_line etc....) with the "19.10 Module
Genlex: a generic lexical analyzer" whose documentation mentions
explicitly the [< >] construct.

Several ocaml programs would like to do input without a specific lexer
or a parser. This is done thu Genlex which need the [< >] construct.

I suggest maintaining the [< >] for a while -ie for several years-
(perhaps marking it explicitly as deprecated in the documentation). It
should be probably acceptable to have the [< >] construct handled by a
standard campl4 module, especially if/when camlp4 will be merged into
the main ocaml package.

Should the Genlex module be deprecated, a newer way of making high
level input should be proposed. My opinion is that it should *not* be
modelled on C's infamous scanf.

Formatted input should particularily well be explained, since it is a
function needed by all newcomers. The first program you write is a
hello world, and the second one asks for your name and age and tells
you hello :-)


Best regards to all


**resumé en français:

les flots par [< >] sont indispensables au module Genlex. Ils ne
devraient donc pas être violemment supprimés (avant plusieurs
années). Si Genlex disparaissait, il faudrait un autre procédé de lecture
de haut niveau (autre que Pervasives.read_line et consors). A mon avis
il ne faut surtout pas s' inspirer de l' infâme scanf du C.

Les entrées formattées doivent être bien documentées car elles sont
indispensables au débutant.

Cordialement

N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
work email: Basile point Starynkevitch at cea point fr 
home email: Basile point Starynkevitch at wanadoo point fr 
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

Hi,

> Several ocaml programs would like to do input without a specific lexer
> or a parser. This is done thu Genlex which need the [< >] construct.

The idea is actually as first step to keep Stream and Genlex in OCaml,
and expand the code of genlex.ml (using camlp4). Then the syntax of
streams and parsers could be removed from OCaml. In this case, the
users of genlex can continue using it like before. Only the programs
using the syntax [< >] in streams or parsers would have to use -pp
camlp4o.

-- 
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] Different types of streams

[Alex Cowie]

Basile Starynkevitch wrote "Wed, 05 Sep 2001 10:02:59 +0200." :
> >>>>> "Daniel" == Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:
>     Daniel>  On Wed, Sep 05, 2001 at 03:03:35AM +0200,
>     Daniel> Christian RINDERKNECHT wrote:
> 
> [...]
> 
>     >> As an aside: the performance of my parser was not a concern,
>     >> feasability was the main challenge. I nevertheless understand
>     >> it can be an important issue. I understood there was a plan to
>     >> remove the [< >] from OCaml, and to request users using camlp4,
>     >> is it correct?
> 
>     Daniel> Yes. Is it a problem?
> 
> Perhaps. standard Ocaml input is done (with the exception of low level
> input such as Pervasives.read_line etc....) with the "19.10 Module
> Genlex: a generic lexical analyzer" whose documentation mentions
> explicitly the [< >] construct.
> 
> Several ocaml programs would like to do input without a specific lexer
> or a parser. This is done thu Genlex which need the [< >] construct.
> 
> I suggest maintaining the [< >] for a while -ie for several years-
> (perhaps marking it explicitly as deprecated in the documentation). It
> should be probably acceptable to have the [< >] construct handled by a
> standard campl4 module, especially if/when camlp4 will be merged into
> the main ocaml package.
>

I would strongly support Basile's proposal to retain the [< >] in Ocaml core 
syntax.  I have been using Caml/Ocaml for 5-6 years and I have found that a 
high proportion of the programs I have written recently have used [< >] stream 
parsing.  The convenience of having this parsing facility within the Ocaml 
syntax should not be underestimated particularly for program development under 
the toplevel.

> Should the Genlex module be deprecated, a newer way of making high
> level input should be proposed. My opinion is that it should *not* be
> modelled on C's infamous scanf.
> 
> Formatted input should particularily well be explained, since it is a
> function needed by all newcomers. The first program you write is a
> hello world, and the second one asks for your name and age and tells
> you hello :-)
> 
> 
> Best regards to all
> 
> 
> [**resumé en français: deleted]
> 
> ---------------------------------------------------------------------
> Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
> DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
> work email: Basile point Starynkevitch at cea point fr 
> home email: Basile point Starynkevitch at wanadoo point fr 
> -------------------

Alex Cowie
Research Fellow, Advanced Computing Research Centre
University of South Australia


-------------------
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] Different types of streams

[Daniel de Rauglaudre]

On Wed, Sep 05, 2001 at 06:43:58PM +0930, Alex Cowie wrote:

> The convenience of having this parsing facility within the Ocaml
> syntax should not be underestimated particularly for program
> development under the toplevel.

Under the toplevel, you can #load "camlp4o.cma"

Remember that the streams and parsers in OCaml have a very bad
implementation, not tail recursive and not optimized. We regularly
receive bug reports about their slowness and stack overflows when they
are used.

-- 
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] Different types of streams

[Dave Mason]

(I've cc'ed everyone because for some reason my postings rarely make
it to the mailing list, and if they do they take days.)

>>>>> On Wed, 5 Sep 2001 11:30:21 +0200, Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> said:

> On Wed, Sep 05, 2001 at 06:43:58PM +0930, Alex Cowie wrote:
>> The convenience of having this parsing facility within the Ocaml
>> syntax should not be underestimated particularly for program
>> development under the toplevel.

I want to re-iterate this.  I have several 10's of lines of caml code,
and probably 1/2 of the programs I write use the [< >] parsing.

> Under the toplevel, you can #load "camlp4o.cma"

Honestly, I don't really understand the implications of the
preprocessor.  If that is literally all I have to do and then I can
use the syntax, that is probably fine (and if it's just as easy from
the command line and for ocamlopt).  But I guess I don't understand
why it won't be the default if it's really that trivial.

> Remember that the streams and parsers in OCaml have a very bad
> implementation, not tail recursive and not optimized. We regularly
> receive bug reports about their slowness and stack overflows when
> they are used.

I don't think anyone is arguing against fixing the implementation, but
the [< >] parsers are much more convenient/natural than yacc-like
parsers for many people and purposes.  Even a switch that let me
choose LALR or LL parsing but used the same syntax (as some C-based
tools do - see (I think) ANTLR) would seem to address this.

../Dave
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

On Wed, Sep 05, 2001 at 06:58:59AM -0400, Dave Mason wrote:

> I want to re-iterate this.  I have several 10's of lines of caml code,
> and probably 1/2 of the programs I write use the [< >] parsing.

And what is the problem?

> I don't think anyone is arguing against fixing the implementation

Camlp4 fixes the implementation. It is complicated to add the same
code in OCaml because it is about manipulatation of pieces of program,
which is very easy and simple in Camlp4 and very complicated with
OCaml. If you are not happy, implement the optimization yourself in
OCaml. Good luck.

> but the [< >] parsers are much more convenient/natural than
> yacc-like parsers for many people and purposes.  Even a switch that
> let me choose LALR or LL parsing but used the same syntax (as some
> C-based tools do - see (I think) ANTLR) would seem to address this.

The point is *not* to remove streams!!!! Streams and their LL1 parsers
remain!!! I just ask people to preprocess by "-pp camlp4o". Is that
so complicated? Are you allergic to my program?

-- 
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] Different types of streams

[Dave Mason]

>>>>> On Wed, 5 Sep 2001 14:06:10 +0200, Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> said:

> On Wed, Sep 05, 2001 at 06:58:59AM -0400, Dave Mason wrote:
>> I want to re-iterate this.  I have several 10's of lines of caml
>> code, and probably 1/2 of the programs I write use the [< >]
>> parsing.

> And what is the problem?

Sorry, should have said 10's of *thousands* of lines.

> The point is *not* to remove streams!!!! Streams and their LL1
> parsers remain!!! I just ask people to preprocess by "-pp
> camlp4o". Is that so complicated? Are you allergic to my program?

Please don't get defensive, I'm not meaning to attack you!

You omitted the part of my original email where I said that I honestly
don't know how easy it is to use this through camlp4o.  If it's
trivial (i.e. just add ``-pp camlp4o''), I don't understand why it
won't be the default, and if it's not trivial, I (and several other
people) will be unhappy.

I get the sense, from your apparent upset, that it really is that trivial.

Thanks	../Dave
-------------------
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] Different types of streams

[Nicolas George]

Le mercredi 05 septembre 2001 à 14:06, Daniel de Rauglaudre a écrit :
>		  Are you allergic to my program?

It is normal that some people try to avoid using features not included in
the core distribution of the language. Camlp4 really brings improvements, I
am favourable to have it in the core distribution.
-------------------
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] Different types of streams

[Daniel de Rauglaudre]

On Wed, Sep 05, 2001 at 08:56:41AM -0400, Dave Mason wrote:

> You omitted the part of my original email where I said that I honestly
> don't know how easy it is to use this through camlp4o.  If it's
> trivial (i.e. just add ``-pp camlp4o''), I don't understand why it
> won't be the default, and if it's not trivial, I (and several other
> people) will be unhappy.

Camlp4 allows to write pieces of programs in concrete syntax,
representing abstract syntax. I need that for the streams
implementation and optimization.

In my Camlp4 code, I manipulate things like this:
      <:expr< let x = y in z >>

To have the equivalent in OCaml, I should write:
     {pstr_desc =
         Pstr_eval
           {pexp_desc =
              Pexp_let
                (Nonrecursive,
                 [({ppat_desc = Ppat_var "x";
                    ppat_loc =
                      {loc_start = 4; loc_end = 5; log_ghost = false}},
                   {pexp_desc = Pexp_ident (Longident.Lident "y");
                    pexp_loc =
                      {loc_start = 8; loc_end = 9; log_ghost = false}})],
                {pexp_desc = Pexp_ident (Longident.Lident "z");
                 pexp_loc =
                   {loc_start = 13; loc_end = 14; log_ghost = false}});
            pexp_loc =
              {loc_start = 0; loc_end = 14; log_ghost = false}};
       pstr_loc = {loc_start = 0; loc_end = 14; log_ghost = false}}

I don't know for you, but I prefer program with the first form.

-- 
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] Different types of streams

[Patrick M Doane]

On Wed, 5 Sep 2001, Daniel de Rauglaudre wrote:

> > I don't think anyone is arguing against fixing the implementation
> 
> Camlp4 fixes the implementation. It is complicated to add the same
> code in OCaml because it is about manipulatation of pieces of program,
> which is very easy and simple in Camlp4 and very complicated with
> OCaml. If you are not happy, implement the optimization yourself in
> OCaml. Good luck.

What is wrong with:

  - Including camlp4 in the standard caml distribution
  - Modifiying the caml compilers to always use camlp4 for preprocessing.

To the user, this fixes the implementation without any modification to
how they use their tools. 

BTW, it has been my impression that the Caml team is not too interested in
external development, so implementing the optimization without camlp4 is
not much of an option.

> The point is *not* to remove streams!!!! Streams and their LL1 parsers
> remain!!! I just ask people to preprocess by "-pp camlp4o". Is that
> so complicated? Are you allergic to my program?

I'm not allergic to your program, but other people may be.  Until camlp4
is part of the caml distribution, the proposal is still to remove streams. 
For developers who distribute source code, we now have to demand that
another package be installed on the user's system.  Caml will be for the
better when these two tools are merged.

Patrick Doane

-------------------
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] Different types of streams

[Daniel de Rauglaudre]

On Wed, Sep 05, 2001 at 10:30:37AM -0400, Patrick M Doane wrote:

>   - Including camlp4 in the standard caml distribution

This is planed.

>   - Modifiying the caml compilers to always use camlp4 for preprocessing.

I have renounced that since a long time: they love yacc too much. Most
people consider that parsing = LALR and no other technic can exist.

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

[Caml-list] Camlp4 and CamlIDL in main distribution?

[Markus Mottl]

On Wed, 05 Sep 2001, Patrick M Doane wrote:
> Caml will be for the better when these two tools are merged.

I'd also say that having one distribution for OCaml and Camlp4 would
lead to fewer hassles for developers. Everytime I upgrade OCaml, I have
to upgrade Camlp4, too, because the byte code formats usually become
incompatible.

Nobody will feel hurt by the few extra bytes that Camlp4 adds to the
distribution, even if users don't need it.  The size of the distribution
is really not an argument anymore considering that most internet traffic
probably already consists of multi-megabyte MPEGs and videos, anyway.

CamlIDL could then also be added. I'd say that both of these tools are
so "standard" that they'd deserve a place in the main distribution.
Finally, I'd only have to issue one command then when I want to upgrade
to a new distribution... :-)

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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] Different types of streams

[Patrick M Doane]

On Wed, 5 Sep 2001, Daniel de Rauglaudre wrote:

> >   - Modifiying the caml compilers to always use camlp4 for preprocessing.
> 
> I have renounced that since a long time: they love yacc too much. Most
> people consider that parsing = LALR and no other technic can exist.

This bias may affect people who want to write campl4 extensions, but how
does this apply to users of those extensions?  Anyone willing to write an
extension probably doesn't mind including another argument on the command
line.  It's the users of these extensions that need things to be simple.

Patrick Doane

-------------------
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] Different types of streams

[Brian Rogoff]

On Wed, 5 Sep 2001, Daniel de Rauglaudre wrote:
> On Wed, Sep 05, 2001 at 10:30:37AM -0400, Patrick M Doane wrote:
>
> >   - Including camlp4 in the standard caml distribution
>
> This is planed.

That's wonderful. I suspect that much of the heat you're getting right now
is because people are confused or don't really understand what the plans
are for CamlP4 and OCaml. Maybe that roadmap isn't such a bad idea?

> >   - Modifiying the caml compilers to always use camlp4 for preprocessing.
>
> I have renounced that since a long time: they love yacc too much. Most
> people consider that parsing = LALR and no other technic can exist.

I prefer recursive descent, but my big gripe with yacc(s) is that they
always seem to be stuck in the original 70s BNF. Can't someone just write
an upwardly compatible yacc clone that supports a rich BNF?

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