Re: [Haskell-cafe] Cabal: error on configure
On Tue, 2008-10-07 at 15:50 -0400, David Barton wrote: OK, I suspect this is a real newbie error, but please have mercy. I have downloaded and installed cabal (at least it responds to the --help command from the command line). Yet when I do, say (to give a real example): cabal configure parameterized_ data (having done he fetch) I get this error: cabal.exe: Using 'build-type Custom' but there is no Setup.hs or Setup.lhs script.' When I download the package manually and look, there is a perfectly servicable Setup.hs script, which I call manually. So what gives? You mean to run: cabal install parameterized-data cabal configure expects to be run inside the build tree. It's looking for a Setup.hs in the current directory. The configure command is for developers working with their own packages locally, rather than for working with released packages directly from hackage. There are basically two sets of commands, those for working with released packages by name, and those for working with a local package in the current directory. I'll tried to make that clearer in the cabal-install README, and perhaps in the --help output in future. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with package consistency on Hackage
Folks, I'm not sure who to email about this, but hopefully someone on the cafe knows: On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See: http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8 If I wait will Hackage eventually become consistent? How does this work? Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [] vs [()]
(This is a literate haskell post, save into SMM.lhs and load in ghci!) Here's one place you might use [()] and []: guard :: Bool - [()] guard True = [()] guard False = [] You can then use guard in monadic list computations to abort the computation on some branches: sendmoney :: [[Int]] sendmoney = do [EMAIL PROTECTED],e,n,d,m,o,r,y] - generate 8 [0..9] guard (s /= 0) guard (m /= 0) guard (val [s,e,n,d] + val [m,o,r,e] == val [m,o,n,e,y]) return choice (evaluating this in ghci takes a little while, but it does succeed! You can easily optimize by noticing that m must be equal to 1 and therefore s must be 8 or 9.) Using guard in this way works because of the definition of bind on lists: xs = f = concatMap f xs = concat (map f xs) Consider a simpler example: simple = do x - [1,2,3] guard (x /= 2) return x This is the same as [1,2,3] = \x - guard (x /= 2) = \_ - return x = mapConcat (\x - mapConcat (\_ - return x) (guard (x /= 2))) [1,2,3] = concat [ mapConcat (\_ - return 1) (guard (1 /= 2)) , mapConcat (\_ - return 2) (guard (2 /= 2)) , mapConcat (\_ - return 3) (guard (3 /= 2)) ] = concat [ mapConcat (\_ - return 1) [()] , mapConcat (\_ - return 2) [] , mapConcat (\_ - return 3) [()] ] = concat [ concat [ [1] ] , concat [] , concat [ [3] ] ] = concat [ [1], [], [3] ] = [1,3] Another fun example: double :: [()] double = [(), ()] sixteen:: Int sixteen = length $ do double double double double Helper code for send more money follows... generate :: Int - [a] - [[a]] generate 0 _ = return [] generate n as = do (x,xs) - select as rest - generate (n-1) xs return (x:rest) select :: [a] - [(a,[a])] select [] = [] select [x] = return (x,[]) select (x:xs) = (x,xs) : [ (y, x:ys) | (y,ys) - select xs ] val xs = val' 0 xs where val' v [] = v val' v (x:xs) = val' (10*v + x) xs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Great! Are there any chances of getting support for non-Win32 platforms with Mono? On Fri, Oct 10, 2008 at 2:12 PM, Andrew Appleyard [EMAIL PROTECTED] wrote: I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ 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] Functional progarmming at JAOO
Hi Simon, Thanks for link! I attended JAOO and there were some great talks on programminng langauges, I really enjoyed Guy Steele's introduction to Fortres and Eric Meijer's Fundamentalist Functional Programming, as well as Anders Hejlsberg's talk, and there were also talks on Scala and F#. I've not been to that many confrences but I all the same I judged this to be a unusally high interester in programming languages for an industrial conference. I got a real fealing that people are much more read to look at alterative languages for their projects, I think this can only be good for haskell and the wider FP community in general. Thanks,Robert From: Simon Peyton-Jones [EMAIL PROTECTED] Sent: 09 October 2008 20:55 To: haskell-cafe@haskell.org haskell-cafe@haskell.org Subject: [Haskell-cafe] Functional progarmming at JAOO Friends Anders Hejlsberg, the chief designer of C# and a very influential person at Microsoft, gave a keynote talk at JAOO Aarhus last week about Where are programming languages going. Some of you may have mixed feelings about Microsoft but I thought you might still be interested in this talk because he gives a strong plug to functional programming (and F# in particular, although Haskell gets a mention). FP is one of the three major trends he identifies, the others being concurrency and dynamic languages. http://blip.tv/file/1317881 The FP section starts 22 mins in. Simon ___ 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] Re: Problem with package consistency on Hackage
Antoine Latter wrote: Folks, I'm not sure who to email about this, but hopefully someone on the cafe knows: On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See: http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8 If I wait will Hackage eventually become consistent? How does this work? You can re-compile parsec and binary to depend on bytestring-0.9.1.3. Alternatively, use cabal-install which knows how to rebuild things to avoid consistency problems like this. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal: error on configure
On Tue, Oct 7, 2008 at 9:50 PM, David Barton [EMAIL PROTECTED] wrote: OK, I suspect this is a real newbie error, but please have mercy. I have downloaded and installed cabal (at least it responds to the --help command from the command line). Yet when I do, say (to give a real example): cabal configure parameterized_ data It's great to read that you are using the parameterized-data package. If you have any questions on its use, or have any suggestions, don't hesitate to ask. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: darcs 2.1.0 (corrected!)
2008/10/9 Eric Kow [EMAIL PROTECTED]: Hi all, I am delighted to announce the release of darcs 2.1.0, available at http://darcs.net/darcs-2.1.0.tar.gz Yay! Ubuntu packages at the usual place: https://launchpad.net/~laney/+archive Note that I inadvertently messed up the version numbering for the prerelease versions (2.1.0preX 2.1.0 according to dpkg; I should have used 2.1.0~preX), so apt will not consider the official 2.1.0 packages as being newer than this one. For this reason, I'll attempt to track the official packages with my numbering scheme when they appear until such a time as 2.1.1 is released. My apologies for any inconvenience. Thanks to the Debian team for providing the initial packaging. Iain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [] vs [()]
What is the difference between empty list [] and list with one unit element [()]? Or, yet: ():[()] --is legal 10:[()] --is not One list can contain elements of a single type. Since the type of () is () (element constructors and types are allowed to have the same name), a list of type [()] can only contain elements of type (), i.e., ()s. Try this is ghci: :t [()] :t [(),(),(),()] Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: maccatcher-1.0.0
Jason Dusek jason.dusek at gmail.com writes: This simple little package obtains a MAC address on *NIX and Windows. It is known to work on Linux, OS X and Windows XP. There is no C fanciness in this package -- it relies on shell commands. The MAC is cached after the first query, using an IORef (I am open to other ideas, but this seemed sufficient). -- _jsn Hi I notice that this only prints one MAC address. Some people have more than one network interface, wouldn't it be better to show all of them? Also, on my system I need to run `ifconfig -a` to show all interfaces since it defaults to showing only interfaces which are up. Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
This could be a game changer. Great work Andrew!! -- Don andrew.appleyard: I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ 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] [] vs [()]
On Fri, 2008-10-10 at 10:59 -0700, Daryoush Mehrtash wrote: I was in fact trying to figure out how guard worked in the do. The interesting (for a beginner) insight is that: [()] map f = [f] I don't think any clarity is added by made-up notation. I think you mean map f [()] = [f ()] or [()] = f = f () or [()] f = f or do [()] f = f or [ f | _ - [()] ] = [ f ] --( just as any list with one element would have been such as [1] map f = [f] ) where as [] map f = [] And map f [] = [] or [] = f = [] or [] f = [] or do [] f = [] or [ f | _ - [] ] = [] jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote: I think it's just the teaching of the language that needs work, not so much the language itself. As a newer user myself, I'd agree with this statement. I'd like to see far more mundane tasks solved in tutorials. The number of times building a parser or generating prime number is used as an example is out of proportion to the times you'd use these things[1]. Just simple, *really* easy things would be better. Maybe it's just me, but if I wanted to learn perl or ruby or python or C# I'm not sure I'd ever see a _tutorial_ containing a prime number. Haskell is can obviously do some really interesting things, but constantly having wikipedia open so I can look up whatever mathematical doodah has just been mentioned can get draining. Even Real World Haskell suffers a bit from this. Iain [1] In years of programming (other languages) I've never had to generate my own primes or build a compiler or a parser. I may have parsed things, but that's different to building an entire parser, if you get my drift. Actually, tell a lie. I have built a parser, but it's still not stuff for a beginner's tutorial IMHO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote: On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote: I think it's just the teaching of the language that needs work, not so much the language itself. As a newer user myself, I'd agree with this statement. I'd like to see far more mundane tasks solved in tutorials. The number of times building a parser or generating prime number is used as an example is out of proportion to the times you'd use these things[1]. Just simple, *really* easy things would be better. Maybe it's just me, but if I wanted to learn perl or ruby or python or C# I'm not sure I'd ever see a _tutorial_ containing a prime number. Haskell is can obviously do some really interesting things, but constantly having wikipedia open so I can look up whatever mathematical doodah has just been mentioned can get draining. Even Real World Haskell suffers a bit from this. Iain [1] In years of programming (other languages) I've never had to generate my own primes or build a compiler or a parser. I may have parsed things, but that's different to building an entire parser, if you get my drift. Actually, tell a lie. I have built a parser, but it's still not stuff for a beginner's tutorial IMHO. In Haskell it is. Parsec makes recursive descent parsers as easy to use in Haskell as regexps are in Perl. No reason not to expose newcomers to Haskell to the thing it does best. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [] vs [()]
I don't think any clarity is added by made-up notation. I think you mean In fact I was trying to be correct on this. Is it wrong to show: [()] f = f as was doing: [()] map f = [f] I want to say map function f over a single element list will yield a list of single element, the element being function f. daryoush On Fri, Oct 10, 2008 at 10:56 AM, Jonathan Cast [EMAIL PROTECTED]wrote: On Fri, 2008-10-10 at 10:59 -0700, Daryoush Mehrtash wrote: I was in fact trying to figure out how guard worked in the do. The interesting (for a beginner) insight is that: [()] map f = [f] I don't think any clarity is added by made-up notation. I think you mean map f [()] = [f ()] or [()] = f = f () or [()] f = f or do [()] f = f or [ f | _ - [()] ] = [ f ] --( just as any list with one element would have been such as [1] map f = [f] ) where as [] map f = [] And map f [] = [] or [] = f = [] or [] f = [] or do [] f = [] or [ f | _ - [] ] = [] jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote: On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote: In Haskell it is. Parsec makes recursive descent parsers as easy to use in Haskell as regexps are in Perl. No reason not to expose newcomers to Haskell to the thing it does best. jcc Regex tends to come after things like basic I/O, even in Perl. I've got a Haskell book here (Hutton, 170 pages) that doesn't even mention how to open a file! Just because it can be done, or it's easy(ier) doesn't mean that's where you should start. Iain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [] vs [()]
I was in fact trying to figure out how guard worked in the do.The interesting (for a beginner) insight is that: [()] map f = [f] --( just as any list with one element would have been such as [1] map f = [f] ) where as [] map f = [] so if your guard computes to [()] (or any list of one element) the following steps in the do would continue. Where as if it computes to an empty list then following steps are not executed. daryoush On Fri, Oct 10, 2008 at 6:33 AM, Ryan Ingram [EMAIL PROTECTED] wrote: (This is a literate haskell post, save into SMM.lhs and load in ghci!) Here's one place you might use [()] and []: guard :: Bool - [()] guard True = [()] guard False = [] You can then use guard in monadic list computations to abort the computation on some branches: sendmoney :: [[Int]] sendmoney = do [EMAIL PROTECTED],e,n,d,m,o,r,y] - generate 8 [0..9] guard (s /= 0) guard (m /= 0) guard (val [s,e,n,d] + val [m,o,r,e] == val [m,o,n,e,y]) return choice (evaluating this in ghci takes a little while, but it does succeed! You can easily optimize by noticing that m must be equal to 1 and therefore s must be 8 or 9.) Using guard in this way works because of the definition of bind on lists: xs = f = concatMap f xs = concat (map f xs) Consider a simpler example: simple = do x - [1,2,3] guard (x /= 2) return x This is the same as [1,2,3] = \x - guard (x /= 2) = \_ - return x = mapConcat (\x - mapConcat (\_ - return x) (guard (x /= 2))) [1,2,3] = concat [ mapConcat (\_ - return 1) (guard (1 /= 2)) , mapConcat (\_ - return 2) (guard (2 /= 2)) , mapConcat (\_ - return 3) (guard (3 /= 2)) ] = concat [ mapConcat (\_ - return 1) [()] , mapConcat (\_ - return 2) [] , mapConcat (\_ - return 3) [()] ] = concat [ concat [ [1] ] , concat [] , concat [ [3] ] ] = concat [ [1], [], [3] ] = [1,3] Another fun example: double :: [()] double = [(), ()] sixteen:: Int sixteen = length $ do double double double double Helper code for send more money follows... generate :: Int - [a] - [[a]] generate 0 _ = return [] generate n as = do (x,xs) - select as rest - generate (n-1) xs return (x:rest) select :: [a] - [(a,[a])] select [] = [] select [x] = return (x,[]) select (x:xs) = (x,xs) : [ (y, x:ys) | (y,ys) - select xs ] val xs = val' 0 xs where val' v [] = v val' v (x:xs) = val' (10*v + x) xs Weblog: http://perlustration.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [] vs [()]
On Fri, 2008-10-10 at 11:14 -0700, Daryoush Mehrtash wrote: I don't think any clarity is added by made-up notation. I think you mean In fact I was trying to be correct on this. Great! Is it wrong to show: [()] f = f as was doing: [()] map f = [f] Yes. Juxtaposition is always application in Haskell, and is always left-associative, and binds more tightly than any other operator. So your left-hand side means [()] applied to two arguments, map and f. This is not legal Haskell, because [()] is not a function. You intended to apply the function map to two arguments, f and [()]. The notation for that is map f [()] so, making that change, you get map f [()] = [f] This is still wrong: map :: (a - b) - [a] - [b] so if f :: (() - b) then map f [()] :: [b] but if f :: (() - b) then [f] :: [() - b] Unification of these types (required for an equation between the two terms) proceeds as follows: [b] = [() - b] so b = () - b But the unifier doesn't have a rule to solve recursive equations on types like the above; so unification fails; your rule isn't even well-typed. The correct rule is map f [()] = [f ()] where f () :: b so [f ()] :: [b] so everything type-checks. () is different from map in three ways: (1) The arguments are in a different order. It's a minor issue, but of course you have to get it right. (2) is an infix operator (syntactically distinct from functions: map and () are functions while `map` and are infix operators). So you can use it in the middle of your left-hand side. (2) () has some subtle differences from map. The definitions are, roughly: map f xn = xn = \ x - return (f x) xn ys = xn = \ x - ys map does something interesting with the elements of its argument list: it passes them to the function f (it also builds a list of the result, which () leaves to its second argument). () just ignores those elements. This difference is reflected by the types, as well: map :: (a - b) - [a] - [b] The type variable `a' appears twice, so in (map f xn) you know the argument to f and the elements of xn are related (in some way). () :: [a] - [b] - [b] The type variable `a' appears only once, so in (xn ys) the elements of xn are just ignored; only the list structure matters. I want to say map function f over a single element list will yield a list of single element, the element being function f. Haskell does distinguish between a function and the result of applying that function to an argument, so the element *isn't* actually f --- it's the result of applying f to an argument. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell in Artificial Intelligence
Greetings, I'm interested in doing a survey about the use of Haskell in the field of Artificial Intelligence. I searched in Google, and found in the HaskellWiki, at www.haskell.org/haskellwiki/Haskell_in_industry, two organizations that use Haskell and do work related to AI. Besides that, I haven't found much else. Could somebody from the Haskell community give me some pointer to a project or system related to AI that uses Haskell? Thank you very much in advance. - CC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
This could be a game changer. Great work Andrew!! Totally agreed, on both accounts. Really interesting to see. -- Don What, no Arch Linux port? :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Don Stewart wrote: This could be a game changer. In what way? As far as I'm aware, .NET never really caught on and has long since become obsolete. Or do you just mean the type system machinery that has been developed could be used for other projects? Great work Andrew!! Yes indeed. I'm looking at the thesis now. It looks rather interesting... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
.NET never really caught on and has long since become obsolete. Oh, if only this was the case. :( You wouldn't believe the things I have to make .NET run on (but I can't talk about it... yay for NDAs). /jve On Fri, Oct 10, 2008 at 3:48 PM, Andrew Coppin [EMAIL PROTECTED]wrote: Don Stewart wrote: This could be a game changer. In what way? As far as I'm aware, .NET never really caught on and has long since become obsolete. Or do you just mean the type system machinery that has been developed could be used for other projects? Great work Andrew!! Yes indeed. I'm looking at the thesis now. It looks rather interesting... ___ 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] Interesting new user perspective
Iain Barnett wrote: On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote: I think it's just the teaching of the language that needs work, not so much the language itself. As a newer user myself, I'd agree with this statement. I'd like to see far more mundane tasks solved in tutorials. I would agree as well. My own flailings led to Software Tools in Haskell[1], which taught me more about how to actually do things[2] than the textbooks that I have read. Haskell is can obviously do some really interesting things, but constantly having wikipedia open so I can look up whatever mathematical doodah has just been mentioned can get draining. Even Real World Haskell suffers a bit from this. The mathematical doodahs are *very* useful, much more so than any other language I have used, but it helps to have some kind of foundation to understand how and why. I am frequently reminded of a How to Draw page from the Tick[3] comic, which went something like: Step 1: Draw a large oval. Step 2: Draw the Tick holding the oval. On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote: Parsec makes recursive descent parsers as easy to use in Haskell as regexps are in Perl. No reason not to expose newcomers to Haskell to the thing it does best. Is it wrong to use Parsec to parse regular expressions for a really simple regex engine[4]? [1] http://www.crsr.net/Programming_Languages/SoftwareTools/index.html [2] Even if it is the wrong way. :-) [3] http://en.wikipedia.org/wiki/The_Tick [4] http://www.crsr.net/Programming_Languages/SoftwareTools/ch6.html The engine itself is in Ch. 5. -- Tommy M. McGuire [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Andrew Coppin wrote: Don Stewart wrote: This could be a game changer. In what way? As far as I'm aware, .NET never really caught on and has long since become obsolete. Wha? Microsoft's programming languages all now depend on and compile to .NET runtime (the CLR), including C#, Managed C++, Visual BASIC, and even things like the Haskell competitor F#. Hence Don's comment. I've heard people at more than one company say that if they could access .NET well from Haskell, they wouldn't be as interested in F#. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 15:00 -0500, Tommy M. McGuire wrote: On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote: Parsec makes recursive descent parsers as easy to use in Haskell as regexps are in Perl. No reason not to expose newcomers to Haskell to the thing it does best. Is it wrong to use Parsec to parse regular expressions for a really simple regex engine[4]? That looks about right. And, as you point out, it's easier to understand than a direct parser. I would also re-code the engine itself in Parsec, though (probably using a finite state machine implementation, which (I think; I haven't tried it yet) would end up looking rather like a manual unfolding along the lines of Koen Claessen's parallel parsing process [1]). jcc [1] http://www.cs.chalmers.se/~koen/Papers/parsing-pearl.ps ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
jason.dusek: Tommy M. McGuire [EMAIL PROTECTED] wrote: Is it wrong to use Parsec to parse regular expressions for a really simple regex engine[4]? I sometimes think it is better, from a maintainability standpoint, to just use Parsec for all that stuff and forget about regular expressions. There are many proficient application programmers and system programmers who are unfamiliar with regexen which, even if they weren't arcane, are still so balkanized. At first, I found writing Parsec for argument/option processing to be almost offensive -- so many lines for so little action! -- but it's clear as day to a lot of people and that is a real mark in its favor. And for true regular expression problems, we have regex libs, dozens. They're just not the only tool for text manipulation, and Haskell makes constructing true parsers just as easy, so may as well do it right, and do it well. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] synchronous channels in STM
roger peppe wrote: By the way, where does FRP (which I haven't got my head around yet) sit with respect to STM? Entirely orthogonal. FRP is not generally thought of as (explicitly) threaded at all. It's more declarative than that. It's also supposed to be deterministic (up to the determinism of input events) which STM is not. However an elegant, efficient, implementation of FRP in pure haskell evades us, so people discuss different ways to implement it which use, possibly, concurrency such as STM or otherwise, under the hood. So STM may or may not be a good tool to implement FRP, but at the level that you *use* FRP, any threading should be entirely implicit. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
Tommy M. McGuire [EMAIL PROTECTED] wrote: The mathematical doodahs are *very* useful, much more so than any other language I have used, but it helps to have some kind of foundation to understand how and why. I am frequently reminded of a How to Draw page from the Tick[3] comic, which went something like: http://i36.tinypic.com/wlcghf.jpg -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote: No reason not to expose newcomers to Haskell to the thing it does best. This is precisely why newcomers flounder. Yes, there certainly should be a Haskell for experienced Java/C++ programmers : All of the advanced things you can do more easily than you ever thought possible. But that's not the way to attract Joe Programmer, who has never had to write a parser. Joe Programmer needs to be shown how Haskell can solve _his_ problems. That might mean that you need to start with an extremely non-idiomatic Haskell program, one that has some of the look and feel of what programmers from other languages are comfortable with. And then transform that program, step-by-step, into something that takes advantage of Haskell's strengths. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Anton van Straaten wrote: I've heard people at more than one company say that if they could access .NET well from Haskell, they wouldn't be as interested in F#. Mmm, I could see how that would work... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 22:24 +0100, Iain Barnett wrote: On 10 Oct 2008, at 9:00 pm, Tommy M. McGuire wrote: Iain Barnett wrote: On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote: I think it's just the teaching of the language that needs work, not so much the language itself. As a newer user myself, I'd agree with this statement. I'd like to see far more mundane tasks solved in tutorials. I would agree as well. My own flailings led to Software Tools in Haskell[1], which taught me more about how to actually do things[2] than the textbooks that I have read. That looks like a really useful resource, thanks. I've just read the introduction and that is the same experience I've been having, (ending up with bits of programs and nothing really practical). I'm currently trying to write some simple games in Haskell, and learning a lot along the way. Haskell is can obviously do some really interesting things, but constantly having wikipedia open so I can look up whatever mathematical doodah has just been mentioned can get draining. Even Real World Haskell suffers a bit from this. The mathematical doodahs are *very* useful, much more so than any other language I have used, but it helps to have some kind of foundation to understand how and why. I am frequently reminded of a How to Draw page from the Tick[3] comic, which went something like: Yep. They're certainly useful, it's just that explanation and knowledge aren't always the fastest route to understanding. Sometimes it's better just to get on with things and just do it - you don't learn how to drive by getting lessons on the combustion engine from a physicist :) On 10 Oct 2008, at 9:50 pm, Don Stewart wrote: Haskell makes constructing true parsers just as easy, You're not speaking for me there! :) I really like regex. It's a domain specific functional language, so why rewrite the wheel? It's a domain-specific *declarative* language. Turning it into a true functional language makes it something entirely different. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
Steve Schafer wrote: On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote: No reason not to expose newcomers to Haskell to the thing it does best. This is precisely why newcomers flounder. Yes, there certainly should be a Haskell for experienced Java/C++ programmers : All of the advanced things you can do more easily than you ever thought possible. But that's not the way to attract Joe Programmer, who has never had to write a parser. Joe Programmer needs to be shown how Haskell can solve _his_ problems. That might mean that you need to start with an extremely non-idiomatic Haskell program, one that has some of the look and feel of what programmers from other languages are comfortable with. And then transform that program, step-by-step, into something that takes advantage of Haskell's strengths. Seconded. On the one hand, Haskell makes difficult things easy, and impossible things possible. This is what's cool about the language. On the other hand, an introductory text ought to start with something simpler and _more familiar_ to get people used to the language first. Haskell is a simple language, but there's an awful lot of new stuff to learn - new language rules, and new techniques for structuring your code, and even *thinking about* what code is. And another problem. I've written a few intro to Haskell documents myself. These almost always end up degenerating into an exercise in tripping over myself trying to explain everything all at once. Haskell has a lot of very cool stuff in it. There are lots of things you need to know to use it though. The things are all pretty simple, but they're all so inter-related that it's difficult figuring out where to start. Countless times I've written an example to demonstrate feature X, and then realise oh, wait, that requires features Y, Z, K, W, B, M and J which I haven't mentioned yet... It seems no matter how many permutations you go through, you always end up with this problem. No matter where you start with the language! Maybe I need to sit down and draw a directed graph of related topics and then perform a topological sort or something. ;-) I sat down to read Real World Haskell today. The introduction was great (although it seems to promise far too much). Chapter 1 is really solid. But then Chapter 2... seemed to be a fairly unstructured tangle of features and concepts all dumped on the reader at once. Like, this is how if/then/else works, oh, but that example program is recursive, so this is how recursion works, oh, but that's lazy, so this is what thunks are... I can just imagine anybody reading all this going wuh? Slow down! OTOH, it's easy to criticise what somebody else wrote. Much harder to write something better yourself... :-/ PS. I'm curios to see what happens when the book gets to the interesting stuff. The intro seems to promise that Haskell has libraries for all kinds of cool stuff - database access, sound, etc. But IME it isn't true. I have tried and tried to make accessing a database work from Haskell; the necessary libraries simply refuse to compile. Ditto for sound. I yearn to do intricate DSP stuff in Haskell, but none of the sound-related libraries will compile for me. (The libsdl binding even comes with a specially-prepaired Windows package - which doesn't work.) I want to see what the hell everybody else is doing differently that makes this stuff actually work for them when it fails miserably for me! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 19:27 +0100, Iain Barnett wrote: On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote: On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote: In Haskell it is. Parsec makes recursive descent parsers as easy to use in Haskell as regexps are in Perl. No reason not to expose newcomers to Haskell to the thing it does best. jcc Regex tends to come after things like basic I/O, even in Perl. Why would I want to do I/O, when I don't know how to do anything interesting with the input yet, or how to generate interesting output? I think the `I/O comes first' attitude is *precisely* the difference between mainstream programmers and Haskellers. The goal should be to create more Haskellers, not just more people whose code happens to be accepted by GHC. I've got a Haskell book here (Hutton, 170 pages) that doesn't even mention how to open a file! That short, and you expect minor features like that (that not every program even needs) to be squeezed in? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, Oct 10, 2008 at 2:31 PM, Jonathan Cast [EMAIL PROTECTED] wrote: On Fri, 2008-10-10 at 17:13 -0400, Steve Schafer wrote: On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote: No reason not to expose newcomers to Haskell to the thing it does best. This is precisely why newcomers flounder. Newcomers flounder because they expect to keep programming the same way they always have. They should be (and *are*) taught better ways of doing things. http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem is a brilliant example of a common workaday problem found in other languages, and solved elegantly in Haskell martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interesting new user perspective
[4] http://www.crsr.net/Programming_Languages/SoftwareTools/ch6.html Hi Tommy, I had never seen this before. It nicely fills a gap, and I really like the format and the writing. Bookmarked. Thanks! -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
Jonathan Cast wrote: Newcomers flounder because they expect to keep programming the same way they always have. _Some_ newcommers flounder because they expect Haskell to be just another VB / C++ / Java / whatever. (Do we really want to encourage these people to be learning Haskell in the first place?) Others it seems flounder simply because Haskell completely changes almost all the rules about programming, and they end up not knowing which way is up. I have far more sympathy with these latter people. As I say, teaching the language syntax and the standard library functions it's going to help much on its own. You need to give these people some idea of what the high-level game plan is. I think you need to show people that you can use Haskell to do normal, ordinary stuff before you start showing off the more exotic things. (Obviously, you need to choose your examples carefully. Anything moderately complex is probably going to be approached from a totally different angle in Haskell, so the parallel won't be as helpful.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 22:40 +0100, Andrew Coppin wrote: Iain Barnett wrote: On 10 Oct 2008, at 9:50 pm, Don Stewart wrote: Haskell makes constructing true parsers just as easy, You're not speaking for me there! :) I really like regex. It's a domain specific functional language, so why rewrite the wheel? Because it's a wheel that looks like the wrong end of a dog? :-} identifier = lexeme $ match [[:lower:]_][[:alphanum:]_]* (pretending match :: String - Parser String is a regex engine). vs. identified = lexeme $ do c - satisfy isLower | satisfy (=='_') s - many $ satisfy isAlphaNum | satisfy (=='_') return (c:s) I'm not sure I follow you here... jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
Martin DeMello wrote: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem is a brilliant example of a common workaday problem found in other languages, and solved elegantly in Haskell Oh, hey, that's pretty nice... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 22:49 +0100, Andrew Coppin wrote: Jonathan Cast wrote: Newcomers flounder because they expect to keep programming the same way they always have. _Some_ newcommers flounder because they expect Haskell to be just another VB / C++ / Java / whatever. (Do we really want to encourage these people to be learning Haskell in the first place?) Absolutely not. That's my point. Others it seems flounder simply because Haskell completely changes almost all the rules about programming, and they end up not knowing which way is up. Are you sure teaching I/O first (or starting with an ugly, unreadable heavily imperative straight translation of C++/Perl/Ruby) is the best way to help these people? The Haskell community *is* committed to teaching people good functional design. You can see it every day on this list. But I don't really see the relevance here. I have far more sympathy with these latter people. As I say, teaching the language syntax and the standard library functions it's going to help much on its own. You need to give these people some idea of what the high-level game plan is. OK, here's the high-level game plan: 1) Figure out what your program's major types are --- just what the names are. 2) Decide what operations you need on them. 3) Pick a domain (or functor) corresponding to each type constant, together with implementations of your selected operations for them. 4) Derive a set of laws governing your operations, that you're going to expect to hold for your implementation. Now, you have an API, and (implicitly) a class of mathematical models of that API. This class comes with a notion of `isomorphism' (or, technically, logical relation), between models that is required to preserve your type constants and operations. You have one model already (step 3); now you need to create another one (step 5) which will be more efficient when translated to machine code or interpreted on the computer. 5) Design a Haskell data type for each type constant, and implement Haskell functions for each operation. These may or may not be similar to your domains and operations from step 3, but there should be an isomorphism or logical relation between them. Now, you have an implementation, and can start work on an interface. 6) Pick an environment to work in (direct X11 programming, wxHaskell, the console, .NET, HTML over HTTP, etc.) 7) Decide what user-level operations you want to provide. 8) Decide, for each operation, what the effect of that operation should be in terms of your underlying state (from steps 1 and 3). 9) Implement each step as a function from the old state to the new one, using your implemented API from step 5. 10) Combine the steps into a comprehensive UI, using whatever composition methods are available in your environment. At each step, feel quite free to go back and revise your work at previous ones (but be sure to continue making progress!) An ideal tutorial would probably guide the user through these steps, in turn; note that I/O *definitely* comes after most of the code has been written. I think you need to show people that you can use Haskell to do normal, ordinary stuff Ordinary in the sense that it's common in programming tutorials, of course. *Real* programming mostly doesn't use printf and fget for I/O, even in C. before you start showing off the more exotic things. (Obviously, you need to choose your examples carefully. Anything moderately complex Anything at all, really. You can paper this over by just not explaining what this `IO' type constant is doing in their programs, but I don't think that actually helps. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, 2008-10-10 at 22:43 +0100, Andrew Coppin wrote: Jonathan Cast wrote: Why would I want to do I/O, when I don't know how to do anything interesting with the input yet, or how to generate interesting output? I think the `I/O comes first' attitude is *precisely* the difference between mainstream programmers and Haskellers. The goal should be to create more Haskellers, not just more people whose code happens to be accepted by GHC. So we need to teach these people not just about the syntax of the language, but the high-level game plan for how to use Haskell effectively. (Since it's SO different from normal languages.) Right. I think what we're doing now *is* an effective program for doing this --- for programmers who are willing to learn --- and what y'all are proposing *isn't*. I think most programmers, looking at the first chapter of the tutorial you want, would be less inclined to learn Haskell than they are now. If they want to write ugly, unmaintainable code, they can always use C++ or Perl, after all. No need to learn Haskell for that. Trouble is, as soon as you attempt to write a chapter like that, guess how many people are gonna actually read it? :-/ Presumably, everyone who knows Haskell now, and programs well in it, *has* read such a chapter. I've got a Haskell book here (Hutton, 170 pages) that doesn't even mention how to open a file! That short, and you expect minor features like that (that not every program even needs) to be squeezed in? See, now it's things like that which stop more people attempting to learn Haskell. Most programmers would consider this an extremely basic and important thing to know, but Haskellers say oh, THAT... it's not really important and the newbies go wuh? Which planet are you from? I'll go learn something less crazy, thanks. It's a simple fact of programming, just one most developers don't know or don't think about. Pretending console or file I/O is somehow fundamental won't make GUIs start calling printf, or database clients start opening disk files. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
On 2008 Oct 10, at 15:48, Andrew Coppin wrote: Don Stewart wrote: This could be a game changer. In what way? As far as I'm aware, .NET never really caught on and has long since become News to me; lots of people installing VS.NET on campus... -- 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] ANNOUNCE: Salsa: A .NET Bridge for Haskell
On Fri, Oct 10, 2008 at 5:12 AM, Andrew Appleyard [EMAIL PROTECTED] wrote: I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Wow, that's really great. I have a .NET friendly employer, so I'm happy to see a tool/library that 'bridges the gap between my dream of using Haskell on the job and my reality of using .NET on the job. Thank you for releasing this! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. That's a very pragmatic approach. Nice. But, as I understand it the Haskell you write still lives in Haskell-land and the .NET code you interface with lives in .NET land. So this means, that if we tried this approach with other languagse, say Python and Java, our Haskell code would be a second class citizen there. For example, suppose you embed CPython into an application and then build a Haskell -- Python bridge. Then my Haskell code I write must be recompiled for each platform and loaded by the python? Similarly for Java, I'm assuming that while the JVM bytecode might get loaded by the security module my Haskell is living in Haskell-land and the JVM can't provide the users with the same guarantees. So, what about translators? I was thinking, maybe a nice way to interoperate would to translate Haskell to language du jour? What if I could type, ghc --make Foo.hs -TPython, and I get Foo.py that can be run in the CPython implementation as just plain python? My understanding is that changing GHC backend is a lot of work. Take projects like lambdaVM, which I don't think has ever been completed, and you see that it involves writing a language specific run-time and some other work. There is yhccore, which has a translator for javascript. What is the way to go here? I like GHC in terms of performance, robustness and language extensions. Would I lose that with custom backends? I imagine the language extensions I'd get to keep and everything else would be subject to how well the backend is written. What do others think? Thanks! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] Haskell Cheatsheet v1.0
All, I've created a cheat sheet for Haskell. It's a PDF that tries to summarize Haskell 98's syntax, keywords and other language elements. It's currently available on hackage[1]. Once downloaded, unpack the archive and you'll see the PDF. A literate source file is also included. If you install with cabal install cheatsheet, run cheatsheet afterwards and the program will tell you where the PDF is located. The audience for this document is beginning to intermediate Haskell programmers. I found it difficult to look up some of the less-used syntax and other language stumbling blocks as I learned Haskell over the last few years, so I hope this document can help others in the future. This is a beta release (which is why I've limited the audience by using hackage) to get feedback before distributing the PDF to a wider audience. With that in mind, I welcome your comments or patches[2]. Justin [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet [2] git://github.com/m4dc4p/cheatsheet.git ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Fri, Oct 10, 2008 at 10:35:05PM +0100, Andrew Coppin wrote: OTOH, it's easy to criticise what somebody else wrote. Much harder to write something better yourself... :-/ PS. I'm curios to see what happens when the book gets to the interesting stuff. The intro seems to promise that Haskell has I'm equally curious to see what happens when you get there ;-) libraries for all kinds of cool stuff - database access, sound, etc. But IME it isn't true. I have tried and tried to make accessing a database work from Haskell; the necessary libraries simply refuse to compile. Well, it compiles out of the box for me. Which may or may not be saying much. Have you posted your compile errors here so that we can help you? work.) I want to see what the hell everybody else is doing differently that makes this stuff actually work for them when it fails miserably for me! Start by showing us what exact commands you're running and what errors you get. Also what version of GHC you have and your platform would be helpful. So anyhow... when I started using Haskell, it was *despite* the state of libraries. I found that I was so much more productive in Haskell in the long run that I could sometimes write the library and solve the original problem in less time than it took to just solve the original problem in Python or OCaml. Obviously this doesn't always hold. But this is part of the reason that I wrote HDBC, ConfigFile, MissingH, hslogger, etc. Small things that were just missing but aren't anymore. I can't pretend that the Haskell library set is as full-featured as, say, Python. But it *is* respectable and it most certainly holds its own with database access. Oh, and you can call Python from Haskell. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Oct 10, 2008, at 5:46 PM, Jonathan Cast wrote: identifier = lexeme $ match [[:lower:]_][[:alphanum:]_]* (pretending match :: String - Parser String is a regex engine). vs. identified = lexeme $ do c - satisfy isLower | satisfy (=='_') s - many $ satisfy isAlphaNum | satisfy (=='_') return (c:s) lexeme $ (:) $ (lowerChar | char '_') * (many $ alphaNum | char '_') ? or (since we're not really talking about full fledged parsers that need lexemes here or such, but usually interpreting a single string, otherwise regexes will quickly become atrocious) foo (x:xs) | isLower x || x == '_', (xs', rest) - break alphaOrUnder xs = Just (x : xs', rest) | otherwise = Nothing where alphaOrUnder = liftM2 (||) isAlphaNum (=='_') foo [] = Nothing A bit more verbose, sure, but operating on text functionally makes it really easy to reason about what your parser is actually doing, unlike the mysteries of a regex. --Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
Quoth John Goerzen [EMAIL PROTECTED]: | Uh... yes. Opening and closing files, command-line parsing, etc -- | needed by almost every program. Aside from some very simple | stdin-to-stdout filters, it is difficult to imagine a program where | you don't need to open a file! That's how it seems to me, too, and moreover maybe the most generally recognizable API. With a GUI or a database, you're going to need to present a fair amount of background to just about everyone, but files, command lines etc. are common to nearly every programming language. If the virtues of Haskell can't be presented in this context, then maybe it isn't such a generally useful language that people ought to be worried about learning it. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
