[Caml-list] Functional scanning facilities

[Caml-list] Functional scanning facilities

[Alessandro Baretta]

How about something like the follwing--the idea coming from 
posts I read a while ago about CPS programming:

module Scan : sig

(* type 'a set *)

type ('a, 'b) conversion  = ( 'b -> 'a ) -> 'a

(* the following signatures refer to stdin scanners *)
val s  : (string -> 'a) -> 'a
val d  : (int    -> 'a) -> 'a
val i  : (int    -> 'a) -> 'a
val o  : (int    -> 'a) -> 'a
val x  : (int    -> 'a) -> 'a
val f  : (float  -> 'a) -> 'a
val c  : int -> (string -> 'a) -> 'a
(* val set: char set -> (string -> 'a) -> 'a *)

type ('a, 'b) scanner = ( 'b -> 'a ) -> ('a, 'c) scanner
val nil :  (unit, unit) scanner

val (+)  : 'a scanner -> ('a, 'b) conversion -> 'a scanner

val get  : ('a, 'b) scanner -> 'a list

end

Basically, a scanner is a fifo of conversions. Scanners are 
built by +ing a scanner (left operand) and a conversion 
(right operand). The fifo must be initialized with a nil 
scanner, containing no conversions. After a scanner has been 
built, it must be applied self-recursively to a succession 
of parameters, each representing a callback for a conversion 
  in the fifo of the scanner. Because a scanner has a 
recursive type, the result of its application to a callback 
is a scanner with one less convertions in its fifo. As the 
convertions are performed, each the result of each callback 
is appended to a list maintained internally by the scanner. 
Finally, when all conversions have been performed, the 'a 
list built by the scanner can be gotten with the get function.

Of course, all this works in my best dreams. The scanner 
type cannot be defined as I have because of the unbound type 
parameter 'c. But there are work arounds, although not 
terribly elegant. For example, we could define a big variant
type callback_parameter = String of string | Int of int | 
Float of float | ...
but this would greatly reduce the beauty of such a solution.

At 3:36 in the morning I can do no better than this. Pierre, 
Xavier, your turn.

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] Functional scanning facilities

[John Prevost]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    ab> How about something like the follwing--the idea coming from
    ab> posts I read a while ago about CPS programming:

It works quite well.  Take a look at Lindig's O'Caml implementation of
parser combinators at http://www.gaertner.de/~lindig/software/mylib.html

A more complete description of how these work (expressed monadically)
is available in a paper by Hutton and Meijer at
http://www.cs.nott.ac.uk/~gmh/monparsing.pdf

These techniques can be applied quite easily in O'Caml, although the
way infix definitions work leads to some rather... interesting choices
of symbols.

John.


-------------------
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] Functional scanning facilities

[Pierre Weis]

> >>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:
> 
>     ab> How about something like the follwing--the idea coming from
>     ab> posts I read a while ago about CPS programming:
> 
> It works quite well.  Take a look at Lindig's O'Caml implementation of
> parser combinators at http://www.gaertner.de/~lindig/software/mylib.html
> 
> A more complete description of how these work (expressed monadically)
> is available in a paper by Hutton and Meijer at
> http://www.cs.nott.ac.uk/~gmh/monparsing.pdf
> 
> These techniques can be applied quite easily in O'Caml, although the
> way infix definitions work leads to some rather... interesting choices
> of symbols.
> 
> John.
> 
> -------------------
> 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

Em, sorry to interrupt you: I'm a fan of combinators since decades (my
thesis was entitled something like ``compiling with combinators''), I
also do love lambda-calculus and monades that I consider extremely
elegant and powerful theoretical tools, but wait, wait, wait ...

Here, we want to design and implement a practical, compact, simple to
understand, and easy way to print and scan in the context of a
functional language with full-fledged imperative features (we are not
in a lazy context where monades are mandatory anyway).

In this favourable situation, I'm afraid no combinatorial approach can
compete with the readability and compactness of C-style formats. In
addition, from the user's point of view, the seamingly flat
first-order typing simplicity of Caml printf (and now scanf)
primitives will be extremely hard to beat. Let alone the strongly
symetrical status and overall treatment of scanf and printf that is so
wonderful in the actual implementation of the Objective Caml
library.

Note that I am so enthousiastic about the new Scanf module because
this problem of implementing a C-like scanf facility in Caml was a
background thread in my head for at least 5 years, before I found the
tricks that lead to the actual scanf implementation ...

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] Functional scanning facilities

[Basile STARYNKEVITCH]

>>>>> "Pierre" == Pierre Weis <pierre.weis@inria.fr> writes:

    Pierre> Here, we want to design and implement a practical,
    Pierre> compact, simple to understand, and easy way to print and
    Pierre> scan in the context of a functional language with
    Pierre> full-fledged imperative features [...]

    Pierre> In this favourable situation, I'm afraid no combinatorial
    Pierre> approach can compete with the readability and compactness
    Pierre> of C-style formats. [...]

I'm not expert enough about combinators, but I have a tiny suggestion
regarding formats (I implemented this suggestion in C++ a few years
ago).

I think that internationalization or localization is very important
today and it wasn't even thinkable at the time -20 [C printf] or 40
years [Fortran Format] ago- formats have been invented.

The idea is that the format string is a true string (typically
localized thru a gettext(3) or equivalent stuff) containing "format
variables". Then the arguments are "bindings" of these "format
variables" to values. Of course what I call "format variables" and
"bindings" is unrelated to the variables and bindings of Ocaml (which
have sense at compile time only; at runtime we only have values and
closures).

So instead of doing

    printf "a=%d x=%g" a x

or perhaps (this certainly does not work today)

    printf (gettext "a=%$1d x=%$2g") a x

my suggestion would be something like

    printb "a=$A x=$B" (PrintIntBind ('A',a)) (PrintRealBind ('B',x))

where we have a type like

printbinding_t = PrintIntBind of char * int | PrintRealBind of char * float 
               | ....

Now of course the code in my example is clumsy. What is needed is just
some syntactic device (e.g. a suitable camlp4 macro, or even a builtin
device in Ocaml like the lazy keyword) to shorten e.g. the
(PrintIntBind ('A',a)) syntax into something shorter, e.g. such as

    printb "a=$A x=$B" @i:A=a @f:B=b

or even, having localization in mind, something like

   lprintb "a=$A x=$B" @i:A=a @f:B=b

which would be a syntax for 

   printb (gettext "a=$A x=$B") (PrintIntBind ('A',a)) (PrintRealBind ('B',x))

I think that formatted input and output is in practice important
enough to be assisted thru specific syntax extension.


Regarding the current ('a,'b,'c) format type, I am lacking of
documentation on the type variables 'a 'b and 'c. I also think that it
is pityful that the "%a" and "%t" functional printers have a type
which depends if they occur inside a Printf.printf Printf.bprintf or
Printf.sprintf function


I am very glad that the forthcoming Ocaml release has a scanf (and a
kprintf) facilities. Both are very invaluable. Thanks again to the
Ocaml team for the great work!

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 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile at Starynkevitch point 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] Functional scanning facilities

[John Prevost]

>>>>> "pw" == Pierre Weis <pierre.weis@inria.fr> writes:

    pw> Here, we want to design and implement a practical, compact,
    pw> simple to understand, and easy way to print and scan in the
    pw> context of a functional language with full-fledged imperative
    pw> features (we are not in a lazy context where monades are
    pw> mandatory anyway).

Right right, I agree that the scanf that's coming is a better solution
for O'Caml.  But on the other hand, I prefer combinator parsing (even
in O'Caml where it's slightly awkward) to the stream parsers in
O'Caml.  And sometimes I like to use combinator formatters rather than
printf.  There's a place for both kinds of things.  :)

John.

-------------------
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] Functional scanning facilities

[Stefano Zacchiroli]

On Fri, Jul 12, 2002 at 09:24:27AM +0200, Pierre Weis wrote:
> Note that I am so enthousiastic about the new Scanf module because
> this problem of implementing a C-like scanf facility in Caml was a
> background thread in my head for at least 5 years, before I found the
> tricks that lead to the actual scanf implementation ...

Have you planned to publish some paper or even a simple report on these
"tricks"?

Thanks,
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] Functional scanning facilities

[Pierre Weis]

> On Fri, Jul 12, 2002 at 09:24:27AM +0200, Pierre Weis wrote:
> > Note that I am so enthousiastic about the new Scanf module because
> > this problem of implementing a C-like scanf facility in Caml was a
> > background thread in my head for at least 5 years, before I found the
> > tricks that lead to the actual scanf implementation ...
> 
> Have you planned to publish some paper or even a simple report on these
> "tricks"?
> 
> Thanks,
> 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

I should do so ...

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