Re: [Haskell-cafe] Pure Haskell Printf
On Tuesday 16 November 2004 10:37, Henning Thielemann wrote: Variable length argument lists are really a mess. Why are people so keen on them? What is the advantage over a plain list as single argument? Is vsprintf %s, your age is %s\n [John, show (10::Integer)] really too complicated? The implementation of printf in ocaml, for example, is not only type-safe, but more type safe than passing a list, because the number and type of arguments is known at compile time. V. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Pure Haskell Printf
Scott Turner wrote: On 2004 November 16 Tuesday 06:42, Jérémy Bobbio wrote: There is a probleme with ShowS though: it is not internationalizable at all. Strings like printf's or with any kind of variable substitution is required for proper internationalization / localization. Printf is not adequate for internationalization either, because word (and thus parameter) ordering may vary among languages. Note that MissingH.Printf addresses this with a feature which supports keys in format items, e.g. %(item1)s. This is what it boils down to for me. A post by Malcolm Wallace to one of the Haskell lists a few years back convinced me that: Internationalization is a killer application for printf-style format-string-based functions. I have seen approximately 32767 different proposals for printf with strong static typechecking, using anything from specialized data types to depedently-typed functions to compile-time reflection. None of these appears to be able to solve the simple problem of allowing localization (or general fiddling with the formatting) without recompiling and relinking. In that respect there will always be a place for dynamically-checked printf, and John's library really seems to be doing The Right Thing. I remain much more skeptical that there's a need for a statically-checked printf which uses format strings. ShowS and related approaches work pretty well in my experience (though it'd be nice to see standardized support for flexible number formatting). A Challenge To The Type System Hackers: Is there a way to get the best of both worlds? To do static checking on format strings when they're available, but fall back to dynamic checking when they are not? Perhaps we provide a canonical format string, or use some other sort of hackery, and then check the actual string dynamically. -Jan-Willem Maessen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure Haskell Printf
On Wed, 17 Nov 2004, Vincenzo Ciancia wrote: On Tuesday 16 November 2004 10:37, Henning Thielemann wrote: Variable length argument lists are really a mess. Why are people so keen on them? What is the advantage over a plain list as single argument? Is vsprintf %s, your age is %s\n [John, show (10::Integer)] really too complicated? The implementation of printf in ocaml, for example, is not only type-safe, but more type safe than passing a list, because the number and type of arguments is known at compile time. Can this be also achieved for extended versions implemented by OCaml users, say for printf's with more placeholder types? What about variable format strings? I assume that it is very hard to solve all these problems and I wonder if it is worth the trouble ... ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Pure Haskell Printf
On 2004-11-17, Vincenzo Ciancia [EMAIL PROTECTED] wrote: On Tuesday 16 November 2004 10:37, Henning Thielemann wrote: Variable length argument lists are really a mess. Why are people so keen on them? What is the advantage over a plain list as single argument? Is vsprintf %s, your age is %s\n [John, show (10::Integer)] really too complicated? The implementation of printf in ocaml, for example, is not only type-safe, but more type safe than passing a list, because the number and type of arguments is known at compile time. On the other hand, the OCaml printf is, unless I'm very mistaken, handled specially by the compiler. That is, the compiler looks out for format strings and converts them to the weirdo format4 things that OCaml uses. That means that one could not implement one's own printf using pure OCaml. Though a person could use camlp4, but then that's back to the same place as TH. OCaml's printf also is limited in that it can take only a string literal for the format string, and not a string in a variable. -- John ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO and State
Iavor S. Diatchki [EMAIL PROTECTED] writes: I find the argument a bit disturbing, as it seems to imply that it is OK for the compiler to produce code without any context switches at all Note that in this case if the main program doesn't explicitly block on MVars, I/O nor timeout, then finalizers will never be run and would be kept in memory despite garbage collection. So such implementation would not be able to run certain programs which create lots of finalized objects, even if almost all of them become dead soon after creation. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO and State
Marcin 'Qrczak' Kowalczyk wrote: Iavor S. Diatchki [EMAIL PROTECTED] writes: I find the argument a bit disturbing, as it seems to imply that it is OK for the compiler to produce code without any context switches at all Note that in this case if the main program doesn't explicitly block on MVars, I/O nor timeout, then finalizers will never be run and would be kept in memory despite garbage collection. So such implementation would not be able to run certain programs which create lots of finalized objects, even if almost all of them become dead soon after creation. This is little different from the situation with GC-based finalization in other languages (cf Java). This is why finalizers are generally viewed as a backstop to clean up resources which were accidentally left un-freed, rather than a universal solution to cleanup. -Jan-Willem Maessen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
