[Haskell-cafe] Re: [Haskell] Re: 20 years ago
On Thu, 16 Jul 2009 13:38:14 +1200, Richard O'Keefe o...@cs.otago.ac.nz wrote: On Jul 15, 2009, at 5:25 PM, Benjamin L.Russell wrote: it interesting that you should use the biological term disease; according to a post [1] entitled Re: Re: Smalltalk Data Structures and Algorithms, by K. K. Subramaniam, dated Mon, 29 Jun 2009 11:25:34 +0530, on the squeak-beginners mailing list (see http://lists.squeakfoundation.org/pipermail/beginners/2009-June/006270.html) , Concepts in Squeak [a dialect and implementation of Smalltalk] have their origins in biology rather than in computational math That posting is wrong. Smalltalk's roots are very firmly planted in Lisp, with perhaps a touch of Logo (which also had its roots in Lisp). The classic Smalltalk-76 paper even contains a meta-circular interpreter, which I found reminiscent of the old Lisp one. The biological metaphor in Smalltalk is actually a SOCIAL metaphor: sending and receiving messages, and a social model of agents with memory exchanging messages naturally leads to anthropomorphisms Incidentally, just for the record, in response to my forwarding your claim, Alan Kay, the inventor of Smalltalk, just refuted your refutation [1] (see http://lists.squeakfoundation.org/pipermail/beginners/2009-July/006331.html); _viz._: I most definitely still think of OOP at its best as being biological. -- Benjamin L. Russell [1] Kay, Alan. [Newbies] Re: Smalltalk Data Structures and Algorithms. The Beginners Archives. Squeak.org. 24 July 2009. 27 July 2009. http://lists.squeakfoundation.org/pipermail/beginners/2009-July/006331.html. -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary.encode slower than show
On Sun, Jul 26, 2009 at 10:27:41PM +0200, Grzegorz Chrupała wrote: Hi all, I have a piece of code where I'm serializing a datastructure with the following type [(Int, (Map DType (IntMap Int)))], using Binary.encode The thing is it is very slow: actually quite a bit slower than just using show. This seems rather suspicious. Any idea what could be going on? Does Map serialisation still require flattening the map to a List? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a sample code for hdbus?
Hi, Although I have used dbus with ruby a little, but still, I do not understand hdbus's APIs Is there any sample that I could learn? Thanks. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A Question of Restriction
Brian Troutwine wrote:
Do you have any reason not to do the above?
Yes, the subset types that I wish to define are not clean partitions,
though my example does suggest this. Let's say that the definition of
Foo is now
data Foo = One | Two | Three | Four | Five | Six
while Odd and Even remain the same. I would further like to define
Triangular, which I will do incorrectly for consistency.
data Triangular = One | Three | Six
I could not accommodate this definition using your scheme, correct?
A variation on scheme proposed by Ross Mellgren earlier in this thread.
It's a bit tedious but allows for definition of arbitrary subsets thus
it may work for you:
{-# LANGUAGE GADTs, EmptyDataDecls #-}
data One
data Two
data Three
data Four
data Foo a where
FOne :: Foo One
FTwo :: Foo Two
FThree :: Foo Three
FFour :: Foo Four
class IsEven a
instance IsEven Two
instance IsEven Four
class IsOdd a
instance IsOdd One
instance IsOdd Three
class IsLessThanThree a
instance IsLessThanThree One
instance IsLessThanThree Two
quux :: IsEven a = Foo a - String
quux FTwo = 2
quux FFour = 4
bzzt :: IsLessThanThree a = Foo a - String
bzzt FOne = 1
bzzt FTwo = 2
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Question of Restriction
Hi Brian, If I understand you correctly, you've run into the Expression Problem. Phil Wadler posed the problem in a widely-cited e-mail, formulating it much more clearly than I ever could: http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt There are lots of ways to tackle this problem in Haskell - just google Expression Problem Haskell. My (completely biased) personal favourite is: http://www.cse.chalmers.se/~wouter/Publications/DataTypesALaCarte.pdf Hope this helps, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proposal: TypeDirectedNameResolution
While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. Is there 'ghc -XTypeDirectedNameResolution' yet? - 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] Proposal: TypeDirectedNameResolution
Hello Johannes, Monday, July 27, 2009, 7:58:11 PM, you wrote: While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution haskell-prime is future haskell standard now in development and on this wiki anyone can write his proposals without any actual implementation -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
this wiki anyone can write his proposals [...] sure, but this anyone is simponpj ... 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] Proposal: TypeDirectedNameResolution
2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de: While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. You would be arguing against it then? ;) Is there 'ghc -XTypeDirectedNameResolution' yet? I'm pretty sure there is not. I don't really care for this proposal because it involves yet more overloading of (.) which rather annoys me. Composition is by far the most common infix operator in my code, and I consider its choice for module qualification a minor, but irritating mistake. (It makes composition chains with qualified names just that much harder to scan with your eyes.) There was a great related idea on #haskell the other day: Make explicit qualification unnecessary whenever there is a *unique* choice of module qualifications from those imported which would make the expression typecheck. Ambiguities would still need to be qualified, but I feel that this would eliminate 99% of all ugly qualified names from code. It would be especially good in the case of infix operators, which as far as I know, nobody actually enjoys qualifying explicitly. I can see some corner cases where this might lead to a combinatorial explosion of possible qualifications to try, however, I have a feeling that such cases wouldn't really happen in practice. It is admittedly a bit like a very restricted sort of ad-hoc polymorphism, but given that the modules are compiled separately, I think the actual interactions with the workings of the type system are not really very significant. (It's just like you tried each set of possible qualifications, compiling the whole thing each time, and checking to see if there's a unique way to get the module to compile.) This would mean that if we had, say, Data.List, Data.Map and Data.Set imported, and there was an occurrence of insert that happened to be applied to a couple of values and then something known to be a Map, it would behave as if you'd written Data.Map.insert, because that's the only thing which could possibly make sense. If there were ambiguity about which insert you meant, it would still be an error, and you might have to qualify it explicitly. What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
Cale Gibbard wrote: What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. A disadvantage - and this is not a No vote, just a remark - is that when trying to debug the expression: foo bar baz quux if I type :t bar I will presumably get an ambiguity error, and I may have no easy way of working out *which* bar was actually intended in this line of code. I don't know how much of a burden this is, but it feels like a burden to writing/debugging/understanding code. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
I've spoken in favor of this many times before. But there are many who think, Every function you write should have a unique name. Talk about needless clutter. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jul 27, 2009, at 10:29 AM, Cale Gibbard wrote: What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
2009/7/27 Jules Bean ju...@jellybean.co.uk: Cale Gibbard wrote: What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. A disadvantage - and this is not a No vote, just a remark - is that when trying to debug the expression: foo bar baz quux if I type :t bar I will presumably get an ambiguity error, and I may have no easy way of working out *which* bar was actually intended in this line of code. I don't know how much of a burden this is, but it feels like a burden to writing/debugging/understanding code. Jules There certainly do seem like some cases where it would help the person reading the code to qualify which module you meant, so clearly if it's not very obvious which selection of modules produces the unique way to get things to typecheck, that's not very good. Perhaps there should at least be the restriction that there must exist a chain of individual choices made where there was a unique possibility at each step. This ensures that you never have to backtrack in deciding which modules things are intended to come from. Of course, in cases where it's still not obvious, it'd still be possible to make the qualification explicit. The goal is to eliminate the need to explicitly qualify in the cases where it's entirely obvious what the qualification should be. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard cgibb...@gmail.com wrote: 2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de: While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. You would be arguing against it then? ;) Is there 'ghc -XTypeDirectedNameResolution' yet? I'm pretty sure there is not. I don't really care for this proposal because it involves yet more overloading of (.) which rather annoys me. Composition is by far the most common infix operator in my code, and I consider its choice for module qualification a minor, but irritating mistake. (It makes composition chains with qualified names just that much harder to scan with your eyes.) There was a great related idea on #haskell the other day: Make explicit qualification unnecessary whenever there is a *unique* choice of module qualifications from those imported which would make the expression typecheck. Ambiguities would still need to be qualified, but I feel that this would eliminate 99% of all ugly qualified names from code. It would be especially good in the case of infix operators, which as far as I know, nobody actually enjoys qualifying explicitly. My biggest fear is that of usability. If I understand you correctly, then as you change module imports you change the meaning of the code in potentially non-obvious ways. So this isn't too different than using unqualified imports and flipping between two modules that export the same function. Except that as you increase the 'automatic'ness of it, it has the potential to trip up people. I think what is the worse case is, you add a module import and suddenly you have an error in code that was previously compiling. Suddenly the auto-disambiguate stops working in a chunk of code that was fine before. When working with code that others have written this would confuse me. I think I would then start using qualified imports everywhere just to work around this feature :) Yes, I realize it would be an extension, but it would be an extension that I suspect I would try to avoid. What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. I like explicit module qualifications more or less. I certainly don't mind reading them and I don't care if it takes 2 seconds longer to type something. You asked for my thoughts and there they are :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Retiring forkIO
Hi, I'd like to retire forkIO and friends by using Delimited Continuations instead. Am I dead wrong here in my understanding of Delimited Continuations or can I pursue in this direction? The most immediate use for this is actully GUI problems where I'd use del-conts in place of forkIO for long-running computations because once I forkIO the computation so as not to block the UI thread I cannot call GUI code from the end of that thread. Well I can but then the app crashes because of single threading issues. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
2009/7/27 Jason Dagit da...@codersbase.com: On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard cgibb...@gmail.com wrote: 2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de: While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. You would be arguing against it then? ;) Is there 'ghc -XTypeDirectedNameResolution' yet? I'm pretty sure there is not. I don't really care for this proposal because it involves yet more overloading of (.) which rather annoys me. Composition is by far the most common infix operator in my code, and I consider its choice for module qualification a minor, but irritating mistake. (It makes composition chains with qualified names just that much harder to scan with your eyes.) There was a great related idea on #haskell the other day: Make explicit qualification unnecessary whenever there is a *unique* choice of module qualifications from those imported which would make the expression typecheck. Ambiguities would still need to be qualified, but I feel that this would eliminate 99% of all ugly qualified names from code. It would be especially good in the case of infix operators, which as far as I know, nobody actually enjoys qualifying explicitly. My biggest fear is that of usability. If I understand you correctly, then as you change module imports you change the meaning of the code in potentially non-obvious ways. So this isn't too different than using unqualified imports and flipping between two modules that export the same function. Except that as you increase the 'automatic'ness of it, it has the potential to trip up people. Well, yes, but only insofar as you can already cause that to happen. Simply adding a new module import might force you to qualify some names, as you mention below (and as it can already force you to do), but will never cause the meaning to otherwise change, since it's not doing something like picking the first module which works (which would really be bad). It's only fixing the qualification in places where there's *exactly one* qualification that would work. Similarly, removing a module import will not cause the meaning to change, supposing that the module still compiles, and if you can do that, you can still be certain that nothing from that module was being used. Of course, put the two together in one step, and you can change semantics arbitrarily, but that's already the case, and I don't think that's necessarily something to be avoided. I think what is the worse case is, you add a module import and suddenly you have an error in code that was previously compiling. Suddenly the auto-disambiguate stops working in a chunk of code that was fine before. When working with code that others have written this would confuse me. I think I would then start using qualified imports everywhere just to work around this feature :) You can already import a module and suddenly need to disambiguate expressions where a name gets used. This just relieves you of that responsibility sometimes. Consider the case where you have a module with a bunch of uses of stuff from Data.List and the Prelude, and you decide that you need Data.Map for a new function. If you import Data.Map, all of a sudden, you need to qualify half of the Prelude and Data.List stuff or it would be ambiguous. (Or import Data.Map qualified.) Yes, I realize it would be an extension, but it would be an extension that I suspect I would try to avoid. What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. I like explicit module qualifications more or less. I certainly don't mind reading them and I don't care if it takes 2 seconds longer to type something. You asked for my thoughts and there they are :) Well, thanks :) I do think some thought has to be put into limiting the power of it, so that we don't end up with situations where only a computer could figure out what's going on. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retiring forkIO
Hi Don, no I can't, I have no clue how to do that. :) There is Olegs ZFS and he has written all his code without any use of forkIO, so I know it's possible, I just haven't been able to translate it to my problem. Günther Am 27.07.2009, 19:10 Uhr, schrieb Don Stewart d...@galois.com: gue.schmidt: Hi, I'd like to retire forkIO and friends by using Delimited Continuations instead. Am I dead wrong here in my understanding of Delimited Continuations or can I pursue in this direction? The most immediate use for this is actully GUI problems where I'd use del-conts in place of forkIO for long-running computations because once I forkIO the computation so as not to block the UI thread I cannot call GUI code from the end of that thread. Well I can but then the app crashes because of single threading issues. Can you provide some examples of how you'd rewrite forkIO code to use del-conts? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
about qualified imports and TDNR: for x.f to work (as in the proposal), the name f must be in scope (that is, be imported unqualified)? That would be bad (unqualified imports should be discouraged). In Java, the methods of a type are automatically in scope, e.g., the .bitCount() works without any import: System.out.println ( java.math.BigInteger.TEN.bitCount() ); see JLS 15.12.1 item 1.3 (in all other cases...) J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 'cabal install lhs2tex' fails for me on os x -- help please
Fails during configuration: bash-3.2$ cabal install lhs2tex Resolving dependencies... [1 of 1] Compiling Main ( /tmp/lhs2tex-1.1423397/lhs2tex-1.14/Setup.hs, /tmp/lhs2tex-1.1423397/lhs2tex-1.14/dist/setup/Main.o ) Linking /tmp/lhs2tex-1.1423397/lhs2tex-1.14/dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Note that the the first module to be compiled is Main. On my linux machine, Main is the *last* of several modules to be compiled. Here's my failure log: http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=3096#a3096 . If instead I use ./configure and make, i get errors due to use of the old Exception API: ... [17 of 19] Compiling FileNameUtils( FileNameUtils.lhs, FileNameUtils.o ) FileNameUtils.lhs:81:35: Ambiguous type variable `b' in the constraint: `GHC.Exception.Exception b' arising from a use of `catch' at FileNameUtils.lhs:(81,35)-(89,60) Probable fix: add a type signature that fixes these type variable(s) ... Suggestions greatly appreciated! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'cabal install lhs2tex' fails for me on os x -- help please
conal: Fails during configuration: bash-3.2$ cabal install lhs2tex Resolving dependencies... [1 of 1] Compiling Main ( /tmp/lhs2tex-1.1423397/lhs2tex-1.14/ Setup.hs, /tmp/lhs2tex-1.1423397/lhs2tex-1.14/dist/setup/Main.o ) Linking /tmp/lhs2tex-1.1423397/lhs2tex-1.14/dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Note that the the first module to be compiled is Main. On my linux machine, Main is the *last* of several modules to be compiled. Here's my failure log: http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=3096# a3096 . If instead I use ./configure and make, i get errors due to use of the old Exception API: ... [17 of 19] Compiling FileNameUtils( FileNameUtils.lhs, FileNameUtils.o ) FileNameUtils.lhs:81:35: Ambiguous type variable `b' in the constraint: `GHC.Exception.Exception b' arising from a use of `catch' at FileNameUtils.lhs:(81,35)-(89,60) Probable fix: add a type signature that fixes these type variable(s) ... Suggestions greatly appreciated! Via cabal: --constraint='base4' or replace Control.Exception with Control.OldException or add 'base 4' to the depends in the .cabal file. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'cabal install lhs2tex' fails for me on os x -- help please
On Jul 27, 2009, at 14:23 , Conal Elliott wrote: Note that the the first module to be compiled is Main. On my linux machine, Main is the *last* of several modules to be compiled. It's compiling the setup program which is presumably used by cabal to do the work a configure script normally does. cabal install -- verbose=3 lhs2tex might show what setup is upset about. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'cabal install lhs2tex' fails for me on os x -- help please
Via cabal: --constraint='base4' or replace Control.Exception with Control.OldException or add 'base 4' to the depends in the .cabal file. Thanks, Don. Trying your first suggestion, I get the same result for the first and third method, and a ghc panic on cat_evals for the second method. All happening in ghc-6.10.3 installed via the Haskell Platform last week on OS X. bash-3.2$ cabal install lhs2tex --constraint='base4' Resolving dependencies... [1 of 1] Compiling Main ( /tmp/lhs2tex-1.1424460/lhs2tex-1.14/Setup.hs, /tmp/lhs2tex-1.1424460/lhs2tex-1.14/dist/setup/Main.o ) Linking /tmp/lhs2tex-1.1424460/lhs2tex-1.14/dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Still fishy about compiling Main first. Now I'll edit add the ' 4' constraint on base, giving the same result: bash-3.2$ dirs ~/cabal bash-3.2$ cabal unpack lhs2tex Unpacking lhs2tex-1.14... bash-3.2$ cd lhs2tex-1.14 [lhs2tex.cabal edit happens here] bash-3.2$ cabal install Resolving dependencies... [1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o ) Linking ./dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Note that on linux, the package compiles without changing the base constraint. I don't know how. Finally, use explicit ./configure make: bash-3.2$ ./configure bash: ./configure: Permission denied bash-3.2$ sh configure checking for ghc... /usr/bin/ghc checking for hugs... no checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for mv... /bin/mv checking for cp... /bin/cp checking for rm... /bin/rm checking for mkdir... /bin/mkdir checking for touch... /usr/bin/touch checking for diff... /usr/bin/diff checking for grep... /usr/bin/grep checking for sed... /usr/bin/sed checking for sort... /usr/bin/sort checking for uniq... /usr/bin/uniq checking for find... /usr/bin/find checking for latex... /usr/local/texlive/2008/bin/universal-darwin/latex checking for pdflatex... /usr/local/texlive/2008/bin/universal-darwin/pdflatex checking for xdvi... /usr/local/texlive/2008/bin/universal-darwin/xdvi checking for gv... no checking for dvips... /usr/local/texlive/2008/bin/universal-darwin/dvips checking for kpsewhich... /usr/local/texlive/2008/bin/universal-darwin/kpsewhich checking for a texmf tree... /usr/local/texlive/2008/../texmf-local checking for texmf.cnf... yes checking for the polytable package... /usr/local/texlive/2008/texmf-dist/tex/latex/polytable/polytable.sty checking for version of polytable... 0.8.2 checking whether polytable needs to be installed... no checking for mktexlsr... /usr/local/texlive/2008/bin/universal-darwin/mktexlsr configure: creating ./config.status config.status: creating config.mk config.status: creating Version.lhs config.status: creating lhs2TeX.1 config.status: creating doc/InteractiveHugs.lhs config.status: creating doc/InteractivePre.lhs Configuration succesfully completed. Say make to compile and build documentation make bin to compile the binary only make install to (compile and) install [edit happens here, changing Control.Exception to Control.OldException.] bash-3.2$ ./configure bash: ./configure: Permission denied bash-3.2$ sh configure checking for ghc... /usr/bin/ghc checking for hugs... no checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for mv... /bin/mv checking for cp... /bin/cp checking for rm... /bin/rm checking for mkdir... /bin/mkdir checking for touch... /usr/bin/touch checking for diff... /usr/bin/diff checking for grep... /usr/bin/grep checking for sed... /usr/bin/sed checking for sort... /usr/bin/sort checking for uniq... /usr/bin/uniq checking for find... /usr/bin/find checking for latex... /usr/local/texlive/2008/bin/universal-darwin/latex checking for pdflatex... /usr/local/texlive/2008/bin/universal-darwin/pdflatex checking for xdvi... /usr/local/texlive/2008/bin/universal-darwin/xdvi checking for gv... no checking for dvips... /usr/local/texlive/2008/bin/universal-darwin/dvips checking for kpsewhich... /usr/local/texlive/2008/bin/universal-darwin/kpsewhich checking for a texmf tree... /usr/local/texlive/2008/../texmf-local checking for texmf.cnf... yes checking for the polytable package... /usr/local/texlive/2008/texmf-dist/tex/latex/polytable/polytable.sty checking for
Re: [Haskell-cafe] 'cabal install lhs2tex' fails for me on os x -- help please
Yo ho! I just installed ghc-6.10.4 over my 6.10.3. Now 'cabal install lhs2tex' works. Phew! On Mon, Jul 27, 2009 at 11:44 AM, Conal Elliott co...@conal.net wrote: Via cabal: --constraint='base4' or replace Control.Exception with Control.OldException or add 'base 4' to the depends in the .cabal file. Thanks, Don. Trying your first suggestion, I get the same result for the first and third method, and a ghc panic on cat_evals for the second method. All happening in ghc-6.10.3 installed via the Haskell Platform last week on OS X. bash-3.2$ cabal install lhs2tex --constraint='base4' Resolving dependencies... [1 of 1] Compiling Main ( /tmp/lhs2tex-1.1424460/lhs2tex-1.14/Setup.hs, /tmp/lhs2tex-1.1424460/lhs2tex-1.14/dist/setup/Main.o ) Linking /tmp/lhs2tex-1.1424460/lhs2tex-1.14/dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Still fishy about compiling Main first. Now I'll edit add the ' 4' constraint on base, giving the same result: bash-3.2$ dirs ~/cabal bash-3.2$ cabal unpack lhs2tex Unpacking lhs2tex-1.14... bash-3.2$ cd lhs2tex-1.14 [lhs2tex.cabal edit happens here] bash-3.2$ cabal install Resolving dependencies... [1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o ) Linking ./dist/setup/setup ... Configuring lhs2tex-1.14... cabal: Error: some packages failed to install: lhs2tex-1.14 failed during the configure step. The exception was: exit: ExitFailure 11 Note that on linux, the package compiles without changing the base constraint. I don't know how. Finally, use explicit ./configure make: bash-3.2$ ./configure bash: ./configure: Permission denied bash-3.2$ sh configure checking for ghc... /usr/bin/ghc checking for hugs... no checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for mv... /bin/mv checking for cp... /bin/cp checking for rm... /bin/rm checking for mkdir... /bin/mkdir checking for touch... /usr/bin/touch checking for diff... /usr/bin/diff checking for grep... /usr/bin/grep checking for sed... /usr/bin/sed checking for sort... /usr/bin/sort checking for uniq... /usr/bin/uniq checking for find... /usr/bin/find checking for latex... /usr/local/texlive/2008/bin/universal-darwin/latex checking for pdflatex... /usr/local/texlive/2008/bin/universal-darwin/pdflatex checking for xdvi... /usr/local/texlive/2008/bin/universal-darwin/xdvi checking for gv... no checking for dvips... /usr/local/texlive/2008/bin/universal-darwin/dvips checking for kpsewhich... /usr/local/texlive/2008/bin/universal-darwin/kpsewhich checking for a texmf tree... /usr/local/texlive/2008/../texmf-local checking for texmf.cnf... yes checking for the polytable package... /usr/local/texlive/2008/texmf-dist/tex/latex/polytable/polytable.sty checking for version of polytable... 0.8.2 checking whether polytable needs to be installed... no checking for mktexlsr... /usr/local/texlive/2008/bin/universal-darwin/mktexlsr configure: creating ./config.status config.status: creating config.mk config.status: creating Version.lhs config.status: creating lhs2TeX.1 config.status: creating doc/InteractiveHugs.lhs config.status: creating doc/InteractivePre.lhs Configuration succesfully completed. Say make to compile and build documentation make bin to compile the binary only make install to (compile and) install [edit happens here, changing Control.Exception to Control.OldException.] bash-3.2$ ./configure bash: ./configure: Permission denied bash-3.2$ sh configure checking for ghc... /usr/bin/ghc checking for hugs... no checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for mv... /bin/mv checking for cp... /bin/cp checking for rm... /bin/rm checking for mkdir... /bin/mkdir checking for touch... /usr/bin/touch checking for diff... /usr/bin/diff checking for grep... /usr/bin/grep checking for sed... /usr/bin/sed checking for sort... /usr/bin/sort checking for uniq... /usr/bin/uniq checking for find... /usr/bin/find checking for latex... /usr/local/texlive/2008/bin/universal-darwin/latex checking for pdflatex... /usr/local/texlive/2008/bin/universal-darwin/pdflatex checking for xdvi... /usr/local/texlive/2008/bin/universal-darwin/xdvi checking for gv... no checking for dvips... /usr/local/texlive/2008/bin/universal-darwin/dvips checking for kpsewhich...
Re: [Haskell-cafe] lifting restrictions on defining instances
wren ng thornton wrote: [1] In System F the capital-lambda binder is used for the term-level abstraction of passing type representations. So for example we have, id :: forall a. a - a id = /\a. \(x::a). x Thus, the forall keyword is serving as the type-level abstraction. Perhaps this is suboptimal syntax, but it is the standard. We could, of course, have both a term-level /\ and a type-level /\ where the latter is the type of the former (since the namespaces are separate) though that's also dubious. Capital-pi is the canonical type-level abstraction, though that evokes the idea of dependent types which are much more complex. What do you mean by type-level abstraction here? In a language with type functions and polymorphism, we need three different lambda binders: (1) abstraction over terms in terms (to construct functions) (2) abstraction over types in terms (to construct polymorphic values) (3) abstraction over types in types (to construct type functions) I think only (2) should be written as upper-case lambdas, while (1) and (3) should both be written as lower-case lambdas. Since (1) and (3) belong to different syntactic categories, they can not be confused, and we can reuse the lower-case lambda at the type-level. Furthermore, we need three function types / kinds to describe the three lambdas one level higher: (4) the type of functions (5) the type of polymorphic values (6) the kind of type functions In ghc, we already have forall for (5), and arrows for (4) and (6). I would say that (3) is the type-level abstraction, not (5). Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
Cale et al, I have a concern about the implementation of the proposed TypeDirectedNameResolution. (I'm not familiar with the internals of any of the compilers, so it could be that my concern isn't well founded.) I'm assuming that name resolution is currently independent of type inference, and will happen before type inference. With the proposal this is no longer true, and in general some partial type inference will have to happen before conflicting unqualified names are resolved. My worry is that the proposal will require a compliant compiler to interweave name resolution and type inference iteratively. Give the Haskell source code: import X import Y import Z a = 1 + (1 :: Integer) b = x a c = y b d = z c . . . Assume X, Y, and Z all export x, y, and z. The compiler might do something like this: (do stuff) Infer type of 'a' Resolve unqualified use of 'x' in x a Infer type of 'b' from b = x a Resolve unqualified use of 'y' in y b Infer type of 'c' from c = y b Resolve unqualified use of 'z' in z c etc. If ambiguous unqualified names are used mutually recursively it may be that there's only one reasonable combination of name resolutions, but is this decidable? To my untrained eye it looks complicated and invasive, even without the mutually recursive case. Can anyone shed light on whether this would be a problem for, say, GHC? Thanks, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Testing nested implication properties with QuickCheck?
How should I you use QuickCheck for testing a property that is a nested implecation such as (A == B) == C ? The problem is (==) in QuickCheck is that its type is Testable prop = Bool - prop - Property rather than Testable prop = prop - prop - Property. So, A == (B == C) would work but (A == B) == C won't work when A, B, C are boolean expressions. Is there some trick to handle the latter? Thanks, -- Ahn, Ki Yung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Testing nested implication properties with QuickCheck?
How should I use QuickCheck for testing a property that is a nested implecation such as (A == B) == C ? The problem is (==) in QuickCheck is that its type is Testable prop = Bool - prop - Property rather than Testable prop = prop - prop - Property. So, A == (B == C) would work but (A == B) == C won't work when A, B, C are boolean expressions. Is there some trick to handle the latter? Thanks, -- Ahn, Ki Yung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Testing nested implication properties with QuickCheck?
2009/7/27 Ahn, Ki Yung kya...@gmail.com: How should I you use QuickCheck for testing a property that is a nested implecation such as (A == B) == C ? You could use the classical equivalence (A == B) = (~A \/ B). I'm not sure you would get very much out of the implication strategy for the nested one, anyway. The problem is (==) in QuickCheck is that its type is Testable prop = Bool - prop - Property rather than Testable prop = prop - prop - Property. So, A == (B == C) would work but (A == B) == C won't work when A, B, C are boolean expressions. Is there some trick to handle the latter? Thanks, -- Ahn, Ki Yung ___ 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] A Question of Restriction
Hello Wouter. I've had a go at the paper linked and perused other references found with Google. Unfortunately, such sophisticated use of the type system is pretty far out of my normal problem domain and I can't see how to apply the techniques presented to my motivating example. Would you be so kind as to elaborate? Thank you, Brian On Mon, Jul 27, 2009 at 2:37 AM, Wouter Swierstraw...@cs.nott.ac.uk wrote: Hi Brian, If I understand you correctly, you've run into the Expression Problem. Phil Wadler posed the problem in a widely-cited e-mail, formulating it much more clearly than I ever could: http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt There are lots of ways to tackle this problem in Haskell - just google Expression Problem Haskell. My (completely biased) personal favourite is: http://www.cse.chalmers.se/~wouter/Publications/DataTypesALaCarte.pdf Hope this helps, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
I would find a third meaning for dot in Haskell just a little bit too many. Especially with hierarchical modules, Haskell encourages writing small modules, or at any rate no larger than they have to be. (SML goes further, of course.) So if we're doing what the software engineering books say (small highly cohesive loosely coupled modules) we should have that much of a name overloading problem in the first place, no? The alias facility for imports, and the practice that has sprung up of using single-letter abbreviations for modules, make the existing practice fairly light-weight. I'm not sure, therefore, that we have a problem that OUGHT to be solved, still less by a method that I find less readable. It seems to me that there's an approach that could be swiped from ML. One of the declaration forms in ML is local private declarations in public declarations end Just as where lets you share a bunch of definitions across a bunch of clauses, so local makes everything in the private declarations visible inside the public declarations but not outside; from the outside only the public declaration can be seen. Waving my hands a bit, this is roughly equivalent to (x1,...,xn) = let private declarations in let public declarations in (x1,...,xn) What has this to do with imports? It means that you can introduce local renamings that can be _shared_ by a group of declarations, while elsewhere in the module, another group of declarations can share different resolutions for the same names. The advantages of that over type directed resolution include - what's happening is visible to the programmer - it's basically ordinary declarations, not some new constraint satisfaction process that has to be interwoven somehow with type inference - that makes life easier for other tools as well - it doesn't overload dot (or my small head) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghci identifier listing question
Hi, in GHCi, after pressing the tab-key, all defined identifiers are listed. If an identifier was redefined, all old and shadowed versions are listed, too. Is it possible, to reach the (shadowed) values in any way? Another question: Is it possible to show only those identifiers that are defined during the interactive session? I only can list all identifiers which start with a given prefix, but I would like to know if GHCi can show me all identifiers defined in a given module or in the current session (by pressing Tab or alike). Best regards, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: 20 years ago
On Jul 27, 2009, at 6:30 PM, Benjamin L.Russell wrote: Incidentally, just for the record, in response to my forwarding your claim, Alan Kay, the inventor of Smalltalk, just refuted your refutation [1] (see http://lists.squeakfoundation.org/pipermail/beginners/2009-July/006331.html) ; _viz._: If you read carefully what he wrote there, it doesn't actually contradict what I said. (For what it's worth, I _have_ read a good deal of Alan Kay's writings.) Molecular biology may very well have been an influence on Alan Kay, but there are no traces of it in Smalltalk. The concepts of Smalltalk have their roots in Lisp, including the original version using nil as false, and the meta-circular interpreter. Sketchpad and Simula also have no trace of biology in them. As for the claim that Smalltalk had its roots in Lisp, this is not my opinion. It's straight from the horse's mouth. Visit http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_IV.html whose title is The first real Smalltalk, and you will read this paragraph: I had orignally made the boast because McCarthy's self-describing LISP interpreter was written in itself. It was about a page, and as far as power goes, LISP was the whole nine-yards for functional languages. I was quite sure I could do the same for object-oriented languages plus be able to do a resonable syntax for the code a loa some of the FLEX machine techiques. [Errors in the page.] So clearly Alan Kay _was_ influenced by Lisp, and the initial Smalltalk-72 implementation _was_ influenced by the Lisp meta-circular interpreter. While we're on that page, here are the six core principles: 1. Everything is an object [Where's the biology in that? Rocks are objects.] 2. Objects communicate by sending and receiving messages (in terms of objects) [Where's the biology in that? Sounds more like the telephone system. And when organisms send messages to other organisms, those messages are not themselves organisms, although that might make a neat gimmick for a science fiction story.] 3. Objects have their own memory (in terms of objects) [Many organisms have memory. But their memories are not themselves organisms. Again that might make a nice science fiction gimmick, and Brin's hydrogen breathers in the Uplift series come close. Not in THIS biology though.] 4. Every object is an instance of a class (which must be an object) [Maybe here's the biology? But no, Simula 67 had single-inheritance classes, with never a trace of biology. There's certainly no biology-talk in the Simula Common Base manual that I can find. Again, in THIS biology, a taxon is not itself an organism, so if anything, Smalltalk is contradicting biology.] 5. The class holds the shared behavior for its instances (in the form of objects in a pogram list) [Errors in the page. Where's the biology here? Organisms behave, but their behaviour isn't made of organisms held in another organism. Class as site of shared behaviour is straight Simula (and of course other sources).] 6. To eval a program list, control is passed to the first object and the remainder is treated as its message [Does that look like biology to you?] A PDF of the whole thing is http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf But how important is that paper anyway? (1) It's by Alan Kay. (2) It's his official history of Smalltalk. (3) It actually says on the second page I will try to show where most of the influences come from. It's true that the abstract speaks of a more biological scheme of protected universal cells interacting only through messages that could mimic any desired behavior, but that's basically _it_ for biology, if we are to believe Kay, and even then, its semantics are a bit like having thousands of and thousands of comptuers all hooked together by a very fast network and Philosophically, Smalltalk's objects have much in common with the monads of Leibnitz (bringing us neatly back to Haskell (:-)). We read The biggest hit for me while at SAIL in late '69 was to _really understand_ Lisp. By the way, Haskell programmers should really appreciate the anecdote on page 13 about programming odds_evens x = odds x ++ evens x where odds []= [] odds (x:xs)= x : evens xs evens (_:x:xs) = x : evens xs evens _= []. It took him about 5 seconds to do about that way, while it took Allen Newell 30 minutes to not quite solve. At any rate, the paper which is supposed to trace most of the influences doesn't link even *one* idea in Smalltalk to biology. The influences are other programming languages, notably Lisp, Simula, and the ever-famous Sketchpad system, philosophy, programming, computer networks, ... As for the biological nature of message passing, the paper says (p50) An
Re: [Haskell-cafe] Re: [Haskell] Re: 20 years ago
On 28/07/2009, at 11:35 AM, Richard O'Keefe wrote: It's true that the abstract speaks of a more biological scheme of protected universal cells interacting only through messages that could mimic any desired behavior, but that's basically _it_ for biology, if we are to believe Kay, and even then, its semantics are a bit like having thousands of and thousands of comptuers all hooked together by a very fast network and Philosophically, Smalltalk's objects have much in common with the monads of Leibnitz (bringing us neatly back to Haskell (:-)). But Richard (or am I arguing with Kay?) - monads don't interact. http://en.wikipedia.org/wiki/Monadology I'd take that to be their defining characteristic - Leibniz is trying to overcome Cartesian mind/body dualism here. Perhaps Smalltalk objects are regulated by pre-established harmonies... and have no need to talk to each other. Or perhaps that is the part that lies outside Kay's identification, in which case one might say the ontologies of monads and Smalltalk have superficial similarities but the deeper structure diverges significantly. (I think my point is well-defended by the above wikipedia article - the OO insights are thin on the ground, and are at least quite tangled.) How are you going to relate Leibniz's monads and Haskell's? I can't find my way, neatly or otherwise. :-P Ah, I see, Haskell has an interface to the best of all possible worlds... :-) cheers peter -- http://peteg.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cabal: : openFile: does not exist (No such file or directory)
I tried updating to ghc-6.10.4 and have exactly the same error. Also ghc doesn't seem to be able to find any of the haskell platform packages, even though it ghc-pkg finds them just fine. For example (trimmed for brevity): ghc-pkg list /usr/local/lib/ghc-6.10.4/./package.conf: Cabal-1.6.0.3, ... parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, ... ghci -v readModel.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/local/lib/ghc-6.10.4/./package.conf ... readModel.hs:9:7: Could not find module `Text.Parsec.Language': locations searched: Text/Parsec/Language.hs Text/Parsec/Language.lhs Failed, modules loaded: none. ... ghc-pkg finds parsec, but ghci can't find it. And if I do a cabal -v3 update I get a: cabal: 3: openFile: does not exist (No such file or directory) Anybody figured it out? - Job Vranish On Fri, Jul 17, 2009 at 11:17 AM, Thomas Hartman tphya...@gmail.com wrote: cabal -v3 update will give you a more verbose version of what is going wrong. cabal --help regrettably, cabal --help doesn't tell you this but there is always the man page I suppose. 2009/7/16 Tony Hannan tonyhann...@gmail.com: Hello, I'm on Ubuntu 8.10. I installed ghc 6.10.4 (from binary package: ghc-6.10.4-i386-unknown-linux-n.tar.bz2). I installed haskell-platform-2009.2.0.1 (from source package: haskell-platform-2009.2.0.1.tar.gz). It contains cabal-install-0.6.2. Then when I run cabal update, I get the following error: cabal: : openFile: does not exist (No such file or directory) Any ideas? Thanks, Tony ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ 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] Re: 20 years ago
On Jul 28, 2009, at 2:25 PM, Peter Gammie wrote: But Richard (or am I arguing with Kay?) - monads don't interact. You're arguing with Alan Kay here: the reference to Leibniz was his. The key link here is (Wikipedia): Leibniz allows just one type of element in the build of the universe (sic.). In precisely the same way, Alan Kay allowed just one kind of 'thing' in his computational universe: object. Just as in the lambda calculus, everything is a function and in set theory everything is a set, so in Smalltalk _everything_ (including classes and the number 42 and anonymous functions) is an object. How are you going to relate Leibniz's monads and Haskell's? I can't find my way, neatly or otherwise. :-P Verbally. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: 20 years ago
On 28/07/2009, at 12:59 PM, Richard O'Keefe wrote: On Jul 28, 2009, at 2:25 PM, Peter Gammie wrote: But Richard (or am I arguing with Kay?) - monads don't interact. You're arguing with Alan Kay here: the reference to Leibniz was his. The key link here is (Wikipedia): Leibniz allows just one type of element in the build of the universe (sic.). In precisely the same way, Alan Kay allowed just one kind of 'thing' in his computational universe: object. Just as in the lambda calculus, everything is a function and in set theory everything is a set, so in Smalltalk _everything_ (including classes and the number 42 and anonymous functions) is an object. Yea gods, that's the thinnest use of monads ever. The concept that lead to idealism, away from mind-body dualism is reduced to ... monism. Awesome. http://en.wikipedia.org/wiki/Monism He could've cited just about any of the major philosophies for that - and I'm not going to talk about religions. How are you going to relate Leibniz's monads and Haskell's? I can't find my way, neatly or otherwise. :-P Verbally. Sure, but I was hoping you'd explain why Wadler uses the pineal gland allusions in his COMPREHENDING MONADS (capitals denoting paper title). That structure was *exactly* what Leibniz was doing his best to avoid in his monadology. I think Wadler was making a joke. cheers peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Importing Control.Arrow changes inferred type of (m = f) x in ghci
The following inferred type has a constraint that can be trivially satisfied, but isn't: Control.Monad :t \ (m,f,x) - (m = f) x \ (m,f,x) - (m = f) x :: forall t a b. (Monad ((-) t)) = (t - a, a - t - b, t) - b -- In Control.Monad there is forall t. instance Monad ((-) t), -- so why is the vacuous Monad constraint still there? -- Nor can I remove it with a type annotation: Control.Monad :t \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b interactive:1:13: Inferred type is less polymorphic than expected [snip] -- Then if I just import a module: Control.Monad :m + Control.Arrow -- Now, the Monad ((- t) constraint disappears: Control.Monad Control.Arrow :t \ (m,f,x) - (m = f) x \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b -- Although it still will not accept an explicit type annotation: Control.Monad Control.Arrow :t \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b interactive:1:13: Inferred type is less polymorphic than expected [snip] Is there some explicit kind annotation I can/should give to get the most general type? Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Importing Control.Arrow changes inferred type of (m = f) x in ghci
On Mon, Jul 27, 2009 at 7:58 PM, Dan Westonweston...@imageworks.com wrote: The following inferred type has a constraint that can be trivially satisfied, but isn't: Control.Monad :t \ (m,f,x) - (m = f) x \ (m,f,x) - (m = f) x :: forall t a b. (Monad ((-) t)) = (t - a, a - t - b, t) - b -- In Control.Monad there is forall t. instance Monad ((-) t), -- so why is the vacuous Monad constraint still there? -- Nor can I remove it with a type annotation: That instance is in the annoying module Control.Monad.Instances. Control.Monad :t \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b interactive:1:13: Inferred type is less polymorphic than expected [snip] -- Then if I just import a module: Control.Monad :m + Control.Arrow Presumably it is also here. -- Now, the Monad ((- t) constraint disappears: Control.Monad Control.Arrow :t \ (m,f,x) - (m = f) x \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b -- Although it still will not accept an explicit type annotation: Control.Monad Control.Arrow :t \ (m,f,x) - (m = f) x :: forall t a b. (t - a, a - t - b, t) - b This is just because :: binds tighter than lambda, I think: :t (\(m,f,x) - (m = f) x) :: forall t a b. (t - a, a - t - b, t) - b typechecks just fine. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
