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

[Alessandro Baretta <alex@baretta.com>]

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