Re: [Haskell-cafe] ANN: LogFloat 0.9
wren: > > -- Announcing: logfloat 0.9.1 > > > New official release of the logfloat package for manipulating log-domain > floating numbers. This release is mainly for those who are playing with > Transfinite rather than LogFloat, but the interface changes warrant a > minor version change. And in Arch Linux http://aur.archlinux.org/packages.php?ID=18832 -- Don (come on packagers!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: LogFloat 0.9
-- Announcing: logfloat 0.9.1 New official release of the logfloat package for manipulating log-domain floating numbers. This release is mainly for those who are playing with Transfinite rather than LogFloat, but the interface changes warrant a minor version change. If you're just using the LogFloat stuff you shouldn't notice any changes except that the constructors/destructors may be a bit pickier about being used when a polymorphic return type is expected. -- Changes * John Meacham pointed out that the Num and Ord superclasses on Transfinite may be onerous due to the growing disaffection with the Prelude. The Num requirement has been lifted, and the Ord requirement has been weakened to the new PartialOrd class. * Introduced a new class for partially ordered types: PartialOrd. * The transfinite-value respecting logarithm has been moved from Data.Number.LogFloat to Data.Number.Transfinite because it's more appropriate there. (It's still reexported by Data.Number.LogFloat.) * In the continuing battle between transfinite values and Rationals, I've added a new class RealToFrac for overloading the Prelude's realToFrac function. On GHC, primitive converters are used to improve both performance and correctness. For non-GHC compilers, only a few generic instances are given. For an older discussion on this topic, see: http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html * Due to all this development on trying to solve the issues of transfinite values, the "stability" of the package has been changed from stable to provisional. -- Future Extensions * A strict version. The current lazy version will move to Data.Number.LogFloat.Lazy, and the strict version will be the standard one in Data.Number.LogFloat * A signed version in Data.Number.LogFloat.Signed * A test suite -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named field syntax
On Fri, Aug 29, 2008 at 1:59 PM, Roman Cheplyaka <[EMAIL PROTECTED]> wrote: > * Johannes Waldmann <[EMAIL PROTECTED]> [2008-08-29 > 15:39:15+0200] > > > data Test = Test Integer {b::String} > > > > positional (= unnamed) record notation is a language design error :-) > > and its use should be discouraged. - J.W. > > Polluting namespace with unneeded functions should not be encouraged > either. Consider for instance defining datatype for 3x3 matrix. > Would the absence of unnamed record notation make you more happy? > Also, if positional record notation is a design error, then is it also a design error not to require all arguments to be explicitly associated with named formal parameters at a function call site (e.g. f(x = 1, y = 2, z = 3))? > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > kzm: My program contains a bug. How ungrateful, after all I've done for it. > ___ > 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] Syntax of 'do'
On Fri, Aug 29, 2008 at 8:50 AM, David House <[EMAIL PROTECTED]> wrote: > 2008/8/29 Philip Weaver <[EMAIL PROTECTED]>: > > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the > > new definitions. This is not possible, regardless of what types you give > > (>>) and (>>=). > > Watch out for rebindable syntax: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax > Oh, I had no idea! Thanks :). > > At first reading, I thought that -XNoImplicitPrelude was required to > turn this on. But now I'm not sure: it seems that if you hide > Prelude.>>= and Prelude.return, that ought to be enough to make do > notation work with your alternative definitions. I'm not at home, so I > can't try this right now. > > -- > -David > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Syntax of 'do'
>> It sounds like you tried to redefine (>>) and >> (>>=) and make 'do' use the new definitions. >> This is not possible, regardless of what types >> you give (>>) and (>>=). > > Watch out for rebindable syntax: (...) > > At first reading, I thought that > -XNoImplicitPrelude was required to turn this > on. But now I'm not sure: (...) I wrote this test to check your sugestion. It does build with -XNoImplicitPrelude, but not without it: -- module Test where { import Prelude hiding ( ( >> ) , ( >>= ) ) ; data PseudoMonad a = PseudoMonad a ; ( >> ) = \(PseudoMonad x) (PseudoMonad _) -> PseudoMonad x ; ( >>= ) = (\(PseudoMonad a) f -> f a) :: PseudoMonad Integer -> (Integer -> PseudoMonad Integer) -> PseudoMonad Integer; plusOne n = (PseudoMonad (n + 1)) :: PseudoMonad Integer; c = (PseudoMonad 1) >> ((PseudoMonad 2) >>= (\n -> plusOne n)); d = do {(PseudoMonad 1) ; a <- (PseudoMonad 2) ; plusOne a } } -- It's interesting that the types involved in >>= etc. should still be like "t t1", that's why I had to create PseudoMonad. Using just Integer (i.e., 2 >> 3 would be valid) doesn't work, even if all operators are defined accordingly. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: vxml (validating xml lib) - proof of concept - need some guidance - bad type level performance (ghc)
Hi @ll. This shouldn't have been an announce yet.. it's more crying for help to get to know how / wether to continue :-) I had an idea: a xml generating library validating the result against a given dtd (to be used in web frameworks etc .. ) After one week of coding I got the result git clone git://mawercer.de/vxml (1) (see README) git hash as of writing : 4dc53 A minimal example looks like this (taken from test.hs): import Text.XML.Validated.TH $( dtdToTypes "dtds/xhtml1-20020801/DTD/xhtml1-strict_onefile.dtd" (XmlIds (Just "-//W3C//DTD XHTML 1.0 Strict//EN") (Just "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";) ) ) main = putStrLn $ xml $ ((html << (head << (title <<< "vxml hello world"))) << (body << (div <<< "PCDATA text" )) ) Which takes about 7 secs to compile on my (fast) 2.5 Ghz machine. Before Oleg telling me about how to use the TypeEq implementation found in HList it took several hours (switch the cabal configure flag to see experience the incredible slow TypeToNat implementation) However type checking the simple small document (2) already takes 35 seconds, duplicating the tags within the body raises compilation time to 74 seconds. (Have a look at test/XmlToQ.hs to automatically create the code generating such a given xml file (its used in run-testcases.hs) The dtd representation used is very easy to understand: (3a) shows allowed subelements of the head tag Seq = sequence Star = zero or more ... (3b) shows the list of allowed attributes for a more commonly used tag such as div the element list (3a) is 324 lines long and there are approximately 15 attributes. Use a line such as putStrLn $ xml $ debugEl div to get this view. All the work is done by class Consume st el r | st el -> r -- result is on of C,CS,R,F class Retry elType st el st' | st el -> st' st = state as given in (3a) el = child to be added (Elem Html_T) or PCDATA C = element consumed, end CS a = element consumed, continue with state a R a = retry with given state (can happen after removing a Star = ()* on a no match ) F a = no match, show failure a instance Retry elType C el C instance Retry elType (CS st) el st instance ( -- retry Consume st el r , Retry elType r el st' ) => Retry elType (R st) el st' Maybe you knowing much more about ghc internals have some more ideas how to optimize? I only came up with a) implement xml HTrue $ xmldoc -- type checking variant xml HFalse $ xmldoc -- unchecked but faster variant so you can run xml HTrue once a day only while having lunch.. ( doubt Maybe you have to take lunch two or more times on intermediate web projects .. ) b) change (A attrType) to attrType only and (Elem e) to e which does not work for the same reason as class TypeEq a b c | a b -> c instance TypeEq a a HTrue instance TypeEq a b HFalse doesn't. Of course a a will match a b as well, but the result is totally different.. So would it be possible to either tell ghc to ignore this happily taking the result of the better matching instance? Or to explicitely tell ghc when an instance matches the way it does in current implementations make it a no match if some constraints can or cannot be satisfied such as this: class TypeEq a b c | a b -> c instance TypeEq a a HTrue instance [ NoMatchOn a b -- if this can be satisfied ignore this instance ] => TypeEq a b HFalse class NoMatchOn a b instance NoMatchOn a a c) Having a reduction rule such as this: If the left side of (Or a b) returnns C (consumed) tell ghc to not evaluate the result of (Consume b element result) which must be done to see wether there is closer instance match (Is this correct ?) Of course not everything is implemented yet.. but except speed I consider it beeing quite usable. He, thanks for reading till the end. Any feedback and suggestions are appreciated. If you have any trouble contact me on irc. I've been using $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Sincerly Marc Weber (1) If you are interested and either don't have git or are not familiar using it I can send you a tarball. (2) http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US"> Example 6 - XHTML 1.0 Strict as application/xhtml+xml Example 6 - XHTML 1.0 Strict as application/xhtml+xml This document is valid XHTML 1.0 Strict served as application/xhtml+xml. This document references CSS rules contained in an external stylesheet via link. Note how the CSS rules for the background are applied in Netscape 7.x, Mozilla, Opera 7 but that Internet Explorer can not display the page at all. http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-xhtml10"; alt="Valid XHTML 1.0!" heig
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
Bryan O'Sullivan wrote: I haven't seen a coherent description of what the semantics of top-level "<-" should be, but avoidance of widespread swearing would be at the top of my list of requirements. Don't the ACIO monad properties satisfy you? Anyway, as I pointed out in my last post, if this is a problem with top level <- ACIO monad bindings it's still going to be a problem (probably much worse) with unsafePerformIO hack IO monad bindings. This problem isn't just going to go away, no matter how long it's ignored :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
Ganesh Sittampalam wrote: Will Data.Unique still work properly if a value is sent across a RPC interface? A value of type Unique you mean? This isn't possible. Data.Unique has been designed so cannot be Shown/Read or otherwise serialised/deserialised (for obvious reasons I guess). Also what if I want a thread-local variable? Well actually I would say that threads are bad concurrency model so I'm not keen on thread local state at all. Mainly because I'd like to get rid of threads, but also a few other doubts even if we keep threads. Even if you don't like them, people still use them. AFAICS this is irrelvant for the present discussions as Haskell doesn't support thread local variable thingies. If it ever does being precise about that is someone elses problem. For the time being the scope of IORefs/MVars/Chans is (and should remain) whatever process is described by main (whether or not they appear at top level). (I.E. Just making existing practice *safe*, at least in the sense that the compiler ain't gonna fcuk it up with INLINING or CSE and every one understands what is and isn't safe in ACIO) Creating new language features means defining their semantics rather more clearly than just "no inlining or cse", IMO. I wouldn't even know how to go about that to the satisfaction of purists. But "global variables" *are* being used whether or not the top level <- bindings are implemented. They're in the standard libraries! So if this stuff matters someone had better figure it out :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
I actually was more interested in the problems with the "obvious fix" for this, namely the "construct on first use" idiom: int A(int a) { static int aa = a; return aa; } int B() { return A(3); } int C() { return A(7); } int D() { if (today() == "Tuesday") B(); else C(); return a(0); } What is the value of D? Notice that this is never a problem with pure functions. The problem is that today() makes this an IO monad, and the swearing starts again. Dan Bryan O'Sullivan wrote: On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston <[EMAIL PROTECTED]> wrote: C++ faced this very issue by saying that with global data, uniqueness of initialization is guaranteed but order of evaluation is not. In C++ circles, this is referred to as the "static initialization order fiasco", and it is a frequent cause of crashes that are very difficult to debug. http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 I think it would be fair to say that C++ pushed this problem off to every user of the language. I haven't seen a coherent description of what the semantics of top-level "<-" should be, but avoidance of widespread swearing would be at the top of my list of requirements. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston <[EMAIL PROTECTED]> wrote: > C++ faced this very issue by saying that with global data, uniqueness of > initialization is guaranteed but order of evaluation is not. In C++ circles, this is referred to as the "static initialization order fiasco", and it is a frequent cause of crashes that are very difficult to debug. http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 I think it would be fair to say that C++ pushed this problem off to every user of the language. I haven't seen a coherent description of what the semantics of top-level "<-" should be, but avoidance of widespread swearing would be at the top of my list of requirements. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
C++ faced this very issue by saying that with global data, uniqueness of initialization is guaranteed but order of evaluation is not. Assuming that the global data are merely thunk wrappers over some common data source, this means that at minimum, there can be no data dependencies between plugins where the order of evaluation matters. Another C++ comparison is with a virtual base class, where A::B::D and A::C::D are supposed to be equal, irrespective of whether it was B or C that first called the constructor. In this case, some witness (a vtable) is necessary to ensure that this happens correctly. Dan Ganesh Sittampalam wrote: On Thu, 28 Aug 2008, Adrian Hey wrote: Ganesh Sittampalam wrote: On Thu, 28 Aug 2008, Adrian Hey wrote: There's no semantic difficulty with the proposed language extension, How does it behave in the presence of dynamic loading? To answer this you need to be precise about the semantics of what is being dynamically loaded. But this is too complex an issue for me to get in to right now. If you want to standardise a language feature, you have to explain its behaviour properly. This is one part of the necessary explanation. To be concrete about scenarios I was considering, what happens if: - the same process loads two copies of the GHC RTS as part of two completely independent libraries? For added complications, imagine that one of the libraries uses a different implementation instead (e.g. Hugs) - one Haskell program loads several different plugins in a way that allows Haskell values to pass across the plugin boundary How do these scenarios work with use cases for <- like (a) Data.Unique and (b) preventing multiple instantiation of a sub-library? Actually as far as things like hs-plugins are concerned I'd alway meant one day what exactly a "plugin" is, semantically. But as I've never had cause to use them so never got round to it. Like is it a value, or does it have state and identity or what? Personally I think of them as values. I'm not sure what your questions about state and identity mean. If you don't have global variables, then state doesn't matter. What about remote procedure calls? Dunno, what problem do you anticipate? Will Data.Unique still work properly if a value is sent across a RPC interface? Also what if I want a thread-local variable? Well actually I would say that threads are bad concurrency model so I'm not keen on thread local state at all. Mainly because I'd like to get rid of threads, but also a few other doubts even if we keep threads. Even if you don't like them, people still use them. (I.E. Just making existing practice *safe*, at least in the sense that the compiler ain't gonna fcuk it up with INLINING or CSE and every one understands what is and isn't safe in ACIO) Creating new language features means defining their semantics rather more clearly than just "no inlining or cse", IMO. Ganesh ___ 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] Re: [Haskell] Top Level <-
On Thu, 28 Aug 2008, Adrian Hey wrote: Ganesh Sittampalam wrote: On Thu, 28 Aug 2008, Adrian Hey wrote: There's no semantic difficulty with the proposed language extension, How does it behave in the presence of dynamic loading? To answer this you need to be precise about the semantics of what is being dynamically loaded. But this is too complex an issue for me to get in to right now. If you want to standardise a language feature, you have to explain its behaviour properly. This is one part of the necessary explanation. To be concrete about scenarios I was considering, what happens if: - the same process loads two copies of the GHC RTS as part of two completely independent libraries? For added complications, imagine that one of the libraries uses a different implementation instead (e.g. Hugs) - one Haskell program loads several different plugins in a way that allows Haskell values to pass across the plugin boundary How do these scenarios work with use cases for <- like (a) Data.Unique and (b) preventing multiple instantiation of a sub-library? Actually as far as things like hs-plugins are concerned I'd alway meant one day what exactly a "plugin" is, semantically. But as I've never had cause to use them so never got round to it. Like is it a value, or does it have state and identity or what? Personally I think of them as values. I'm not sure what your questions about state and identity mean. If you don't have global variables, then state doesn't matter. What about remote procedure calls? Dunno, what problem do you anticipate? Will Data.Unique still work properly if a value is sent across a RPC interface? Also what if I want a thread-local variable? Well actually I would say that threads are bad concurrency model so I'm not keen on thread local state at all. Mainly because I'd like to get rid of threads, but also a few other doubts even if we keep threads. Even if you don't like them, people still use them. (I.E. Just making existing practice *safe*, at least in the sense that the compiler ain't gonna fcuk it up with INLINING or CSE and every one understands what is and isn't safe in ACIO) Creating new language features means defining their semantics rather more clearly than just "no inlining or cse", IMO. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
Quoth brian <[EMAIL PROTECTED]>: | On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave <[EMAIL PROTECTED]> wrote: |> Quoth brian <[EMAIL PROTECTED]>: |> |> | I want to use Parsec to parse NNTP data coming to me from a handle I |> | get from connectTo. |> |> I would implement the network service |> input data stream myself, with timeouts | | Could you explain a little about how this would look? | | If it's reading characters trying to make a String we want to call a | 'line', isn't that what the parser is supposed to be doing? If you | were parsing /etc/passwd, would you read each line yourself and give | each one to Parsec? You bet, given that passwd is a simple line record file and I'm reasonably confident that hGetLine will do what I want for a disk file (or more or less so, anyway, since while I don't want end of file to raise an exception, I'm aware of work-arounds for this.) On the other hand, for the very same reason, I wouldn't worry too much about letting a parse function read the data -- from a disk file. With a network client, though, the value of those buffered I/O routines isn't so obvious to me. While it can be a convenient metaphor in some common circumstances, a socket is not a file and the notion easily becomes more trouble than it's worth. I wouldn't read byte-by-byte, but rather read available data into my own buffer. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
Quoth Johannes Waldmann <[EMAIL PROTECTED]>: ... | I think the following is analoguous. | | Imagine you're writing a parser for a simple programming language. | A program is a sequence of statements. | Fine, you do "readFile" (once) and then apply a pure Parsec parser. | | Then you decide to include "import" statements in your language. | Suddenly the parser needs to do IO. Assume the import statements | need not be the first statements of the program | (there may be headers, comments etc. before). | Then you really have to interweave the parsing and the IO. I think "readFile" might be where the analogy fails. In a network client like we were talking about, it's understood that you have to interweave the parsing and I/O, to some extent. From this point of view, I don't see a problem with this programming language parser, in fact I suppose I might indeed do it that way - maybe map the file to a ByteString or something, would have to think about it. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named field syntax
* Johannes Waldmann <[EMAIL PROTECTED]> [2008-08-29 15:39:15+0200] > > data Test = Test Integer {b::String} > > positional (= unnamed) record notation is a language design error :-) > and its use should be discouraged. - J.W. Polluting namespace with unneeded functions should not be encouraged either. Consider for instance defining datatype for 3x3 matrix. Would the absence of unnamed record notation make you more happy? -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler's bane
On Fri, 2008-08-29 at 21:48 +0100, Conor McBride wrote: > Hi > > On 29 Aug 2008, at 21:12, Jonathan Cast wrote: > > > > > If you want to avoid infinite normal forms (or just plain lack of > > normal > > forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to > > follow three rules: > > > > 1) Static typing > > With you there. > > > 2) No value recursion > > Mostly with you: might allow productive corecursion > computing only on demand. > > > 3) If you allow data types, no recursive data types > > I can think of a few Turing incomplete languages with > (co)recursive data types, so > > Otherwise, your language will be Turing-complete, > > seems suspect to me. OK. If you have any of 1) Dynamic typing, as implemented in say Scheme, or 2) Unlimited recursion, as implemented in say Haskell, or 3) Unlimited recursive data types, as implemented in say Haskell your language is Turing-complete. > It's quite possible to identify a total fragment of > Haskell, eg, by seeing which of your Haskell programs > compile in Agda. > Things aren't as hopeless as you suggest. OK. There are intermediate cases that involve some suitably restricted form of recursion. I don't actually know anything about them, so I won't comment on the suitability of such restrictions for Andrew's interpreter. But I should have remembered their existence. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler's bane
Hi On 29 Aug 2008, at 21:12, Jonathan Cast wrote: If you want to avoid infinite normal forms (or just plain lack of normal forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to follow three rules: 1) Static typing With you there. 2) No value recursion Mostly with you: might allow productive corecursion computing only on demand. 3) If you allow data types, no recursive data types I can think of a few Turing incomplete languages with (co)recursive data types, so Otherwise, your language will be Turing-complete, seems suspect to me. It's quite possible to identify a total fragment of Haskell, eg, by seeing which of your Haskell programs compile in Agda. Things aren't as hopeless as you suggest. Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler's bane
On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote: > Neil Mitchell wrote: > > Hi > > > > > >> I'm writing a simple interpretter for a small extended-lambda-calculus sort > >> of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! >_< > >> > > > > Agreed :-) > > > > I'm glad it's not just me! ;-) > > (Oleg cat sez: "see, yr type problum not so hard".) > > >> To illustrate: > >> > >> let x = f x; y = 5 in x y > >> > >> A simple-minded interpretter might try to replace every occurrance of "x" > >> with "f x". This yields > >> > >> let y = 5 in (f x) y > >> > > > > That's wrong, its a two step transformation. You just substitute all > > occurances of x for f x: > > > > let x = f (f x); y = 5 in (f x) y > > > > For the case let x = 5 in x, you do the same thing: > > > > let x = 5 in 5 > > > > Now as a second step you hoover up unused let bindings and disguard: > > > > 5 > > > > You seem to be combining the substitution and the removing of dead let > > bindings, if you separate them you should have more luck. > > > > Right. So substitute in the RHS and then perform a let-cull afterwards. > Got it. > > I've been playing with this today, and no matter what rules I come up > with, it seems to be ridiculously easy to put the interpretter into an > infinite loop from which it will never escape. Is there any way to know > which binds are "worth" expanding and which ones aren't? (I have a > sinking feeling this might be equivilent to the Halting Problem...) > > For example, if you have "let x = f y; y = g x in x" then since all the > functions are free variables, there's really nothing much "useful" you > can do to simplify this any further. However, my interpretter merrily > goes into an endless loop building a huge expression like "f (g (f (g (f > (g..." Is it possible to avoid this? If you want to avoid infinite normal forms (or just plain lack of normal forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to follow three rules: 1) Static typing 2) No value recursion 3) If you allow data types, no recursive data types Otherwise, your language will be Turing-complete, so yes, trying to determine ahead of time if even a HNF exists will be the halting problem. If you really want to write a general-purpose evaluator, then infinite normal forms may not be an issue, as long as they are generated lazily, so your evaluator can at least print something out while it goes into an infinite loop. Otherwise, you can declare f x, where f is an unknown function, a HNF, and stop at that point, or go on only under the client's control. The optimizers used by GHC and YHC pick one function out of each recursive binding group, and just refuse to inline it at all. If you don't mind producing expressions that aren't really in any definable HNF, that would be an alternative as well. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler's bane
Neil Mitchell wrote: Hi I'm writing a simple interpretter for a small extended-lambda-calculus sort of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! >_< Agreed :-) I'm glad it's not just me! ;-) (Oleg cat sez: "see, yr type problum not so hard".) To illustrate: let x = f x; y = 5 in x y A simple-minded interpretter might try to replace every occurrance of "x" with "f x". This yields let y = 5 in (f x) y That's wrong, its a two step transformation. You just substitute all occurances of x for f x: let x = f (f x); y = 5 in (f x) y For the case let x = 5 in x, you do the same thing: let x = 5 in 5 Now as a second step you hoover up unused let bindings and disguard: 5 You seem to be combining the substitution and the removing of dead let bindings, if you separate them you should have more luck. Right. So substitute in the RHS and then perform a let-cull afterwards. Got it. I've been playing with this today, and no matter what rules I come up with, it seems to be ridiculously easy to put the interpretter into an infinite loop from which it will never escape. Is there any way to know which binds are "worth" expanding and which ones aren't? (I have a sinking feeling this might be equivilent to the Halting Problem...) For example, if you have "let x = f y; y = g x in x" then since all the functions are free variables, there's really nothing much "useful" you can do to simplify this any further. However, my interpretter merrily goes into an endless loop building a huge expression like "f (g (f (g (f (g..." Is it possible to avoid this? (The problem isn't unique to recursive let-binds of course. I discovered today that (\x -> x x) (\x -> x x) reduces to itself, so that puts the interpretter into a loop too. However, NON-recursive let-binds always terminate eventually. It's only the recursive ones that cause problems.) My word, this stuff is really surprisingly hard! At least this time I built a general-purpose renamer rather than trying to avoid name capture by construction! ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New Category Theory Intros
These category theory intros were new to me. Thought others here might care. http://golem.ph.utexas.edu/category/2008/08/new_structures_for_physics_i.html -- Darrin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave <[EMAIL PROTECTED]> wrote: > Quoth brian <[EMAIL PROTECTED]>: > > | I want to use Parsec to parse NNTP data coming to me from a handle I > | get from connectTo. > > I would implement the network service > input data stream myself, with timeouts Could you explain a little about how this would look? If it's reading characters trying to make a String we want to call a 'line', isn't that what the parser is supposed to be doing? If you were parsing /etc/passwd, would you read each line yourself and give each one to Parsec? > So the parser would > never see any streams or handles or anything, it would just get strings > to parse. Well, I think the parser still works with a Stream. For example, Text/Parsec/ByteString.hs makes ByteString an instance of Stream. My next try is to make this thing an instance of Stream: data Connection = Connection { connectionHandle :: Handle , connectionData :: C.ByteString } In uncons, the easy case is when connectionData is nonnull. If it is null, hWaitForInput on the handle. If we get something, read it and return appropriate stuff. If not, it's a parse error similar to getting unexpected EOF in a file. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
On Fri, 2008-08-29 at 20:01 +0200, Johannes Waldmann wrote: > Donn Cave wrote: > > > ... I would implement the network service > > input data stream myself, with timeouts, encryption, whatever as required, > > and then apply the parser to available data as a simple, pure function > > that returns NNTP results and whatever data remains. So the parser would > > never see any streams or handles or anything, it would just get strings > > to parse. > > A likely problem with that is that your implementation of the "input > data stream" will still need to parse some information from it. > So you're going to replicate code from the parser. > > I think the following is analoguous. > > Imagine you're writing a parser for a simple programming language. > A program is a sequence of statements. > Fine, you do "readFile" (once) and then apply a pure Parsec parser. > > Then you decide to include "import" statements in your language. > Suddenly the parser needs to do IO. Assume the import statements > need not be the first statements of the program > (there may be headers, comments etc. before). > Then you really have to interweave the parsing and the IO. > > If anyone has a nice solution to this, please tell. - J.W. Using parsec3 you can just do exactly what you said. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
igouy2: > otoh I see the attraction of showing parallelised versions alongside > existing programs; otoh that adds yet another layer of confusion about > why the measurements differ (and another level of quarreling about > whether even vaguely the same thing is being measured); otoh some > existing programs already use more cores when they can ... > > The Scala threadring program shows 524s cpu but 157s elapsed: > > http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all Very cool! > > I'm keen to get going on this, if only because I think we can turn > > out parallelised versions of many of the existing programs, fairly > > cheaply. > > I'm always delighted that you're keen to get going on things like this! > > The benchmarks game always seems to demand somewhat unnatural acts and > here's another - is there an effective way to /prevent/ ghc using > multiple cores when multiple cores are available? Can we force ghc to > only use one core on the quadcore machine? (Moreover can we do the same > trick for other languages?) Certainly, for the quad core, to get all 4 cores in play: * compile with -threaded * run with +RTS -N4 to force single core, we'll: * compile normally * run normally -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
Donn Cave wrote: > ... I would implement the network service > input data stream myself, with timeouts, encryption, whatever as required, > and then apply the parser to available data as a simple, pure function > that returns NNTP results and whatever data remains. So the parser would > never see any streams or handles or anything, it would just get strings > to parse. A likely problem with that is that your implementation of the "input data stream" will still need to parse some information from it. So you're going to replicate code from the parser. I think the following is analoguous. Imagine you're writing a parser for a simple programming language. A program is a sequence of statements. Fine, you do "readFile" (once) and then apply a pure Parsec parser. Then you decide to include "import" statements in your language. Suddenly the parser needs to do IO. Assume the import statements need not be the first statements of the program (there may be headers, comments etc. before). Then you really have to interweave the parsing and the IO. If anyone has a nice solution to this, please tell. - J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
On Aug 29, 2008, at 9:11 AM, Isaac Gouy wrote: The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?) There is indeed. In fact, GHC-compiled programs will only use multiple processors if you explicitly tell them to. To make use of two processors, for instance, you have to pass the flags '+RTS -N2' to the compiled executable when you run it. This tells it to schedule its internal threads on two OS threads, which the OS will presumably run on two processors if possible. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec and network data
Quoth brian <[EMAIL PROTECTED]>: | I want to use Parsec to parse NNTP data coming to me from a handle I | get from connectTo. Are you still having trouble with this? Take my opinion for what it's worth - I'm no Haskell guru - but for me, your basic approach is unsound. I would implement the network service input data stream myself, with timeouts, encryption, whatever as required, and then apply the parser to available data as a simple, pure function that returns NNTP results and whatever data remains. So the parser would never see any streams or handles or anything, it would just get strings to parse. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
--- Don Stewart <[EMAIL PROTECTED]> wrote: -snip > > How should the benchmarks game approach multicore? > > Well, there's a famous paper, > > Algorithm + Strategy = Parallelism > > I'd imagine we use the benchmark game's algorithms, but let > submitters determine the strategy. Then the results would show > > a) how well you utilize the cores, and > b) overall wall clock results. otoh I see the attraction of showing parallelised versions alongside existing programs; otoh that adds yet another layer of confusion about why the measurements differ (and another level of quarreling about whether even vaguely the same thing is being measured); otoh some existing programs already use more cores when they can ... The Scala threadring program shows 524s cpu but 157s elapsed: http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all > I'm keen to get going on this, if only because I think we can turn > out parallelised versions of many of the existing programs, fairly > cheaply. I'm always delighted that you're keen to get going on things like this! The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
Brandon S. Allbery KF8NH wrote: On 2008 Aug 29, at 4:22, Adrian Hey wrote: Brandon S. Allbery KF8NH wrote: On 2008 Aug 28, at 20:45, Adrian Hey wrote: Lennart Augustsson wrote: If Haskell had always taken the pragmatic path of adding what seems easiest and most in line with imperative practice it would not be the language it is today. It would be Perl, ML, or Java. The Haskell philosophy has always been to stick it out until someone comes up with the right solution to a problem rather than picking some easy way out. BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's not get too snobby about this. (Sorry, I couldn't resist.) It's anything but easy; there are specific rules you need to follow, including use of certain compiler pragmas, to insure it works properly. Yes, of course. The worst thing about all this is that the single most common use case AFAICS (the one under discussion) isn't even a "safe" use. Just pointing out that this pseudo function is certainly not something one would expect from an organisation as dedicated to the persuit of perfection as Lennart would have us believe. It's an expedient hack. Not that I wish to seem ungrateful or anything :-) ...but, as he noted, we *do* that until we find the right way to do it. So what's the problem with doing it *safely*, that is at least until someone has found the mythic "right way to do it". Not that anybody has ever been able to offer any rational explanation of what's *wrong* with the current proposed solution AFAICS. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax of 'do'
2008/8/29 Philip Weaver <[EMAIL PROTECTED]>: > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the > new definitions. This is not possible, regardless of what types you give > (>>) and (>>=). Watch out for rebindable syntax: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax At first reading, I thought that -XNoImplicitPrelude was required to turn this on. But now I'm not sure: it seems that if you hide Prelude.>>= and Prelude.return, that ought to be enough to make do notation work with your alternative definitions. I'm not at home, so I can't try this right now. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax of 'do'
On Fri, Aug 29, 2008 at 6:41 AM, Maurício <[EMAIL PROTECTED]> wrote: > Hi, > > http://haskell.org/haskellwiki/Keywords says that: > > - > [do is a] syntactic sugar for use with monadic > expressions. For example: > > do { x ; result <- y ; foo result } > > is shorthand for: > > x >> y >>= \result -> foo result > - > > I did some tests hiding Prelude.>> and Prelude.>>= > and applying >> and >>= to non-monadic types, and > saw that 'do' would not apply to them. So, I would > like to add the following to that text: > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the new definitions. This is not possible, regardless of what types you give (>>) and (>>=). If you want to define (>>) and (>>=), do so for a particular instance of Monad. > - > as long as proper types apply: > > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c > - > > Is that correct (Haskell and English)? > > Thanks, > Maurício > > ___ > 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] Syntax of 'do'
2008/8/29 Maurício <[EMAIL PROTECTED]>: > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c Monad is not a type, it is a type class, so you probably mean: x :: Monad m => m a y :: Monad m => m b foo :: Monad m => b -> m c With the further understanding that all three `m's must be the same. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named field syntax
On 2008 Aug 29, at 9:30, Maurí cio wrote: However, this doesn't: data Test = Test Integer {b::String} Is there some way to name only a single, or a few, of some data type fields? There's no shorthand for it, no (and therefore you can't get one that works for pattern matching). Personally, I haven't found it a hardship, because you can always used the unnamed field syntax. -- 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] Syntax of 'do'
Hello Mauricio, Friday, August 29, 2008, 5:41:41 PM, you wrote: afaik, this shorthand isn't exact. actually there is more code dealing with fails and this code use Monad operations > Hi, > http://haskell.org/haskellwiki/Keywords says that: > - > [do is a] syntactic sugar for use with monadic > expressions. For example: > do { x ; result <- y ; foo result } > is shorthand for: > x >> y >>= \result -> foo result > - > I did some tests hiding Prelude.>> and Prelude.>>= and applying >>> and >>= to non-monadic types, and > saw that 'do' would not apply to them. So, I would > like to add the following to that text: > - > as long as proper types apply: > x :: Prelude.Monad a > y :: Prelude.Monad b foo :: b ->> Prelude.Monad c > - > Is that correct (Haskell and English)? > Thanks, > Mauricio > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
On 2008 Aug 29, at 4:22, Adrian Hey wrote: Brandon S. Allbery KF8NH wrote: On 2008 Aug 28, at 20:45, Adrian Hey wrote: Lennart Augustsson wrote: If Haskell had always taken the pragmatic path of adding what seems easiest and most in line with imperative practice it would not be the language it is today. It would be Perl, ML, or Java. The Haskell philosophy has always been to stick it out until someone comes up with the right solution to a problem rather than picking some easy way out. BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's not get too snobby about this. (Sorry, I couldn't resist.) It's anything but easy; there are specific rules you need to follow, including use of certain compiler pragmas, to insure it works properly. Yes, of course. The worst thing about all this is that the single most common use case AFAICS (the one under discussion) isn't even a "safe" use. Just pointing out that this pseudo function is certainly not something one would expect from an organisation as dedicated to the persuit of perfection as Lennart would have us believe. It's an expedient hack. Not that I wish to seem ungrateful or anything :-) ...but, as he noted, we *do* that until we find the right way to do it. -- 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] Named field syntax
> data Test = Test Integer {b::String} positional (= unnamed) record notation is a language design error :-) and its use should be discouraged. - J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax of 'do'
-XNoImplicitPrelude ? On 29 Aug 2008, at 17:41, Maurí cio wrote: Hi, http://haskell.org/haskellwiki/Keywords says that: - [do is a] syntactic sugar for use with monadic expressions. For example: do { x ; result <- y ; foo result } is shorthand for: x >> y >>= \result -> foo result - I did some tests hiding Prelude.>> and Prelude.>>= and applying >> and >>= to non-monadic types, and saw that 'do' would not apply to them. So, I would like to add the following to that text: - as long as proper types apply: x :: Prelude.Monad a y :: Prelude.Monad b foo :: b -> Prelude.Monad c - Is that correct (Haskell and English)? Thanks, Maurício ___ 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] Syntax of 'do'
Hi, http://haskell.org/haskellwiki/Keywords says that: - [do is a] syntactic sugar for use with monadic expressions. For example: do { x ; result <- y ; foo result } is shorthand for: x >> y >>= \result -> foo result - I did some tests hiding Prelude.>> and Prelude.>>= and applying >> and >>= to non-monadic types, and saw that 'do' would not apply to them. So, I would like to add the following to that text: - as long as proper types apply: x :: Prelude.Monad a y :: Prelude.Monad b foo :: b -> Prelude.Monad c - Is that correct (Haskell and English)? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named field syntax
Maurício <[EMAIL PROTECTED]> writes: > However, this doesn't work: > > data Test = Test Integer {b::String} > Is there some way to name only a single, or a few, > of some data type fields? data Test = Test Integer String b :: Test -> String b (Test i s) = s :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Named field syntax
Hi, I see that this works: data Test = Test Integer String This also works: data Test = Test {a::Integer,b::String} However, this doesn't: data Test = Test Integer {b::String} Is there some way to name only a single, or a few, of some data type fields? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
Richard A. O'Keefe wrote: On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote: What type safety buys you, in my mind, is that Nothing is only a valid value for explicit Maybe types. In cases where you don't use Maybe, the "null" situation just can't occur. In languages with null pointers, any pointer could possibly be null. This is not true of Eiffel. The ECMA Eiffel standard has ?Teither a void reference or a reference to an instance of T !Ta reference to an instance of T Tsame as !T in ECMA Eiffel; used to be same as ?T I suppose you could call the detachable type ?T an *implicit* Maybe. Needless to say, the switch in semantics of undecorated T helped to fork the Eiffel community... Just because the devil needs more advocacy... there are safer dialects of C that have non-nullable pointers in addition to the standard variety. Cyclone[1] comes to mind, there are others. In so far as propaganda goes, imperative programming is ugly, unsafe, and evil, but it is getting better. Blanket statements about their failings tend toward falsity as they keep adopting things from the functional world. [1] http://www.cs.bu.edu/groups/ibench/presentations/2003-04-10.pdf -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HEq and Context reduction stack overflow, non optimal ghc behaviour ?
Marc Weber wrote: Now ghc can try to resolve (1),(2),(3) in arbitrary order.. What happens if ghc starts with (3)? It tries to find an instance for not known types.. Damn. There is even a matching instance.. , the same one. This time it starts even with HEqwhich is even more bad! after the second recursion it already knows that won't find a solution, because it will try to resolve HEqagain and again.. What happens if ghc starts with (1 or 2)? It happily finds an instance *and* it can even resolve elNr and elNr' Those can then be used to find an instance for (3) easily So I think the behaviour of ghc should be changed to prefer resolving class constraints which reduce the amount of unkown types first I even consider this beeing a bug ? So maybe this thread should be moved to glasgow-haskell-users ? There are a number of issues like this due to the fact that typeclass instances aren't determined by full SLD resolution. More particularly the determinism information in fundeps seems to be ignored in this whole process. Not that I'm a GHC hacker (yet), but research in this area is at the top of my to-do stack; alas that's still a ways away. To put a refinement on your proposal, I'd suggest that fundeps be used to construct a dataflow graph in order to know which instances to pursue first (namely, the leaves). To resolve the ordering any toposort of the dataflow graph should be fine. This still has the problem of if there's no toposort, though: class Foo a b | a -> b class Bar a b | b -> a class Wtf a b instance (Foo a b, Bar a b) => Wtf a b There are a few standard approaches to break the cycle, though if instances of Foo or Bar are given inductively we might run into the same problems as your code. Here's another proposal, and perhaps an easier one to hack together for the time being. When pursuing the context of an instance for some class A, resolve all instances for non-A classes before pursuing instances for A. It's not a general solution, but it's closer to correct at least. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
Brandon S. Allbery KF8NH wrote: On 2008 Aug 28, at 20:45, Adrian Hey wrote: Lennart Augustsson wrote: If Haskell had always taken the pragmatic path of adding what seems easiest and most in line with imperative practice it would not be the language it is today. It would be Perl, ML, or Java. The Haskell philosophy has always been to stick it out until someone comes up with the right solution to a problem rather than picking some easy way out. BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's not get too snobby about this. (Sorry, I couldn't resist.) It's anything but easy; there are specific rules you need to follow, including use of certain compiler pragmas, to insure it works properly. Yes, of course. The worst thing about all this is that the single most common use case AFAICS (the one under discussion) isn't even a "safe" use. Just pointing out that this pseudo function is certainly not something one would expect from an organisation as dedicated to the persuit of perfection as Lennart would have us believe. It's an expedient hack. Not that I wish to seem ungrateful or anything :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe