Re: [Haskell] Re: [Haskell-cafe] Why functional programming matters
Isaac Dupree wrote: Derek Elkins wrote: and you can have unboxed values in dynamically typed languages. really? Sure that's possible as an optimization, but I thought that to explicitly specify that would require a known static type. Or perhaps the bit-tagging by which some Scheme implementations are able to hold small integers without a pointer (IIRC)? That's exactly what Ruby does - symbols, Fixnums (integers that fit into a single machine word), bools and nil are unboxed, distinguished from boxed types by the lowest 2 bits. That's undistinguishable at runtime, though - everything Just Works as though they're ordinary objects, including flipping integer class to Bignum (which is boxed) as necessary. -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Evolutionary Computing
Dusan Kolar wrote: Hello, I don't know about math, but a practical usage seems to be in the reconfigurable hardware (FPGA). See web-page of my colleague, where is list of his papers on the topic. http://www.fit.vutbr.cz/~sekanina/pubs.php These people use GAs for optimising water networks (and, more importantly, maintenance of water networks): http://optimatics.com/go/case-studies-andamp-testimonials Their tools are all C++, though. -- Alex Dusan PR Stanley wrote: Hi What does the list think of EC? Genetic algorithm is apparently the latest thing. Is EC mathematically reasonable? Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: suggestion: add a .ehs file type
Alex Jacobson wrote: My original point (refined) was that I'd like a file extension (.ehs) that defaults to including all extensions that don't change the meaning of a .hs program but that may cause a small subset of them not to compile (e.g. ones that use forall as a type variable, foreign as a function, or 'd' as the result value of a list comprehension) This does not seem like a major change, does not break any existing code, and has the advantage of making it really obvious when people are going beyond haskell98. It'll break all sorts of things when .ehs has to get merged into .hs the next time this conversation comes around, unless it's guaranteed that all .hs processors will eventually be upgraded to cope with .ehs semantics. I don't think anyone's arguing for that... -- Alex -Alex- Simon Marlow wrote: I see, all you're saying is you'd like the default to be different. (That's not the same as saying Extensions that change syntax are effectively declared by the use of that syntax, which is what you said earlier, BTW.) Well, we could change the default. I don't think it's a great idea personally - I think we should default to compiling whatever is the most recent standard, i.e. Haskell 98. But you're arguing that the proportion of Haskell 98 code that would fail to compile is relatively small; that might well be true. This isn't a decision we could take lightly, though. Furthermore, it's only something we could change in 6.10, by which time it is likely that we'll have a clearer idea of what Haskell' is, so there might well be a -fhaskell-prime flag (or it might even be the default). Cheers, Simon Alex Jacobson wrote: Simon, I think we've been trying to be too clever... The simple question is: for a given extension, what is the risk of leaving it turned on by default? Clearly we don't want extensions turned on that causes code to compile but with a different meaning. We may not want extensions turned on that cause most reasonable code not to compile. But I would say neither risk is significant in the case of most extensions. To use your examples: * FFI doesn't not cause h98 code to compile to a different meaning. The worst case is that code that uses 'foreign' as a function name doesn't compile. That seems okay in that more code probably uses FFI than uses foreign as a function name and the user can apply a language pragma to turn it off if really desired. * Existential types won't cause h98 code to compile with a different meaning. The worst case is that code that uses 'forall' as a type variable won't compile. That seems ok * TemplateHaskell also not compatible with h98. The worst case is the loss [d| in list comprehensions. * MagicHash: Does not appear in the ToC or the Index of the user's guide so should probably be turned off. I have no idea what it does. Note, in all cases where the extension is turned on by default, there should be a language pragma to turn it off. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Simon, from what I can tell, with GHC 6.8.1, use of foreign as a function name or forall as a type variable or leaving out a space in a list-comprehension doesn't parse differently when the relevant extensions are enabled, it causes a parse error. Extensions allow the same code to parse but with different meanings need to be declared explicitly. But, extensions that are obvious from syntax should be allowed to be declared simply from the use of that syntax. So for the first example I gave, f x y = x 3# y the MagicHash extension is one that you'd require to be explicitly declared, because the expression parses both with and without the extension. Now, Let's take the Template Haskell example: f x = [d|d-xs] So this is valid Haskell 98, but invalid H98+TH. You would therefore like this example to parse unambiguously as H98, correct? But in order to do that, our parser would need arbitrary lookahead: it can't tell whether the expression is legal H98+TH until it gets to the '-' in this case. Certainly it's possible to implement this using a backtracking parser, but Haskell is supposed to be parsable with a shift-reduce parser such as the one GHC uses. Or we could try parsing the whole module with various combinations of extensions turned on or off, but I'm sure you can see the problems with that. So basically the problem is that you need a parser that parses a strict superset of Haskell98 - and that's hard to achieve. Cheers, Simon I am not taking a position here on the merits of any extensions. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syntax. If you can parse the source, then you know which extensions it uses. I thought we'd already established that this isn't possible. Here are some code fragments that parse differently depending on which extensions are enabled:
Re: [Haskell-cafe] More problems [Tetris]
Peter Verswyvelen wrote: No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird. It was bundled with GHC 6.6.1. But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first. This is handled in Ruby-land by having binary packages available for Windows, either cross-compiled or donated by someone with an appropriate compiler. Would that be a possible here? Just a thought. -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Magnus Therning wrote: On Tue, Nov 20, 2007 at 12:33:21 +, Vladimir Zlatanov wrote: Yes, those are good points. Maybe adding functionality similar to plt's planet http://planet.plt-scheme.org and http://download.plt-scheme.org/doc/371/html/mzscheme/mzscheme-Z-H-5.html#node_sec_5.4 In plt scheme including a module, not present in the local repository , but included via planet, resolves the module, including version, etc..., downloads it from planet, and uses it appropriately. It makes following various dependencies extremely easy. Updating with a new version is updating the appropriate local module definitions. I have no clue how it would be best to implement this for haskell, but it is a very user friendly no hassle way to work, so I reckon worth investigating. Many other programming languages have packaging strategies that sound very similar. Several of them have managed to have a negative impact on platforms that already have good packaging technologies (i.e. almost every platform apart from Windows ;-). I'd hate to see Haskell go in a direction where packaging for e.g. Debian is made more difficult than it is at the moment. See [1] for the Debian Ruby packagers' opinion of RubyGems. IIRC similar concerns have been raised for Python's eggs. /M [1]: http://pkg-ruby-extras.alioth.debian.org/rubygems.html Much of that's either outdated or just plain wrong, as I understand it. In the interest of balance, note the following thread on ruby-talk, which devolved fairly rapidly into a bunfight over Debian's policies (and a comparison with Apple's approach to the same problem): http://www.nabble.com/-ANN--RubyGems-0.9.5-tf4840470.html There are arguments on both sides, but the utility of having RubyGems available far outweighs the minor inconvenience of having to install RubyGems outside apt as far as I'm concerned. -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Magnus Therning wrote: On Wed, Nov 21, 2007 at 20:40:01 +, Alex Young wrote: Magnus Therning wrote: On Tue, Nov 20, 2007 at 12:33:21 +, Vladimir Zlatanov wrote: Yes, those are good points. Maybe adding functionality similar to plt's planet http://planet.plt-scheme.org and http://download.plt-scheme.org/doc/371/html/mzscheme/mzscheme-Z-H-5.html#node_sec_5.4 In plt scheme including a module, not present in the local repository , but included via planet, resolves the module, including version, etc..., downloads it from planet, and uses it appropriately. It makes following various dependencies extremely easy. Updating with a new version is updating the appropriate local module definitions. I have no clue how it would be best to implement this for haskell, but it is a very user friendly no hassle way to work, so I reckon worth investigating. Many other programming languages have packaging strategies that sound very similar. Several of them have managed to have a negative impact on platforms that already have good packaging technologies (i.e. almost every platform apart from Windows ;-). I'd hate to see Haskell go in a direction where packaging for e.g. Debian is made more difficult than it is at the moment. See [1] for the Debian Ruby packagers' opinion of RubyGems. IIRC similar concerns have been raised for Python's eggs. /M [1]: http://pkg-ruby-extras.alioth.debian.org/rubygems.html Much of that's either outdated or just plain wrong, as I understand it. In the interest of balance, note the following thread on ruby-talk, which devolved fairly rapidly into a bunfight over Debian's policies (and a comparison with Apple's approach to the same problem): http://www.nabble.com/-ANN--RubyGems-0.9.5-tf4840470.html There are arguments on both sides, but the utility of having RubyGems available far outweighs the minor inconvenience of having to install RubyGems outside apt. All I was trying to say is that if discussions like the one you link to can be avoided altogether then that would be good. Indeed it would. I have never been heavy into Ruby programming, but I thought that the location for gems was the least of the problems they list. The major one, IFAIU is: “Rubygems is source-intrusive. The require instruction is replaced by a require_gem instruction to allow for versioned dependencies. Debian and most other systems think that dealing with versioned dependencies outside of the source is a better idea.” This particular objection has the distinction of being both wrong and outdated. The require_gem method was deprecated some time ago, and versioned dependency control has always been available to package management outside the source, in the gemspec, as well as having a runtime check available to the software author. And it's not only a problem for Ruby in Debian: http://people.debian.org/~terpstra/message/20070904.152810.4f84c924.en.html “There are currently no plans to improve RubyGems to ease the work of Debian and RPM packagers.” It's the position of the RubyGems team that all the functionality that should be needed has been implemented, but they've made it quite plain that they're willing to accept reasonable patches (as they have done from Apple). I think that making it easy to package Haskell libraries, and programs, for any OS/distribution (Debian, Gentoo, PC-BSD, windows, etc) is /extremely/ important. I for one would like to see programs written in Haskell make it into as many places as possible. I'd hate to see a Haskell-specific packaging system prevent that in a similar way that RubyGems does. I am yet to be convinced that RubyGems prevents anything, but then I'm not a maintainer on either end. I certainly believe that it's possible to avoid inconvenience. From the Debian Ruby team again: “[Users can] continue to install their apps the way they are used to (using apt-get), since most of them do not care about the language their apps are written in or about other ways this application/library is made available.” That section specifically refers to libraries and applications that are not distributed as RubyGems, and that therefore can't take advantage of the cross-platform distribution and dependency management system. That's a (relatively) shrinking number. Again, I'm not convinced that the two can't be made to co-exist; that is, that an apt-get installed library should be gem update'able, and vice versa, and have everything still work. The upshot of the current situation of Ruby on Debian is that the standard advice seems to be to build everything from source; luckily, that works extremely well. We're in danger of drifting OT here, but I think the lessons are important. -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] c2hs on Windows?
Hi all, Does anyone know if c2hs should be working on Windows? I'm trying to build it under ghc 6.8.0, but this happens: C:\Users\Alex\Documents\Plugins\c2hs\c2hs-0.15.0runghc Setup.hs configure Configuring c2hs-0.15.0... Setup.hs: Error: Non-empty library, but empty exposed modules list. Cabal may not build this library correctly C:\Users\Alex\Documents\Plugins\c2hs\c2hs-0.15.0runghc Setup.hs build Setup.hs: error reading dist\setup-config; run setup configure command? Apologies if I'm being dense... Thanks, -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monte Carlo Pi calculation (newbie learnings)
Hi all,
I'm new to Haskell, and don't quite understand how IO and lazy
evaluation work together yet. In order to improve my understanding, I
thought I'd try to knock together a translation of a fairly simple
problem I can code up in C, that of calculating pi by throwing random
numbers about. The C code I started with is as follows:
//
#include stdio.h
#include stdlib.h
#include time.h
int main(int argc, char *argv[])
{
if(argc != 2)
{
printf(usage: %s iteration_count, argv[0]);
return 1;
}
int total;
if(sscanf(argv[1], %d, total) != 1)
return 1;
int count = 0;
int unit_radius = RAND_MAX * RAND_MAX;
int i;
srand(time(NULL));
for(i = 0; i total; i++)
{
int x, y;
x = rand();
y = rand();
count += x*x + y*y unit_radius;
}
double pi = (count 2) / (double)total;
printf(Count: %d\nTotal: %d\n, count, total);
printf(%f, pi);
return 0;
}
///
All very simple - the key is that I'm counting the result of a
conditional evaluated inside a loop. Ignore whether it's correct, or
accurate, for now; it happily runs and gives an accurate-looking result
when run with an argument of 1000. My (thoroughly ugly, not
currently working) Haskell version looks like this:
{--}
module Main where
import Random
import System.Environment
import List
import Monad
randMax = 32767
unitRadius = randMax * randMax
rand :: IO Int
rand = getStdRandom (randomR (0, randMax))
randListTail accum 0 = accum
randListTail accum n = randListTail (rand : accum) (n - 1)
randList :: Int - [IO Int]
randList n = randListTail [] n
randPairs :: Int - [(IO Int, IO Int)]
randPairs n = zip (randList n) (randList n)
pairIsInside x y = if x*x + y*y unitRadius then 1 else 0
doCountPair :: (IO Int, IO Int) - IO Int
doCountPair (a, b) = do
x - a
y - b
return (pairIsInside x y)
fSumListTail :: Int - [(IO Int, IO Int)] - IO Int
fSumListTail total [] = do
return total
fSumListTail total (x:xs) = do
y - doCountPair x
fSumListTail (total+y) xs
fSumList :: [(IO Int, IO Int)] - IO Int
fSumList l = fSumListTail 0 l
piAsDouble :: Int - Int - Double
piAsDouble a b =
(fromInteger (toInteger a)) / (fromInteger (toInteger b))
calculatePi total = do
count - fSumList (randPairs total)
return (piAsDouble (4*count) total)
main = do
args - getArgs
(calculatePi (read (args !! 0))) = (putStr . show)
{--}
Now, I have two questions. The easy question is, how can I make this
more idiomatic? I seem to be jumping through hoops rather a lot to
achieve what should be rather simple operations. The piAsDouble and
fSumListTail functions are perfect examples, but I'm not wildly keen on
doCountPair either.
The second question is performance-related. The Haskell code above
overflows the stack when run with an argument of 100, so either
somewhere a list I'm intending to be lazily evaluated and chucked away
is being retained, or one of my recursive functions isn't
tail-optimising. Is it obvious to a more trained eye where the problem
is? If not, how should I start to diagnose this? I'm not really sure
where I should look for more information.
More information, if it's relevant:
Haskell: Glasgow Haskell Compiler, Version 6.8.0.20070917, for
Haskell 98, stage 3 booted by GHC version 6.6
OS: Windows Vista, 32bit
Any guidance gratefully appreciated...
Thanks,
--
Alex
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
