Re: [Caml-list] Scanf [was: Productivity improvement]

Re: [Caml-list] Scanf [was: Productivity improvement]

[Alessandro Baretta]

Pierre Weis wrote:
>>
>>The fact is, I don't like the look and feel of Unix scanf 
>>and printf.
> 
> 
> However, if what you dislike about those functions is the conciseness
> of the format strings, there is not much to say ...
> 

Not the conciseness, of course. I dislike the lack of 
readability of format strings. I'd like to write:
let format = int + float + float + string + int
and, voilà mon format! Then there would have to be some 
additional details such as having a scanf function taking an 
in_channel, a format such as the above, and


>>I'd rather something simpler, that does not 
>>require compiler magic. Scanf and printf require compiler 
>>magic even the the almost typeless C language. Is it not 
>>incoherent to maintain virtually untypeable constructs in a 
>>language that claims to have a bullet-proof type system? 
>>(With the sole exception of Obj.magic)
> 
> 
> I claim that scanf and printf are statically type checked in Caml, and
> require no magic from the user nor from the compiler (except evidently
> the addition of an extra typing rule for the proper typechecking of
> those format string constants, exactly as we have typechecking rules
> for other complex structured constants such as lists or vectors or
> strings). I think the Caml implementation is clean, except for the
> fact that string format constants cannot be lexically distinguished
> from ordinary string constants. However, this little glitch has never
> been reported by any of our users who seem to be happy with this
> little flavor of overloading in the language.

Ah, so this is how the "magic" from the compiler works. 
Formats are string literals only in the concrete syntax of 
the language; whereas, in the abstract syntax, formats are a 
different type. The typing machinery behind looks more 
complicated than I dare delve into for now

> Look at the transposition of your code in Caml: our scanf and printf
> functions are not mere transpositions of the equivalent C
> functions. They are more functional in spirit and much less error
> prone than their C equivalent, since they are fully typechecked (and
> there are no 0 valued argument provided by default, nor multiple usage
> of the same format to parse extra arguments, nor any of such error
> prone unique (mis-)features).

Alright. They probably resemble their C counterparts so much 
that I have overlooked the differences.

> In effect, given that the typing rule is based on the ('a, 'b, 'c)
> format type constructor, so higly polymorphic that many people do not
> understand it at all (let alone its unification and interaction with
> the definition types of printf and scanf-like functions); given that
> the Caml code for those primitives is entirely based on continuations
> (that many people found difficult to use and masterize); we can state
> that the scanf and printf features are based on polymorphism and
> continuations. Polymorphism and continuations are often considered as
> the distinguished features of ML-like languages, precisely in the
> "duro e puro" kernel of functional languages :)

IOW, you are telling me I should study the details of the 
machinery behind scanf and printf. I will. But I still 
wonder if I can cook up a working, toy example, of the 
scanf-I've-always-dreamt-of-but-never-dared-to-code.

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] Scanf [was: Productivity improvement]

[Pierre Weis]

Alex wrote:

> > However, if what you dislike about those functions is the conciseness
> > of the format strings, there is not much to say ...
> > 
> 
> Not the conciseness, of course. I dislike the lack of 
> readability of format strings. I'd like to write:
> let format = int + float + float + string + int
> and, voilà mon format! Then there would have to be some 
> additional details such as having a scanf function taking an 
> in_channel, a format such as the above, and

So, I think what you want a format concatenation primitive to build-up
your format from small pieces. Supposing this primitive is available
and named ( ^^ ) you would write:

let format = "%i" ^^ "%f" ^^ "%f" ^^ "%s" ^^ "%i"

I agree with you that this primitive is lacking from the current
system. However, as already mentioned by Damien some weeks ago, by
Xavier a long time ago, and by me in this thread, it is possible to
add such a primitive, if we add an extra type variable to the format
type constructor.

This would be slightly not backward compatible for people that use to
add explicit type constraints with format types in their programs,
something like 

(expression : (int, bool, string) format)

I'm curious to know if there are many users of Objective Caml that
ever used such a complex type constraint ???

(The Caml implementors being excepted evidently, since these
constraints are necessary to define printf and scanf in the first
place)

If somebody would object about adding a fourth type variable to the
format constructor, please let me know (drop me a message directly, it
is useless to bother this mailing list).

> IOW, you are telling me I should study the details of the 
> machinery behind scanf and printf. I will. But I still 
> wonder if I can cook up a working, toy example, of the 
> scanf-I've-always-dreamt-of-but-never-dared-to-code.
> 
> Alex

Sure, you should give it a serious try and let us know when you get
something that works.

All the best,

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