* Re: [Caml-list] Scanf [was: Productivity improvement]
[not found] <200207121224.OAA24345@pauillac.inria.fr>
@ 2002-07-12 13:32 ` Alessandro Baretta
2002-07-12 17:43 ` Pierre Weis
0 siblings, 1 reply; 2+ messages in thread
From: Alessandro Baretta @ 2002-07-12 13:32 UTC (permalink / raw)
To: Ocaml
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
^ permalink raw reply [flat|nested] 2+ messages in thread