February 2002 - Haskell-Cafe

Re: syntax...(strings/interpolation/here docs)
by C.Reinke 15 Feb '02

15 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? Unlike my rough proposal, one should aim for a combination of (mostly) in-Haskell implementation and (some) pre-processing. As Thomas Nordin has pointed out to me in private email, Hugs (Dec 2001) already supports this (module lib/hugs/Quote.hs and flag +H). The real trick is to have the same support in all implementations.. > I don't think it is really necessary to add the feature to the language, > since you can program something very similar for yourself in user-code. It is not really necessary, but "very similar" isn't good enough for the purpose (see further down). - haven't tried with other systems, but Hugs at least has some limit on maximum token length (4000). This is a lot easier to avoid if string variable interpolation implicitly breaks up tokens. - I've tried to work with Haskell's \\-multiline strings - I don't find them useable. The extra characters at the end and start of lines make them less readable and less writeable than necessary for this kind of applications (my current workaround is to use break strings on lines, either with explicit concatenation or with lists of strings and the good old unlines to get rid of those "\n"s) - as said above, I do agree that there should be no complex language extensions for what can be done in Haskell, and Hugs' combination of Quote module and +H support gets close to that. If you have to change string quoting (to preserve formatting), you might as well throw in variable interpolation (only needs "..$(var).." -> ".."++quote var++"..", the rest is Haskell code). It is similar to what I posted, but the ``$(var) $$''-syntax is simpler, there are no overlapping instances, and there is an explicit function to trim leading whitespace instead of the extra layout rule I assumed. Here's your example, with Hugs' Quote: {- :set +H -} import Quote hereDocument v w = ``Multi-line string starts here and uses string gap delimiters. Variable names like $(a) are filled in from the bindings specified in the `with` clause, e.g. $(a) = $$a, $(b) = $$b and unused bindings pass through e.g. $(c) = $$c.'' where (a,b,c) = (v,w,"$c") After all, the purpose of here-documents is readability in programs that have to generate programs or formatted text (e.g., the popular Haskell/CGI libraries, or libraries generating XML/HTML/VRML/SVG/..). In those contexts, they are an important matter of convenience - you just write the text template you want to generate, filled in with variables. Meta-programming is difficult enough without asking for trouble (extra \ everywhere, explicit \n, by hand conversion from any type a to String, no checks of variable bindings instead of lexical scoping). The only disadvantage I've seen so far (apart from that maximum token length..) is the need to disambiguate numeric types for the overloaded quote, but that's a standard Haskell problem. Claus > Here's a sample of a single-character macro expansion within strings, > that took a couple of minutes to write. > > module Printf where > import Maybe(fromMaybe) > > hereDocument :: (Show a, Show b) => a -> b -> String > hereDocument v w = > "Multi-line string starts here\ > \ and uses string gap delimiters.\n\ > \ Variable names like $$a are filled in from the\n\ > \ bindings specified in the `with` clause,\n\ > \ e.g. $$a = $a, $$b = $b\n\ > \ and unused bindings pass through e.g. $$c = $c." > `with` [('a',show v), ('b',show w)] > > with :: String -> [(Char,String)] -> String > [] `with` env = [] > ('$':'$':cs) `with` env = '$': cs `with` env > ('$':c:cs) `with` env = s ++ cs `with` env > where s = fromMaybe ('$':c:[]) (lookup c env) > (c:cs) `with` env = c : cs `with` env

5 6

syntax across languages
by Pixel 14 Feb '02

14 Feb '02

http://merd.net/pixel/language-study/syntax-across-languages.html CHANGES: - the page has now much more entries - one can check the missing entries per language at http://merd.net/pixel/language-study/syntax-across-languages-per-language.h… (160KB) see especially the haskell one http://merd.net/pixel/language-study/syntax-across-languages-per-language.h… Contributions, suggestions and fixes are welcome. -- Pixel programming languages addict http://merd.net/pixel/language-study/

5 11

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 11 Feb '02

11 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 11 Feb '02

11 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 11 Feb '02

11 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