From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA26729; Fri, 12 Jul 2002 15:25:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA26725 for ; Fri, 12 Jul 2002 15:25:22 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (r-mi214-6a229.tin.it [62.211.4.229]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6CDPLj28090 for ; Fri, 12 Jul 2002 15:25:21 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id DE0452739C for ; Fri, 12 Jul 2002 15:32:11 +0200 (CEST) Message-ID: <3D2EDA5B.2050102@baretta.com> Date: Fri, 12 Jul 2002 15:32:11 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: it, en MIME-Version: 1.0 To: Ocaml Subject: Re: [Caml-list] Scanf [was: Productivity improvement] References: <200207121224.OAA24345@pauillac.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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