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