- Haskell-Cafe - Haskell.org

Re: Re: syntax...(strings/interpolation/here docs)
by David Feuer 13 Feb '02

13 Feb '02

> From: Joe <joe(a)culturematic.net> > Does anybody with their elbows in the > code think variable interpolation and/or > multi-line strings are good/doable ideas? Can't say I have my elbows in the code, but I think that multi-line strings could be useful. I'm not sure what I think about variable interpolation... I imagine it would make the language somewhat more difficult to parse. What would this be like, anyway? Something like "foo $(bar) baz" = "foo"++bar++"baz" ? And then you'd have to have some sort of quoting rule, for dollar signs followed by parens... I guess you'd probably want some variant that automatically applies show... > Would this be the sort of change one could make > without a lot of previous familiarity with > the implementation of Hugs/Ghc? You'd certainly need to be familiar with how to specify syntax, and how to write a parser. > It would be a *signifigant* boon to those > of us trying to get haskell into organizations > by using it as "maintainable perl/sh", and Haskell is not a "maintainable perl/sh". It is not a good language for simple shell scripts, and is not good for string processing either. Have you tried Scsh? Or Python? I don't think that supporting string hacking is a major goal for Haskell. > generally make an already delightful language > more delightful. This message has been brought to you by the letter alpha and the number pi.

2 1

Re: syntax...(strings/interpolation/here docs)
by Joe 13 Feb '02

13 Feb '02

Does anybody with their elbows in the code think variable interpolation and/or multi-line strings are good/doable ideas? Would this be the sort of change one could make without a lot of previous familiarity with the implementation of Hugs/Ghc? It would be a *signifigant* boon to those of us trying to get haskell into organizations by using it as "maintainable perl/sh", and generally make an already delightful language more delightful. -------------------- Joe Bowers http://www.culturematic.net

2 1

RE: syntax...(strings/interpolation/here docs)
by Simon Marlow 13 Feb '02

13 Feb '02

