[Haskell-cafe] 'data' syntax - a suggestion
I have often found myself wishing for a small extension to the syntax of Haskell 'data' declarations. It goes like this: data as usual = as usual | ... | as usual +++where type tvar = type type tvar = type ... deriving as usual Even something like binary search trees would, to me, be clearer as data BST key val = Empty | Fork key val bst bst where type bst = BST key val because this establishes an *essential* identity between the 3rd and 4th Fork argument types, rather than an accidental identity. I can't set this up using 'type' outside the 'data' declaration, because it has to refer to the type arguments of BST. Semantically, this is just an abbreviation mechanism with no consequences of any kind outside the 'data' declaration itself. The only point would be to make reading and writing 'data' declarations easier, especially large ones. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.
On 26 Sep 2007, at 7:05 pm, Johan Tibell wrote: If UTF-16 is what's used by everyone else (how about Java? Python?) I think that's a strong reason to use it. I don't know Unicode well enough to say otherwise. Java uses 16-bit variables to hold characters. This is SOLELY for historical reasons, not because it is a good choice. The history is a bit funny: the ISO 10646 group were working away defining a 31-bit character set, and the industry screamed blue murder about how this was going to ruin the economy, bring back the Dark Ages, c, and promptly set up the Unicode consortium to define a 16-bit character set that could do the same job. Early versions of Unicode had only about 30 000 characters, after heroic (and not entirely appreciated) efforts at unifiying Chinese characters as used in China with those used in Japan and those used in Korea. They also lumbered themselves (so that they would have a fighting chance of getting Unicode adopted) with a round trip conversion policy, namely that it should be possible to take characters using ANY current encoding standard, convert them to Unicode, and then convert back to the original encoding with no loss of information. This led to failure of unification: there are two versions of Å (one for ordinary use, one for Angstroms), two versions of mu (one for Greek, one for micron), three complete copies of ASCII, c). However, 16 bits really is not enough. Here's a table from http://www.unicode.org/versions/Unicode5.0.0/ Graphic 98,884 Format 140 Control 65 Private Use 137,468 Surrogate 2,048 Noncharacter 66 Reserved875,441 Excluding Private Use and Reserved, I make that 101,203 currently defined codes. That's nearly 1.5* the number that would fit in 16 bits. Java has had to deal with this, don't think it hasn't. For example, where Java had one set of functions referring to characters in strings by position, it now has two complete sets: one to use *which 16-bit code* (which is fast) and one to use *which actual Unicode character* (which is slow). The key point is that the second set is *always* slow even when there are no characters outside the basic multilingual plane. One Smalltalk system I sometimes use has three complete string implementations (all characters fit in a byte, all characters fit in 16 bits, some characters require more) and dynamically switches from narrow strings to wide strings behind your back. In a language with read-only strings, that makes a lot of sense; it's just a pity Smalltalk isn't one. If you want to minimize conversion effort when talking to the operating system, files, and other programs, UTF-8 is probably the way to go. (That's on Unix. For Windows it might be different.) If you want to minimize the effort of recognising character boundaries while processing strings, 32-bit characters are the way to go. If you want to be able to index into a string efficiently, they are the *only* way to go. Solaris bit the bullet many years ago; Sun C compilers jumped straight from 8-bit wchar_t to 32_bit without ever stopping at 16. 16-bit characters *used* to be a reasonable compromise, but aren't any longer. Unicode keeps on growing. There were 1,349 new characters from Unicode 4.1 to Unicode 5.0 (IIRC). There are lots more scripts in the pipeline. (What the heck _is_ Tangut, anyway?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote: UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Good point. Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Wed, Sep 26, 2007 at 11:25:30AM +0100, Tony Finch wrote: On Wed, 26 Sep 2007, Aaron Denney wrote: It's true that time-wise there are definite issues in finding character boundaries. UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On 2007-09-27, Ross Paterson [EMAIL PROTECTED] wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). You'll never want to combine combining characters or vice-versa? Never want to figure out how much screen space a sequence will take? It _is_ an issue. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Thu, Sep 27, 2007 at 07:26:07AM +, Aaron Denney wrote: On 2007-09-27, Ross Paterson [EMAIL PROTECTED] wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). You'll never want to combine combining characters or vice-versa? Never want to figure out how much screen space a sequence will take? It _is_ an issue. It's an issue for a higher layer, not for a compact String representation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Thu, Sep 27, 2007 at 06:39:24AM +, Aaron Denney wrote: On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. You could get rapid seeks by ignoring the UTFs and representing strings as sequences of chunks, where each chunk is uniformly 8-bit, 16-bit or 32-bit as required to cover the characters it contains. Hardly anyone would need 32-bit chunks (and some of us would need only the 8-bit ones). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] distghc possible?
hi, i am a newbie in haskell. i have read about the tool distcc, http://distcc.samba.org/. so i was wondering, does something like this already exist for haskell? would it be possible to implement a similar tool based on ghc for haskell or does this not make sense as a haskell program has to be compiled all in one go? how are haskell programs compiled? it would be great if someone would have some suggestions on this. walter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.
On 9/27/07, ok [EMAIL PROTECTED] wrote: (What the heck _is_ Tangut, anyway?) http://en.wikipedia.org/wiki/Tangut_language Juanma ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On 2007-09-27, Ross Paterson [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 07:26:07AM +, Aaron Denney wrote: On 2007-09-27, Ross Paterson [EMAIL PROTECTED] wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). You'll never want to combine combining characters or vice-versa? Never want to figure out how much screen space a sequence will take? It _is_ an issue. It's an issue for a higher layer, not for a compact String representation. Yes, and no. It's not something the lower layer should be doing, but enabling the higher layers to do so efficiently is a concern. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] distghc possible?
i am a newbie in haskell. i have read about the tool distcc, http://distcc.samba.org/. so i was wondering, does something like this already exist for haskell? would it be possible to implement a similar tool based on ghc for haskell or does this not make sense as a haskell program has to be compiled all in one go? how are haskell programs compiled? it would be great if someone would have some suggestions on this. It seems possible and you can use ghc as a compiler on each machine from the compilation farm. I think distcc can be accommodated to do it. -- vir http://vir.comtv.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
On 9/27/07, ok [EMAIL PROTECTED] wrote: I have often found myself wishing for a small extension to the syntax of Haskell 'data' declarations. It goes like this: ['where' clause to allow locally defined names in type declarations] Nice. Quite a few times I've found myself declaring type synonyms for this reason, but you end up polluting the global namespace. +1 vote. -- Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
Thomas Conway writes: On 9/27/07, ok [EMAIL PROTECTED] wrote: I have often found myself wishing for a small extension to the syntax of Haskell 'data' declarations. It goes like this: ['where' clause to allow locally defined names in type declarations] Nice. Quite a few times I've found myself declaring type synonyms for this reason, but you end up polluting the global namespace. +1 vote. Data with where? You haven't heard about GADTs? http://en.wikibooks.org/wiki/Haskell/GADT http://www.haskell.org/haskellwiki/Generalised_algebraic_datatype Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote: UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Good point. Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. And in [Char] for all these years, yet I don't hear people complaining. Most string processing is linear and does not need random access to characters. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unsafePerformIO: are we safe?
Chaddaï Fouché wrote: 2007/9/26, Adrian Hey [EMAIL PROTECTED]: Chaddaï Fouché wrote: There can't be alternatives, unsafeIO throw by the window most guarantee that Haskell can give you and you have to provide them yourself (with a proof of this part of your program), but it's inherent to the nature of the beast, it's what it do ! What about .. http://www.haskell.org/haskellwiki/Top_level_mutable_state This as unsafe a use of unsafePerformIO as you'll ever find, but necessary for real IO libs. I'm not arguing that there aren't specific current usage of unsafePerformIO that could be better formalized (there are), I'm saying that you can't design an alternative to unsafePerformIO which cover all its applications but stay safer. What we can do with unsafePerformIO is inherently unsafe, even though you can obtain safe results with it (and in some of those use-case, a restricted version of unsafePerformIO could be used and would be safer). In your original post you appear to be making the usual argument about proof obligations and the possibility that unsafePerformIO can be used safely, despite the name (and should only be used this way). I was simply pointing out that there is at least one common use of unsafePerformIO for which this isn't possible (and there is currently no safe alternative). Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
2007/9/27, Duncan Coutts [EMAIL PROTECTED]: Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. And in [Char] for all these years, yet I don't hear people complaining. Most string processing is linear and does not need random access to characters. Well, if you never heard anyone complaining about [Char] and never had any problem with it's slowness, you're probably not in a field where the efficiency of a Unicode library is really a concern, that's for sure. (I know that the _main_ problem with [Char] wasn't random access, but you must admit [Char] isn't really a good example to speak about efficiency problems) -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
On 9/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thomas Conway writes: On 9/27/07, ok [EMAIL PROTECTED] wrote: I have often found myself wishing for a small extension to the syntax of Haskell 'data' declarations. It goes like this: ['where' clause to allow locally defined names in type declarations] Nice. Quite a few times I've found myself declaring type synonyms for this reason, but you end up polluting the global namespace. +1 vote. Data with where? You haven't heard about GADTs? I think that you haven't read the question carefully, because where in GADTs is simply a syntactic sugar. However, this seems to be available already with GADTs and type equality constraints: data BST key val where Empty :: BST key val Fork:: (bst ~ BST key val) = key - val - bst - bst - BST key val It's a pity you can't use bst (or a type synonym) instead of the last BST key val. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
Well, if you never heard anyone complaining about [Char] and never had any problem with it's slowness, you're probably not in a field where the efficiency of a Unicode library is really a concern, that's for sure. (I know that the _main_ problem with [Char] wasn't random access, but you must admit [Char] isn't really a good example to speak about efficiency problems) I have problems with [Char] and use ByteString instead but that forces me to keep track of the encoding myself and hence UnicodeString. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] isWHNF :: a - IO Bool ?
Hi, Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x)-- True putStrLn . show (isWHNF (Just undefined)) -- True If not, would it be hard/easy/possible to implement on-top-of or using GHC? I'm happy (if it's possible) to have a stab at implementing it myself, so any pointers to right directions would be helpful. I'm thinking it could be useful to allow creation of sparse-check [1] like libraries without needing a separate logic encoding, or things along those lines / in that area. Cheers, Tris [1] http://www-users.cs.york.ac.uk/~mfn/sparsecheck/index.html#lim -- Tristan Allwood PhD Student Department of Computing Imperial College London ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] isWHNF :: a - IO Bool ?
Hi Tristan, I've implemented it for earlier versions of GHC, by calling some C code which then peeps at the internal representation of a value. From memory, I needed to pass a stable pointer to the value to the C code, so that it can be polymorphic, without having to make it a primitive in GHC. Have a look at the reify code on this page: http://www.cs.mu.oz.au/ ~bjpop/code.html - its more than what you want, but you can trim it down easily. Let me know if you get stuck. The internal representation in GHC tends to change between releases, so it might need a bit of polishing up. Cheers, Bernie. On 27/09/2007, at 10:07 PM, Tristan Allwood wrote: Hi, Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x)-- True putStrLn . show (isWHNF (Just undefined)) -- True If not, would it be hard/easy/possible to implement on-top-of or using GHC? I'm happy (if it's possible) to have a stab at implementing it myself, so any pointers to right directions would be helpful. I'm thinking it could be useful to allow creation of sparse-check [1] like libraries without needing a separate logic encoding, or things along those lines / in that area. Cheers, Tris [1] http://www-users.cs.york.ac.uk/~mfn/sparsecheck/index.html#lim -- Tristan Allwood PhD Student Department of Computing Imperial College London ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
Tomasz Zielonka wrote: On 9/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thomas Conway writes: On 9/27/07, ok [EMAIL PROTECTED] wrote: I have often found myself wishing for a small extension to the syntax of Haskell 'data' declarations. It goes like this: ['where' clause to allow locally defined names in type declarations] Nice. Quite a few times I've found myself declaring type synonyms for this reason, but you end up polluting the global namespace. +1 vote. Data with where? You haven't heard about GADTs? I think that you haven't read the question carefully, because where in GADTs is simply a syntactic sugar. However, this seems to be available already with GADTs and type equality constraints: data BST key val where Empty :: BST key val Fork:: (bst ~ BST key val) = key - val - bst - bst - BST key val It's a pity you can't use bst (or a type synonym) instead of the last BST key val. Indeed. GADT syntax looks like a type signature (except for strictness annotations, which presently aren't part of function syntax!) but apparently the (-)s and result-type aren't type-signature, because type-synonyms can't be used for them. I tried. (because there were several GADT constructors with slightly different signatures, so I made a type-synonym with an argument to try to shorten them). It seems a pity to me too. Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] isWHNF :: a - IO Bool ?
Actually, in 6.8 we can build isWHNF on top of the GHC-API. First, you need to import the ghc package: ghci -package ghc GHCi, version 6.7: http://www.haskell.org/ghc/ :? for help Then, you can define the isWHNF function as follows: Prelude :m +RtClosureInspect Prelude RtClosureInspect let isWHNF = fmap (isConstr . tipe) . getClosureData Prelude RtClosureInspect :t isWHNF isWHNF :: a - IO Bool What the code above does is to inspect the info table associated to the value given, and check if the closure is a Constructor closure, i.e. in WHNF. We can put it to test now: Prelude RtClosureInspect let a = [1..10] Prelude RtClosureInspect isWHNF a False Prelude RtClosureInspect seq a () () Prelude RtClosureInspect isWHNF a True As a bonus because this code is included in GHC itself it should stay in sync with any changes in the GHC internal representations. Cheers pepe On 27/09/2007, at 14:51, Bernie Pope wrote: Hi Tristan, I've implemented it for earlier versions of GHC, by calling some C code which then peeps at the internal representation of a value. From memory, I needed to pass a stable pointer to the value to the C code, so that it can be polymorphic, without having to make it a primitive in GHC. Have a look at the reify code on this page: http:// www.cs.mu.oz.au/~bjpop/code.html - its more than what you want, but you can trim it down easily. Let me know if you get stuck. The internal representation in GHC tends to change between releases, so it might need a bit of polishing up. Cheers, Bernie. On 27/09/2007, at 10:07 PM, Tristan Allwood wrote: Hi, Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x)-- True putStrLn . show (isWHNF (Just undefined)) -- True If not, would it be hard/easy/possible to implement on-top-of or using GHC? I'm happy (if it's possible) to have a stab at implementing it myself, so any pointers to right directions would be helpful. I'm thinking it could be useful to allow creation of sparse-check [1] like libraries without needing a separate logic encoding, or things along those lines / in that area. Cheers, Tris [1] http://www-users.cs.york.ac.uk/~mfn/sparsecheck/index.html#lim -- Tristan Allwood PhD Student Department of Computing Imperial College London ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round
Sam Hughes wrote: Brian Hulley wrote: ... For example, with the prefix definition of a function with multiple clauses, the function name at the start of each clause is already lined up since it must appear at the margin of the current layout block ... Or you could have everything be backwards, and use an editor that right aligns things. (a - b) - [a] - [b] :: map [] = [] _ map x f : xs f map = (x:xs) f map There is still a reversal here between the order of arguments in the type signature and the order in the clauses. Henning Thielemann wrote: Curried functions like f :: a - b - c suggest a swapped order of arguments for (-), since 'f' must be called this way b a f Maybe it should be f :: c - b - a Which would fix this reversal. However there are 2 other kinds of reversal with postfix notation: 1) Declarations start with a keyword followed by some content whereas function definitions start with the args followed by the function name 2) Special constructs like case or let have to start with the keyword (so the parser knows what kind of thing it is supposed to parse next and so that the editor knows how to highlight what the user is typing before the user has finished typing the whole construct), again making a reversal between built-in constructs and constructs you can define using higher order functions (eg consider if as a user-defined construct in a postfix language) I've come to the conclusion that whereas postfix notation is extremely neat for simple stack-based languages like Forth and PostScript it would not play well with languages which have a structured syntax since structured syntax + left to right reading order implies each syntactic element must start with a head followed by content appropriate to that element, or else recursive descent parsing and/or as-you-type grammatical highlighting would be impossible, and therefore in terms of function application, the head must of course be the function itself hence Prefix is the only solution. Jonathan's comparison to natural languages made me think of it this way: x `plus` y === [Subject] [Verb] [Object] x .plus(y) === [Subject] [Verb Object] plus y x === [Verb Object] [Subject] plus x y === [Verb Subject] [Object] which illustrates why infix notation feels natural (corresponds to SVO in English etc), why OOP notation feels natural, why prefix notation is natural for a functional language (since we are interested primarily in the transformation not the things being transformed hence we put [VO] first), and why the desuraging of infix in Haskell/ML is quite simply just wrong, since the object is now separated from the verb. ok wrote: Binary operators have two arguments. That's why sections are needed. What's wrong with just using (flip)? I am a bear of very little brain, and I would find it VERY confusing if the order of arguments in an operator application did not match the order of arguments in a function call. I can live with x @ y = (op @)(x, y)(* SML *) x @ y = (@) x y-- Haskell but making the orders different would guarantee that I would *always* be in a muddle about which argument was which. Living with inconvenient argument orders is vastly easier than with inconsistent ones. If you inwardly parse x @ y as [x] [@ y] then the prefix notation is naturally formed just by putting the specialized verb before the subject instead of after it ie [@ y] [x]. Therefore I think this desugaring, though different from the usual one, would seem natural as soon as the reason for it was understood (of course, only if you agree with the reason ;-) ), and the great advantage of it is that we could write library functions without having to decide in advance whether or not they should be used with infix sugar. (Regarding Henning's point about ((-) a) being needed for Reader monads we could define type Fun a b = a - b and then use (Fun a)) In any case, thanks to all who replied. I've found the discussion very illuminating and it's certainly helped a lot to clarify the issues for me, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] isWHNF :: a - IO Bool ?
On Sep 27, 2007, at 9:14 AM, Pepe Iborra wrote: Actually, in 6.8 we can build isWHNF on top of the GHC-API. First, you need to import the ghc package: ghci -package ghc GHCi, version 6.7: http://www.haskell.org/ghc/ :? for help Then, you can define the isWHNF function as follows: Prelude :m +RtClosureInspect Prelude RtClosureInspect let isWHNF = fmap (isConstr . tipe) . getClosureData Prelude RtClosureInspect :t isWHNF isWHNF :: a - IO Bool What the code above does is to inspect the info table associated to the value given, and check if the closure is a Constructor closure, i.e. in WHNF. Very cool. This is much nicer than when I asked much the same question a few years back (and I can think of all sorts of interesting things I can learn from the interface in that module). But what about indirection chasing? Surely we want isWHNF to return True if we have an indirection to a WHNF. Possibly one wants something a bit like this (untested, and rather depends on GHC's indirection semantics): removingIndirections :: (forall c . c - IO b) - a - IO b removingIndirections k a = do closureData - getClosureData a if isConstr (tipe closureData) then removingIndirections (ptrs closureData ! 0) else k a simpleIsWHNF :: a - IO Boolean simpleIsWHNF = fmap (isConstr . tipe) . getClosureData isWHNF = removingIndirections simpleIsWHNF -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] isWHNF :: a - IO Bool ?
Very cool. This is much nicer than when I asked much the same question a few years back (and I can think of all sorts of interesting things I can learn from the interface in that module). But what about indirection chasing? Surely we want isWHNF to return True if we have an indirection to a WHNF. Possibly one wants something a bit like this (untested, and rather depends on GHC's indirection semantics): removingIndirections :: (forall c . c - IO b) - a - IO b removingIndirections k a = do closureData - getClosureData a if isConstr (tipe closureData) then removingIndirections (ptrs closureData ! 0) else k a simpleIsWHNF :: a - IO Boolean simpleIsWHNF = fmap (isConstr . tipe) . getClosureData isWHNF = removingIndirections simpleIsWHNF Very true, isWHNF needs to follow indirections indeed. To decide whether to recurse, you probably intended to test for Indirections and not for Constructors: removingIndirections :: (forall c . c - IO b) - a - IO b removingIndirections k a = do closureData - getClosureData a if isIndirection (tipe closureData) then removingIndirections (ptrs closureData ! 0) else k a Thanks, pepe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: isWHNF :: a - IO Bool ?
Tristan Allwood wrote: Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x)-- True putStrLn . show (isWHNF (Just undefined)) -- True Note that this function is not referentially transparent since isWHNF 2 = True but isWHNF (1+1) = False although 1+1 = 2. In other words, it messes up the language semantics (extensional equality) which is bad. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: isWHNF :: a - IO Bool ?
On Thu, Sep 27, 2007 at 05:31:51PM +0200, apfelmus wrote: Tristan Allwood wrote: Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x) -- True putStrLn . show (isWHNF (Just undefined)) -- True Note that this function is not referentially transparent since isWHNF 2 = True but isWHNF (1+1) = False although 1+1 = 2. In other words, it messes up the language semantics (extensional equality) which is bad. Indeed. Does it still mess up with the result in IO Bool (as was my intent)? Ah, I do realise my example use case above needs some ='s inserting into it which may have led to some confusion. Tris -- Tristan Allwood PhD Student Department of Computing Imperial College London ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: isWHNF :: a - IO Bool ?
apfelmus [EMAIL PROTECTED] writes: Tristan Allwood wrote: Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x)-- True putStrLn . show (isWHNF (Just undefined)) -- True Note that this function is not referentially transparent since isWHNF 2 = True but isWHNF (1+1) = False although 1+1 = 2. In other words, it messes up the language semantics (extensional equality) which is bad. Isn't it OK if it's a - IO Bool ? (Admittedly, the test example above is wrong in that case). -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: isWHNF :: a - IO Bool ?
On Thu, 2007-09-27 at 16:57 +0100, Tristan Allwood wrote: On Thu, Sep 27, 2007 at 05:31:51PM +0200, apfelmus wrote: Tristan Allwood wrote: Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool let x = (map succ [0..]) in do putStrLn . show (isWHNF x)-- False putStrLn . show . head $ x putStrLn . show (isWHNF x) -- True putStrLn . show (isWHNF (Just undefined)) -- True Note that this function is not referentially transparent since isWHNF 2 = True but isWHNF (1+1) = False although 1+1 = 2. In other words, it messes up the language semantics (extensional equality) which is bad. Indeed. Does it still mess up with the result in IO Bool (as was my intent)? In IO this should be fine, as IO is explicitly a non-determinism monad (along with everything else). jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data types and field labels and Show
I am trying to print the data from a data type and also get the field
values. How would I reference those values if I am declaring a Show function.
I should probably use a class for this, but so far it is working.
I have something along the lines of this.
data SimplePlayer = SimplePlayer {
shape :: MechShape,
angle :: GLfloat,
posX :: GLfloat,
posY :: GLfloat
}
and then to use Show, I was declaring this.
instance Show SimplePlayer where
show a = Simple posX [ ++ show a{posX} ++ ]
Of course, this didn't compile.
How should I change this code to get the field label values of the type.
Tests/GLTests.hs:20:42: parse error on input `}'
--
Berlin Brown
[berlin dot brown at gmail dot com]
http://botspiritcompany.com/botlist/?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data types and field labels and Show
On Sep 27, 2007, at 14:14 , bbrown wrote:
instance Show SimplePlayer where
show a = Simple posX [ ++ show a{posX} ++ ]
instance Show SimplePlayer where
show a = Simple posX [ ++ show (posX a) ++ ]
You might also want to consider deriving(Show).
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Thu, 27 Sep 2007, Ross Paterson wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). I dislike referring to unicode code points as characters because that tends to imply a lot of invalid simplifications. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data types and field labels and Show
bbrown:
I am trying to print the data from a data type and also get the field
values. How would I reference those values if I am declaring a Show function.
I should probably use a class for this, but so far it is working.
I have something along the lines of this.
data SimplePlayer = SimplePlayer {
shape :: MechShape,
angle :: GLfloat,
posX :: GLfloat,
posY :: GLfloat
}
and then to use Show, I was declaring this.
instance Show SimplePlayer where
show a = Simple posX [ ++ show a{posX} ++ ]
Of course, this didn't compile.
How should I change this code to get the field label values of the type.
Tests/GLTests.hs:20:42: parse error on input `}'
Just derive Show. Types with records will be printed with their labels.
You can then also derive Read, and get serialisation for free.
data SimplePlayer = SimplePlayer
{ shape :: MechShape
, angle :: GLfloat
, posX :: GLfloat
, posY :: GLfloat }
deriving (Read,Show)
*M show $ SimplePlayer square pi 1.0 (exp 1)
SimplePlayer {shape = \square\
, angle = 3.1415927
, posX = 1.0
, posY = 2.7182817}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data types and field labels and Show
On Thu, 27 Sep 2007 11:41:00 -0700, Don Stewart wrote
bbrown:
I am trying to print the data from a data type and also get the field
values. How would I reference those values if I am declaring a Show
function.
I should probably use a class for this, but so far it is working.
I have something along the lines of this.
data SimplePlayer = SimplePlayer {
shape :: MechShape,
angle :: GLfloat,
posX :: GLfloat,
posY :: GLfloat
}
and then to use Show, I was declaring this.
instance Show SimplePlayer where
show a = Simple posX [ ++ show a{posX} ++ ]
Of course, this didn't compile.
How should I change this code to get the field label values of the type.
Tests/GLTests.hs:20:42: parse error on input `}'
Just derive Show. Types with records will be printed with their labels.
You can then also derive Read, and get serialisation for free.
data SimplePlayer = SimplePlayer
{ shape :: MechShape
, angle :: GLfloat
, posX :: GLfloat
, posY :: GLfloat }
deriving (Read,Show)
*M show $ SimplePlayer square pi 1.0 (exp 1)
SimplePlayer {shape = \square\
, angle = 3.1415927
, posX = 1.0
, posY = 2.7182817}
I did this too:
instance Show SimplePlayer where
show simpleEntity = Simple posX [ ++ show (posX simpleEntity) ++
] posY [ ++ show (posY
simpleEntity) ++ ]
--
Berlin Brown
[berlin dot brown at gmail dot com]
http://botspiritcompany.com/botlist/?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
In message [EMAIL PROTECTED] Tony Finch [EMAIL PROTECTED] writes: On Thu, 27 Sep 2007, Ross Paterson wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). I dislike referring to unicode code points as characters because that tends to imply a lot of invalid simplifications. Just to be pedantic, Ross did say Char not character. A Char is defined in the Haskell report as a Unicode code point. As you say, that does not directly correspond to what many people think of as a character due to combining characters etc. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On 2007-09-27, Aaron Denney [EMAIL PROTECTED] wrote: On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote: UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Good point. Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. Speaking as someone who has done a lot of Unicode implementation, I would say UTF-16 represents the best time/space tradeoff for an internal representation. As I mentioned, it's what's used in Windows, Mac OS X, ICU, and Java. I guess why I'm being something of a pain-in-the-ass here, is that I want to use your Unicode implementation expertise to know what these time/space tradeoffs are. Are there any algorithmic asymptotic complexity differences, or all these all constant factors? The constant factors depend on projected workload. And are these actually tradeoffs, except between UTF-32 (which uses native wordsizes on 32-bit platforms) and the other two? Smaller space means smaller cache footprint, which can dominate. Simplicity of algorithms is also a concern. Validating a byte sequence as UTF-8 is harder than validating a sequence of 16-bit values as UTF-16. (I'd also like to see a reference to the Mac OS X encoding. I know that the filesystem interface is UTF-8 (decomposed a certain a way). Is it just that UTF-16 is a common application choice, or is there some common framework or library that uses that?) -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
[EMAIL PROTECTED] wrote: Data with where? You haven't heard about GADTs? To avoid clashing with GADT's where, I propose to rename ok's keyword to wherein, or wheretype, or something data B k v = E | F b b wherein type b = B k v data B k v = E | F b b wheretype b = B k v (I also propose that ok should not just take an existing unrelated thread like Unicode string library, click reply, and herein talk about a new topic; but rather, should take the necessary extra effort to start a new thread altogether.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Opengl and Haskell GLdouble/GLfloat vs. Double/Float
I am going to be doing a lot of opengl stuff in haskell and so far one thing has irked me. Why does haskell keep the GLFloat and GL types and not just the Haskell types. -- Berlin Brown [berlin dot brown at gmail dot com] http://botspiritcompany.com/botlist/? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On 2007-09-27, Duncan Coutts [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote: UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Good point. Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. And in [Char] for all these years, yet I don't hear people complaining. Most string processing is linear and does not need random access to characters. Yeah. I'm saying the differences between them are going to be in the constant factors, and that these constant factors will differ between workloads. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Praise for xmonad :-)
Seems xmonad is feeling the love. The attached mail turned up on the debian-user mailing list. It's high time xmonad gets packaged for Debian! /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus ---BeginMessage--- Javier Vasquez [EMAIL PROTECTED] writes: Don't know about windowMaker, but you might try: fluxbox icewm pekwm fvwm2 You might find some pretty light, and some besides offering lots of fun and good looking features... I use fluxbox and a machine with 512M main, and 64M ati-rage is performing pretty well... I know my choices may seem rather extreme by some, but if one is really seeking a lightweight wm I would suggest adding xmonad (with dzen2) to the above list. I have tried many small tools in this area, including ratpoison, ion3, and stumpwm, and xmonad is easily the fastest and has the smallest memory footprint I have found yet. As I have no experience with haskell compiling it was something of a learning experience, but it really wasn't too bad and has been more than worth it. It does just about everything I ever liked in ion3 (the next smallest IMHO), and all without Tuomo! :-) Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---End Message--- signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: isWHNF :: a - IO Bool ?
Tristan Allwood wrote: Does anyone know if there is a function that tells you if a haskell value has been forced or not? e.g. isWHNF :: a - IO Bool apfelmus wrote: Note that this function [isWHNF :: a - Bool] is not referentially transparent Indeed. Does it still mess up with the result in IO Bool (as was my intent)? It depends, but I think yes. I mean, given extensional equality, isWHNF 2 isWHNF (1+1) still have to be the same IO actions, in the sense that there cannot be a guarantee that the first always returns True during execution without the second returning always True , too. That is, you may not depend on such a property for proving that your program is correct, although you may use it for performance (memory time) characteristics (I don't know how you would use isWHNF to do /that/, but it's a hypothetical possibility). In other words, if your program output is correct with a fake nondeterministic replacement like isWHNF x = do b' - getMemoizedValueFor x if b' then return True else do b - randomIO when b $ setMemoizedValueFor x True return b then it's safe, otherwise it's not. But similarly to a memoization function implemented with unsafePerformIO memoize :: Ord a = (a - b) - (a - b) you may well use the not so nondeterministic property of isWHNF to achieve a time space improvement. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Praise for xmonad :-)
Nice spot, Magnus. We at xmonad.org aim to please :) People might be also interested in a bit of an experience report on developing xmonad (and running an open source Haskell project) I gave at Galois a couple of weeks ago: http://galois.com/~dons/talks/xmonad-galois-0907.pdf Finally, while we're here, an xmonad talk and demo will be happening at the Haskell Workshop next week in Freiburg, and there's bound to be some xmonad hacking/install fest during the Hackathon too: http://www.haskell.org/haskellwiki/Hac_2007_II The talk outline: http://www.cse.unsw.edu.au/~dons/papers/haskell51d-stewart.pdf -- Don magnus: Seems xmonad is feeling the love. The attached mail turned up on the debian-user mailing list. It's high time xmonad gets packaged for Debian! /M Date: Thu, 27 Sep 2007 15:35:28 -0500 From: cothrige [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: efficiency of windows managers Javier Vasquez [EMAIL PROTECTED] writes: Don't know about windowMaker, but you might try: fluxbox icewm pekwm fvwm2 You might find some pretty light, and some besides offering lots of fun and good looking features... I use fluxbox and a machine with 512M main, and 64M ati-rage is performing pretty well... I know my choices may seem rather extreme by some, but if one is really seeking a lightweight wm I would suggest adding xmonad (with dzen2) to the above list. I have tried many small tools in this area, including ratpoison, ion3, and stumpwm, and xmonad is easily the fastest and has the smallest memory footprint I have found yet. As I have no experience with haskell compiling it was something of a learning experience, but it really wasn't too bad and has been more than worth it. It does just about everything I ever liked in ion3 (the next smallest IMHO), and all without Tuomo! :-) Patrick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Praise for xmonad :-)
Hi, Am Donnerstag, den 27.09.2007, 21:53 +0100 schrieb Magnus Therning: Seems xmonad is feeling the love. The attached mail turned up on the debian-user mailing list. It's high time xmonad gets packaged for Debian! note that there is an Intend To Package filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429226 But I wonder how to combine the idea of a binary package with the way xmonad gets configured. Greetings, Joachim -- Joachim nomeata Breitner mail: [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Key: 4743206C JID: [EMAIL PROTECTED] | http://www.joachim-breitner.de/ Debian Developer: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Praise for xmonad :-)
mail: Hi, Am Donnerstag, den 27.09.2007, 21:53 +0100 schrieb Magnus Therning: Seems xmonad is feeling the love. The attached mail turned up on the debian-user mailing list. It's high time xmonad gets packaged for Debian! note that there is an Intend To Package filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429226 But I wonder how to combine the idea of a binary package with the way xmonad gets configured. I'd just go with the defaults for now, in a binary package, with a mention to go an install it yourself if you want to edit the configuration. That, or use an extension that allows configuration via X defaults. Binary packaging is a bit of an open issue at the moment. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
On 9/27/07, Albert Y. C. Lai [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Data with where? You haven't heard about GADTs? To avoid clashing with GADT's where, I propose to rename ok's keyword to wherein, or wheretype, or something data B k v = E | F b b wherein type b = B k v data B k v = E | F b b wheretype b = B k v I'm not sure there is a clash. data B k v where ... is easily distinguished from data B k v = ... where ... -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] int to bin, bin to int
Hi intToBin :: Int - [Int] intToBin 1 = [1] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] binToInt :: [Integer] - Integer binToInt [] = 0 binToInt (x:xs) = (x*2^(length xs)) + (binToInt xs) Any comments and/or criticisms on the above definitions would be appreciated. Thanks , Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and how to load them
On Thu, Sep 27, 2007 at 06:10:37PM -0400, bbrown wrote: If I have a set of haskell code and I create a directory with the source that has the following imports. (some_dir/MyLib.hs) module MyLib where And then I want to use that set of code at the top level directory, eg: MyTest.hs import MyLib How would I compile with ghc such that it loads the code from some_dir without it having to have the module as module some_dir.MyLib. I think this is a basic packaging question but couldnt figure it out. ghc -isome_dir Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] int to bin, bin to int
prstanley: Hi intToBin :: Int - [Int] intToBin 1 = [1] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] binToInt :: [Integer] - Integer binToInt [] = 0 binToInt (x:xs) = (x*2^(length xs)) + (binToInt xs) Any comments and/or criticisms on the above definitions would be appreciated. One of my favourites is: unroll :: Integer - [Word8] unroll = unfoldr step where step 0 = Nothing step i = Just (fromIntegral i .. 1, i `shiftR` 1) roll :: [Word8] - Integer roll = foldr unstep 0 where unstep b a = a `shiftL` 1 .|. fromIntegral b -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
Thomas Conway wrote: Although Richard's proposal was simpler, I reckon it's worth discussing whether the where clause should allow normal type/data/newtype declarations, effectively introducing a new scope. There are obviously some type variable quantification and name resolution issues that should yield several conference papers. data RelaxedTree key val = Leaf Bal [(key,val)] | Node Bal [(key,RelaxedTree key val)] where data Bal = Balanced | Unbalanced Is Bal visible outside data RelaxedTree? If so, why not put it at the top level. If not, are Balanced and Unbalanced visible? If not, then there is no way to construct a RelaxedTree. If so, then you could not give a type annotation to x = Balanced. data Tree key val = Leaf key val | Node BST key val BST where type BST = Tree key val The type synonym example is much easier because it is effectively syntactic sugar, and although BST is not visible, Tree key val is. But is let allowed as well, if we want to restrict the visibility of BST to just the Node constructor? Type synomym of a type variable OK? data Tree key val = let BST = key in Leaf BST val -- perversely called BST | let BST = Tree key val in Node BST key val BST ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
On 9/28/07, David Menendez [EMAIL PROTECTED] wrote: I'm not sure there is a clash. data B k v where ... is easily distinguished from data B k v = ... where ... Indeed. Although Richard's proposal was simpler, I reckon it's worth discussing whether the where clause should allow normal type/data/newtype declarations, effectively introducing a new scope. There are obviously some type variable quantification and name resolution issues that should yield several conference papers. Here are a couple of examples: data Tree key val = Leaf key val | Node BST key val BST where type BST = Tree key val data RelaxedTree key val = Leaf Bal [(key,val)] | Node Bal [(key,RelaxedTree key val)] where data Bal = Balanced | Unbalanced -- Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Packages and how to load them
If I have a set of haskell code and I create a directory with the source that has the following imports. (some_dir/MyLib.hs) module MyLib where And then I want to use that set of code at the top level directory, eg: MyTest.hs import MyLib How would I compile with ghc such that it loads the code from some_dir without it having to have the module as module some_dir.MyLib. I think this is a basic packaging question but couldnt figure it out. -- Berlin Brown [berlin dot brown at gmail dot com] http://botspiritcompany.com/botlist/? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] int to bin, bin to int
On 9/27/07, PR Stanley [EMAIL PROTECTED] wrote: Hi intToBin :: Int - [Int] intToBin 1 = [1] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] binToInt :: [Integer] - Integer binToInt [] = 0 binToInt (x:xs) = (x*2^(length xs)) + (binToInt xs) Any comments and/or criticisms on the above definitions would be appreciated. Thanks , Paul IntToBin diverges for inputs = 0. You could get 0 for free with intToBin :: Int - [Int] intToBin 0 = [] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] And why not use [Bool] for the Bin type? Or data Bin = Zero | One Regards, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Postdoctoral Fellowship in Functional Programming
--- Iain Lane [EMAIL PROTECTED] wrote: Bryan Burgers wrote: On 9/26/07, Graham Hutton [EMAIL PROTECTED] wrote: Salary will be within the range 25,134 - 32,796 pounds per year, depending on qualifications and experience. The post is available immediately, and will be offered on a fixed-term contract for 3 years. I don't mean to diminish the seriousness of your message, but why is the salary range so exact? Couldn't you have just rounded the upper bound to 32,768 for the sake of readability? I would imagine that they come from the University's salary scales[1]. As for why the salaries on there are so exact, that's anyone's guess. [1] http://www.nottingham.ac.uk/hr/scales/r-t010807%2B.pdf I used to work for a county goverment in the USA where I started at $8.886 per hour and left at $12.998 per hour. Even multiplying by 2080 hours per annum resulted in decimal places. It was probably part of the percentage increases we received each year: somehow it made the infaamous bean counters happy... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] int to bin, bin to int
If you don't like explicit recursion (or points): intToBin = map (`mod` 2) . takeWhile (0) . iterate (`div` 2) binToInt = foldl' (\n d - n*2+d) 0 or even: binToInt = foldl' ((+).(*2)) 0 On 27/09/2007, PR Stanley [EMAIL PROTECTED] wrote: Hi intToBin :: Int - [Int] intToBin 1 = [1] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] binToInt :: [Integer] - Integer binToInt [] = 0 binToInt (x:xs) = (x*2^(length xs)) + (binToInt xs) Any comments and/or criticisms on the above definitions would be appreciated. Thanks , Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Postdoctoral Fellowship in Functional Programming
Bryan Burgers wrote: On 9/26/07, Graham Hutton [EMAIL PROTECTED] wrote: Salary will be within the range 25,134 - 32,796 pounds per year, depending on qualifications and experience. The post is available immediately, and will be offered on a fixed-term contract for 3 years. I don't mean to diminish the seriousness of your message, but why is the salary range so exact? Couldn't you have just rounded the upper bound to 32,768 for the sake of readability? Bryan I would imagine that they come from the University's salary scales[1]. As for why the salaries on there are so exact, that's anyone's guess. Iain [1] http://www.nottingham.ac.uk/hr/scales/r-t010807%2B.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'data' syntax - a suggestion
On 28 Sep 2007, at 10:01 am, Thomas Conway wrote: data Tree key val = Leaf key val | Node BST key val BST where type BST = Tree key val data RelaxedTree key val = Leaf Bal [(key,val)] | Node Bal [(key,RelaxedTree key val)] where data Bal = Balanced | Unbalanced My proposal was deliberately rather limited. My feeling was that if there is a constructor (like Balanced, Unbalanced) then I want it to belong to a module-scope type name. What I'm looking for is something that provides (1) an easily understood way of abbreviating repeated types in a data, type, or newtype declaration (2) and using them *uniformly* throughout such a declaration (which is why GADTs don't help) (3) to reduce the incidence of errors (4) and clarify the programmer's intent in much the same way as field names do (but as a complementary, not a rival technique) (5) and above all, to simplify maintenance. The thing that got me thinking about this is my continuing attempt to write a compiler (to C) for a legacy language in Haskell. I start out with a simple AST data type, adequate for testing the grammar. And then I start adding semantic information to the nodes, and suddenly I find myself adding extra fields all over the place. Now there's a paper that was mentioned about a month ago in this mailing list which basically dealt with that by splitting each type into two: roughly speaking a bit that expresses the recursion and a bit that expresses the choice structure. My feeling about that was that while it is a much more powerful and general technique, it isn't as easy to get your head around as a single level solution. Here's a trivial example. Parser-only version: newtype Var = Var String data Expr = Variable Var | Constant Int | Unary String Expr | Binary String Expr Revised version: data Var env = Var env String data Expr env = Variable (Var env) | Constant Int | Unary String (Expr env) | Binary String (Expr env) (Expr env) Now let's do Expr using my proposal: data Expr = Variable var | Constant Int | Unary String expr | Binary String expr expr where type var = Var type expr = Expr (obtained from the first parser-only version by lower-casing the type names) becoming * data Expr env = Variable var | Constant Int | Unary String expr | Binary String expr expr * where type var = Var env *type expr = Expr env To my mind it's clearer to see 'expr' repeated than '(Expr env)' repeated, as you don't have to keep checking that the argument is the same. I'm not wedded to this scheme. It's the simplest thing I can think of that will do the job. But the Haskell spirit is, if I may say so, seems to be to look for the simplest thing that can do the job at hand and a whole lot more in a principled way. What I'm looking for in a better counter-proposal is something that makes it this easy or easier to revise and extend a type. Perhaps a variation on GADTs would be the way to go. I don't know. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] int to bin, bin to int
I might be inclined to use data Bin = Zero | One (or at least type Bin = Bool) to let the type system guarantee that you'll only ever have binary digits in your [Bin], not any old integer. Using [Int] is an abstraction leak, inviting people to abuse the representation behind your back. Rodrigo Queiro wrote: If you don't like explicit recursion (or points): intToBin = map (`mod` 2) . takeWhile (0) . iterate (`div` 2) binToInt = foldl' (\n d - n*2+d) 0 or even: binToInt = foldl' ((+).(*2)) 0 On 27/09/2007, PR Stanley [EMAIL PROTECTED] wrote: Hi intToBin :: Int - [Int] intToBin 1 = [1] intToBin n = (intToBin (n`div`2)) ++ [n `mod` 2] binToInt :: [Integer] - Integer binToInt [] = 0 binToInt (x:xs) = (x*2^(length xs)) + (binToInt xs) Any comments and/or criticisms on the above definitions would be appreciated. Thanks , Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
