caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re: string variables in Printf.* calls: Bug, or lack of understanding?
@ 1997-02-24 20:40 Valentin Bonnard
  0 siblings, 0 replies; 3+ messages in thread
From: Valentin Bonnard @ 1997-02-24 20:40 UTC (permalink / raw)
  To: caml-list

[English summary at the end]

>> Dans ce cas, comment avoir un record (en Caml-light):
>> 
>> type Rec = { x: ('a, 'b, 'c) printf__format };;
>> 
>> ne marche pas (variable 'a non lie'e).
>
>Apprenez le langage.  type ('a, 'b, 'c) Rec = ...

Je veut bien, mais le record a plus de 10 champs ce qui 
fait 30 variables de type pour qqchose qui n'est pas 
polymorphe ! (Meme si pour Caml-light il l'est, du point 
de vu du 'domaine du probleme' comme on dit, on a des 
chaines indiquand un format; il n'y a aucun 
polymorphisme la dedans.)

De plus je ne sais pas comment innitialiser les champs:

let f = { x = "toto" };;

ne fonctionne pas.

Tout cela signifie t'il que l'ordre dans lequel est fait 
le typage est important ?

******** 

I want to have a record (in Caml-light) with printf 
format strings.

type Rec = { x: ('a, 'b, 'c) printf__format };;

doesn't work because the vars a, b end c aren't bound.

I have more then 10 fields in the record so does it 
means I need 30 type vars ?

Also I don't know how to create an instance of this 
type.

BTW does the type-system depend on the order in which 
things are typed ?


Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)







^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: string variables in Printf.* calls: Bug, or lack of understanding?
  1997-02-13 18:31 T. Kurt Bond
@ 1997-02-18 16:39 ` Xavier Leroy
  0 siblings, 0 replies; 3+ messages in thread
From: Xavier Leroy @ 1997-02-18 16:39 UTC (permalink / raw)
  To: T. Kurt Bond; +Cc: caml-list, tkb

> 	    Objective Caml version 1.03
> 
> [1] # let s = "%f" in Printf.printf s 10.5;;
>     Characters 30-31:
>     This expression has type string but is here used with type
>       ('a, out_channel, unit) format
> 
> [2] # Printf.printf "%f" 10.5;;
>     10.500000- : unit = ()
> 
> I don't understand why the variable s, which is bound to a string value,
> causes the error in statement 1, while using a literal string in
> statement 2 works as expected.  Can anyone explain?  Or is this a bug?

It's a feature: format strings are typed specially in order to make
printf type-safe. Look at the type for Printf.printf: it's

        ('a, out_channel, unit) format -> ...

and not

        string -> ...

A format string is typed specially and receives a type of the form
(t1, t2, t3) format, for suitable types t1, t2, t3.  For instance, the
format string ``%f %d'' has type

        (float -> int -> 'b, 'c, 'b) format

which, when passed as first argument to Printf.printf, gives the
return type

        float -> int -> unit

which ensures that the next two arguments are a float and an integer,
as expected.

Now comes the dirty hack. In an ideal world, there would be a
different syntax for string literals and for format literals, so that
the type-checker would always know whether to type the literal as a
string or as a format.

For backward compatibility, and because we are somehow running out of
quote characters, format literals have actually the same syntax as
strings, and it's the type expected by the context of the literal that
says whether to type it as a string or as a format. In some sense, the
syntax for string literals is overloaded for format literals as well.

In particular, when a string literal occur as first argument to
Printf.printf (your example [2]), its expected type is ('a,
out_channel, unit) format and thus the type-checker types it as a
format literal. In other contexts, such as your example [1] above,
there is no expected type and the literal is therefore typed as a
string.

However, you can force the correct behavior with a type constraint:

        let s = ("%f" : ('a, 'b, 'c) format) in Printf.printf s 10.5;;

You can actually go quite far this way, and use formats as first-class
values (pass them as arguments to functions, etc) -- all in a
type-safe way. Just remember to put a type constraint around format
literals if the context does not already expect a format type.

- Xavier Leroy






^ permalink raw reply	[flat|nested] 3+ messages in thread

* string variables in Printf.* calls: Bug, or lack of understanding?
@ 1997-02-13 18:31 T. Kurt Bond
  1997-02-18 16:39 ` Xavier Leroy
  0 siblings, 1 reply; 3+ messages in thread
From: T. Kurt Bond @ 1997-02-13 18:31 UTC (permalink / raw)
  To: caml-list; +Cc: tkb

Hello,

[I apologize for the lack of a French version of this message.]

I recently observed the following while runing Objective Caml under
Windows NT and UnixWare 1.1:

	    Objective Caml version 1.03

[1] # let s = "%f" in Printf.printf s 10.5;;
    Characters 30-31:
    This expression has type string but is here used with type
      ('a, out_channel, unit) format

[2] # Printf.printf "%f" 10.5;;
    10.500000- : unit = ()

I don't understand why the variable s, which is bound to a string value,
causes the error in statement 1, while using a literal string in
statement 2 works as expected.  Can anyone explain?  Or is this a bug?

-- 
T. Kurt Bond, Thomas.K.Bond@cpmx.saic.com






^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1997-02-25 12:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-02-24 20:40 string variables in Printf.* calls: Bug, or lack of understanding? Valentin Bonnard
  -- strict thread matches above, loose matches on Subject: below --
1997-02-13 18:31 T. Kurt Bond
1997-02-18 16:39 ` Xavier Leroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).