> Does anybody with their elbows in the > code think variable interpolation and/or > multi-line strings are good/doable ideas? > Would this be the sort of change one could make > without a lot of previous familiarity with > the implementation of Hugs/Ghc? > It would be a *signifigant* boon to those > of us trying to get haskell into organizations > by using it as "maintainable perl/sh", and > generally make an already delightful language > more delightful. I once wondered about translating "aaa \$bbb ccc" into "aaa " ++ show bbb ++ " ccc" (before you check, \$ isn't a valid escape sequence in Haskell 98). Of course, you could go all the way and do it properly: http://www.dcs.gla.ac.uk/~partain/haskerl/partain-1.html Cheers, Simon

1 0

RE: Eager IO function
by Simon Marlow 13 Feb '02

13 Feb '02

> > How should I modify the function below so that characters > are printed > > out as they arrive? > > > > printchar :: Handle -> IO () > > printchar handle = do c <- hGetChar handle > > putChar c > > Try using > hSetBuffering handle NoBuffering > hSetBuffering stdout NoBuffering > from the IO library, before you call printchar. If the input handle > is attached to a terminal, you may also need to adjust the terminal > emulation into `cbreak' mode, e.g. with > System.system "stty cbreak" > Don't forget to reset the terminal afterwards! GHC does the "stty cbreak" step for you, if the handle on which you set the buffering mode is a terminal. Note also that not all systems have an 'stty' command. Cheers, Simon

1 0

Eager IO function
by Tom Bevan 13 Feb '02

13 Feb '02

How should I modify the function below so that characters are printed out as they arrive? Thanks. Tom printchar :: Handle -> IO () printchar handle = do c <- hGetChar handle putChar c

2 1

RE: (no subject)
by Jay Allen 12 Feb '02

12 Feb '02

Ask yourself what the type of "head s, last s" is in the exp portion of the comprehension. In fact, it's not a valid Haskell expression, unless you convert it into a list or a tuple. What you actually want is: function seg = nub (concat([[head s, last s] | s <- seg]) -J- Jay Allen Technical Lead, DSV Internet Client "The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++." - Richard Gabriel -----Original Message----- From: Phil Haymen [mailto:phaymen@yahoo.com] Sent: Saturday, February 09, 2002 11:09 AM To: haskell-cafe(a)haskell.org Subject: (no subject) hi,I have a function, using list comprehension to pick out the head and last elements from a list of lists and output this into a list without duplicates. It doesn't work. I want to know what is the error. function :: [[Int]] -> [Int] function seg = nub (concat([head s, last s | s <- seg]) __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: syntax across languages
by C.Reinke 12 Feb '02

12 Feb '02

> > encryptionTooSimple d = > > "This encryption key is too simple (must be at least " > > ++(show (d::Integer))++ characters long)" > > - i don't like separating the string from the code for simple strings if you don't extract the string, how can it be a parameter of/variable in your application? > - do you really suggest giving this translators? You can be sure it won't > compile any more ;p actually, this version seems to come from an out-of-date editor buffer (missing quote).. it won't compile!-) <GRIPE> one thing I really don't like about Haskell is it's lacking support for HERE documents, as you'll find them in shells or in Perl. Am I the only one who's constantly bitten by this? </GRIPE> <ROUGH SUGGESTION> Something like: encryptionTooSimple :: Integer -> String encryptionTooSimple d = <<HERE; This encryption key is too simple (must be at least $d characters long) HERE with "..$var.." translated to ".."++(toString var)++".." and toString somewhat like this (just to avoid spurious quotes): class Show a => ToString a where toString :: a -> String instance Show a => ToString a where toString = show instance ToString Char where toString c = [c] instance ToString String where toString s = s </ROUGH SUGGESTION> As some of our implementers seem to be in fast-track-response mode, perhaps this has a chance of slipping in?-) Claus

2 1

Re: syntax across languages
by C.Reinke 12 Feb '02

12 Feb '02

> > I'm not sure if "iterate" counts as loop forever? > > I don't think there can be a "loop forever" construct in haskell? why not? > in OCaml, it is simply: > let loop(f) = f() ; loop(f) > and is only useful together with exceptions and side-effects. and in Haskell, it is simply: loop f = f >> loop f or, as there is little difference between control structures and other data structures, you can convert the latter into the former, using the list version of loop, called repeat: loop f = mapM_ id $ repeat f or simply: loop = foldr1 (>>) . repeat example (get ready to hit that interrupt key;-): loop (putStrLn "hi") > > I can't remember any %-based sprintf off the top of my head, but hey, > > who'd want one anyway? > > me! I've always wondered how you internationalize a program without it? > > eg: > "This encryption key is too simple (must be at least %d characters long)" > "The package %s needs to be installed. Do you want to install it?" > > (I agree you don't need the full power of sprintf for this) indeed not. you only want to factor out the strings, so that they can be collected in a single space for the translators/customizers convenience. functional abstraction allows you to just do that (then put the functions into a module per language, or collect them in tuples/records, and link or select as appropriate): encryptionTooSimple d = "This encryption key is too simple (must be at least " ++(show (d::Integer))++ characters long)" packageMissing s = "The package "++s++" needs to be installed. Do you want to install it?" but if you absolutely want printf-style formatting, Danvy's solution is very nice and simple (once someone had the idea;-): int k r x = k (r++(show (x::Integer))) -- an Integer str k r x = k (r++x) -- a String s x k r = k (r++x) -- format String fragment nl = s "\n" -- newline format p = p id "" (similar continuation-based functions for other types) Now you can try it in Hugs: Main> :t format $ s "age: " . int . s " name: " . str . nl format $ s "age: " . int . s " name: " . str . nl :: Integer -> [Char] -> [Char] Main> format ( s "age: " . int . s " name: " . str . nl ) 10 "IGS" "age: 10 name: IGS\n" See: RS-98-12 Olivier Danvy. Functional Unparsing. May 1998. 7 pp. This report supersedes the earlier report BRICS RS-98-5. Extended version of an article to appear in Journal of Functional Programming. http://www.brics.dk/RS/98/Ref/BRICS-RS-98-Ref/BRICS-RS-98-Ref.html#BRICS-RS… > i don't put any non-simple functions, the main aim is not to show how it can > be done, but what are the various names used in various languages. but it is one of the major features of functional languages that it is so easy to compose/reuse functionality! this is why Haskell doesn't need a name for everything - composing the functions can be as simple as (and more flexible than) composing the names. Claus

2 1

Re: syntax across languages
by Pixel 12 Feb '02

12 Feb '02

Patrick M Doane <patrick(a)watson.org> writes: [...] > I find sprintf to be not powerful enough for internationalization. The > specification of actual values is order dependant which may change from > language to language. not true with advanced printf's: There is one last vital consideration for output. The order of words in a sentence is different in various languages, for example, ``yellow flower'' becomes ``la flor amarilla'' en Espanbsp;nol. The differences between English and German are equally dramatic. To solve this problem, the standard printf() allows the order of the arguments to be handled in variable order in the format string. For example, if we have printf(fmt, month, date, who); we can use an fmt of %s %d is %s's birthday in English to produce ``April 26 is James's birthday'' and %3$s's geburtstag ist %2$d. %1$s in German to generate ``James's geburtstag ist 26. April.'' Notice that qualifiers like 2$ allows us to reorder the parameters to account for differing word order in different languages. (from http://www.alumni.caltech.edu/~copeland/work/i18n-b.html)

1 0

Re: efficiency question
by Jorge Adriano 11 Feb '02

11 Feb '02

On Monday 11 February 2002 02:10, Hal Daume III wrote: > So instaed of storing 1 and 2 in the list, it stores pointers to > them. The reason it does this is so that it makes it easy to generate > code for polymorhpic functions. (,) being boxed means that instead of > storing a pair of element, you're storing a pair of pointers. That means > you get worse performance because you have to chase more pointers. > > (at least that's my impression) Thanks, I knew the concept but not the name. On Sunday 10 February 2002 18:48, Kirsten Chevalier wrote: > I'd guess that it's not just that you have to apply the (,) constructor -- > it also has to do with the fact that the tuples it's constructing here are > boxed. This brings another question to my mind, isn't it toupling a standard technique used in functional programming? I'm pretty sure I've seen it focused in some papers/text books. I for one would not expect that folding the list twice would be more efficient... J.A.

1 0