- Haskell-Cafe - Haskell.org

Re: syntax...(strings/interpolation/here docs)
by cwitty＠newtonlabs.com 17 Feb '02

17 Feb '02

"Claus Reinke" <claus.reinke(a)talk21.com> writes: > Haskell definitely supports abstraction and composition, so we can > factor out application aspects (not just text) that need localisation, > and link them (dynamically?) with the main parts of our applications. > Some systematic approach would be useful, but apart from keeping > track of the issues raised in the standards committees, I don't see > why Haskellers should limit themselves to "the" standard way of > patching C#/Java apps with translated text fragments. I think there is a good reason to use standard localisation methods; it makes it cheaper/more likely to happen. It sounds like you're advocating localisation methods which would require the translators to know Haskell; this would make hiring translators more expensive (for a commercial proposition) or significantly reduce your pool of volunteers (if you rely on volunteer translators). Carl Witty

1 0

add something to a list
by christophe certain 17 Feb '02

17 Feb '02

Hi, I'm a poor lonesome newbie in Haskell world, and I would like to add a string typed on the prompt to a list of strings which is already defined. It would look like something like : type Path = [String] currentPath::Path currentPath = [] getpiece ::IO String getpiece = do c <-getLine return c putpiece:: String->Path putpiece a = a:currentPath and then I could combine the two functions, but obviously it doesn't work. I dare understand that it's impossible isn't it ? Maybe the only way is to create a new [String] each time I want to add a new string ? No ? Christophe Certain

5 5

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