Re: [Haskell-cafe] Problems with Language.Haskell.Interpreter and errors
Thanks a lot. You ought to be able to add a Control.Monad.CatchIO.catch clause to your interpreter to catch this kind of errors, if you want. I forgot to mention that this didn't work for me either. Thanks for the report! You are welcome. If you come up with a work around or a fix, I would appreciate if you let me know. Cheers, Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
Curt Sampson c...@starling-software.com writes: Java is part of the Java platform, that brought OS independence and interoperability at the right time. .Download-execution on the client was also a reason for the initial success of Java in the Internet era. This may be somewhat anecdotal evidence, but I disagree with both of your statements here. I've rarely known anybody to use Java cross-platform in a non-trival way, barring a few major GUI-centric projects such as Eclipse. (I've far more cross-platform use of Haskell than Java myself.) And I know of nobody who did anything serious with download-execution of Java. Well I (dis)agree with you both :-) I think these things - running Java programs in the browser, and cross-platformness - were very important in making Java popular, even if they ended up being, at best, peripheral uses of the language. Still, they served to hype the language to an industry that had just gotten used to object orientation, and thus clearing the path for Java's adoption as a successor to C++ (where it was and is quite successful). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with result-type context restrictions in typeclasses.
class Cls c where
type Ret c :: (Bar *) = * -- or a better name
foo :: c - Ret c
which isn't legal Haskell.
OK, that's exactly the same thing I've met when developing
compose-trans. I needed guarantees that something is a Monad.
My way of doing that was to make Bar (Monad in my case) a datatype.
Suppose you Bar class is something like
class Bar c where
toBar :: String - c
changeBar :: c - Int - c
fromBar :: c - c - [Float]
Declare something like
data BarD c =
BarD
{toBarD :: String - c,
changeBarD :: c - Int - c,
fromBarD :: c - c - [Float]}
I've did it some other way, using the Monad specifics, but essentially
it was the same.
Then you can write a default BarD this way:
barDInst :: Bar c = BarD c
barDInst =
BarD
{toBarD = toBar,
changeBarD = changeBar,
fromBarD = fromBar}
Do not (!) export BarD constructor, so the only BarD one would be able
to produce would be the default one. It simplifies you interface.
Now, your Cls looks like that:
class Cls c where
type Ret c
barRet :: BarD (Ret c)
foo :: c - Ret c
If somebody is using your class, she can't be sure that Ret c is of
class Bar, but she would have sort of an instance anyway: she would
just use toBarD barRet instead of toBar, and so on. If somebody is
trying to make some c an instance of Cls - the only thing she can do
is to make some d an instance of Bar and write
instance Cls MyCoolInstance where
type Ret MyCoolInstance = MyCoolRetType
barRet = barDInst
foo c = ...
It's higly possible, however, that you'd have to deal with Ambiguous
type variable's.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Problem with result-type context restrictions in typeclasses.
You can require the associated type to have a particular instance, like
this:
class (Bar (Ret c)) = Cls c where
type Ret c
foo :: c - Ret c
Another option is to use existential types:
data HasBar = forall a. Bar a = HasBar a
class Cls c where
foo :: c - HasBar
You then have to wrap the result of foo by HasBar; then you can get the
instance back out by case-matching on HasBar. This is basically the same as
Miguel's solution of returning a dictionary, except the dictionary is
implicitly held in the existential instead of explicit.
-- ryan
On Tue, Sep 29, 2009 at 10:25 PM, DNM dnme...@gmail.com wrote:
Dan, thanks again for the response.
I changed my code to use type families to let each Cls instance (actually a
more complicated instance in my code) determine which Bar instance type it
will return, but this didn't seem to work. The problem is that the client
of the typeclass instance methds ('useThisStuff', which calls on 'toNum'
and
'foo' in the contrived example) expects some guarantee that (Ret c) is
going
to be an instance of Bar. The actual client code I'm using complains when
it sees that the associated type doesn't guarantee that an instance of the
appropriate class is instantiated. I don't see any way to guarantee this
without adding a context restriction in the class-level definition of Ret
c,
something like:
class Cls c where
type Ret c :: (Bar *) = * -- or a better name
foo :: c - Ret c
which isn't legal Haskell. What I want to say is define Ret c however you
want, but make sure it is an instance of Bar in the *class-level
definition
of Ret c*, so that any client of 'Cls' will know that Ret c will be
foo-able.
Maybe I'm missing some subtlety of type families...
Any suggestions?
--D.N.
Daniel Peebles wrote:
In your class, you have:
class Cls c where
foo :: (Bar b) = c - b
There's an implicit forall for b, meaning that the caller of the
method gets to choose what it wants for b (as long as it's an instance
of Bar). For you to be able to write such a method you'd need to write
functions that can return any instance of Bar. One solution to this is
to turn on the GHC extension -XTypeFamilies, and then modify your code
as follows:
class Cls c where
type Ret c :: * -- or a better name
foo :: c - Ret c
instance Cls G where
type Ret G = FU
foo = fuu
That should work (although I haven't tested it).
What type families do in this case is allow you to write not only
methods associated with typeclasses, but type functions associated
with them too. In this case you can think of Ret as a function that
takes a type (G in the instance above) and returns another type (FU).
Each instance can define new mappings for Ret.
Hope this helps!
Dan
On Tue, Sep 29, 2009 at 10:48 PM, DNM dnme...@gmail.com wrote:
Correction by the author:
It seems that ghc doesn't like the fact that I am saying 'foo' must
return a class 'b' of typeclass 'Bar', while providing a function that
returns a concrete data instance of 'Bar' (viz., FU or FI) later on
when I implement 'foo' in each type classes.
Should read:
It seems that ghc doesn't like the fact that I am saying 'foo' must
return something of TYPE 'b' implementing typeclass 'Bar', while
providing
a function that returns a concrete data instance of 'Bar' (viz., FU or
FI)
later on when I implement 'foo' in each type classes.
On Sep 29, 10:43 pm, DNM dnme...@gmail.com wrote:
N.B. I'm a newbie to Haskell, and this problem is a bit complex, so
bear with me.
I'm using typeclasses to implement a sort of common interface for all
things -- call them things of type 'Cls' -- that can be expected to
implement a set of functions -- an 'interface' in OOP-speak. (Yes,
yes, I'm aware that typeclasses are subtly different and far superior,
but my Haskell-ese is still a bit rudimentary.)
Essentially, I want to have a typeclass that expects its instances to
have an accessor function that results in something that is an
instance of another typeclass whose instances can perform some
operation. The ghc type-checker doesn't seem to like my code,
though, and I can't seem to figure out why.
To make it concrete, I've typed up some dummy typeclasses and a dummy
function that uses their instances to illustrate what I mean, as well
as the form of the ghc(i) error.
- BEGIN CODE --
class Cls c where
foo :: (Bar b) = c - b
class Bar b where
toNum :: b - Int
-- | One implementation of Cls
data D = D {fu :: FU}
data FU = FU {num :: Int}
instance Cls D where
foo = fu
instance Bar FU where
toNum f = (num f) + 47
-- | Another implementation of Cls
data E = E {fi :: FI}
data FI = FI {nuum :: Int}
instance Cls E where
foo = fi
instance Bar FI where
toNum f = (nuum f) + 100
-- | Yet another (this one
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Casey Hawthorne wrote: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language. If this is true, it needs to be pushed. And if by changing a few lines of source code one can develop a whole family of similar applications, that needs to be pushed, also. :) As one C++ expert I know is fond of telling me, Haskell will only become popular when obscure mathematics becomes popular. You can argue about whether or not this is true. Myself I think we just need to start documenting things more clearly. (E.g., Mr C++ apparently spent half an hour trying to figure out why an expression wouldn't parse. Turns out you have to write negative numbers in brackets. Which isn't hard, but you have to already know this.) I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. (Not to mention some of the standard I/O functions doing slightly strange things because GHC is calling POSIX compatibility functions rather than native I/O functions. For example, doesDirectoryExist C:\\ = False.) The lack of a big shiny whizzy-looking IDE probably stops quite a few people too. (I gather the Leksah guys are working on that one.) Lack of a good way to write native-looking Windows GUI applications - or indeed any GUI applications without requiring a stack of DLLs - probably doesn't help either. None of these look fundamentally insumountable to me. (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. We shall see...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Haskell-beginners] Better way to retrieve data strucures from sql-db?
Hi Roman,
Template Haskell should be the preferred way to
cope with these boilerplate code problems.
Template Haskell: http://www.haskell.org/haskellwiki/Template_Haskell
Note: I'm a beginner myself so please wait for a more informed response.
Paolo
2009/9/28 Roman Naumann roman_naum...@fastmail.fm:
The following function converts the data read from an sql database to a
player data structure.
toPlayer :: [SqlValue] - Player
toPlayer sx = Player {
plID = fromSql (sx!!0),
plAccount = fromSql (sx!!1),
plForename = fromSql (sx!!2),
plSurename = fromSql (sx!!3),
plPos_x = fromSql (sx!!4),
plPos_y = fromSql (sx!!5)
}
It appears to me, that I have to write this boilerplate code every time I
introduce a new data structure that has to be read from the sql database.
Can you think of a way to automate this?
Thanks for your replies,
Roman Naumann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
2009/9/30 Andrew Coppin andrewcop...@btinternet.com:
(Mr C++ argues that homo sapiens fundamentally think in an imperative way,
and therefore functional programming in general will never be popular.
Sounds more like Mr C++ fundamentally thinks in an imperative way
because that's what he is used to.
I recently started working with C# and struggled for way too long with
for/foreach loops to do things that in Haskell could be expressed
using only folding, mapping and filtering. When I realised that those
ideas actually exist in System.Linq I suddenly started liking the
language a bit more.
txtCommaSeparatedNames.Text.Split(',').Select(x = x.Trim()).Where(x
= x.Length 0).Select(x = Convert.ToInt32(x)).ToList();
Ah, the joy of FP.
--
Deniz Dogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Yep, LINQ makes C# more enjoyable :-) Scala and haXe also look nice, a bit
of a mix between OCaml/F#, C#/Java and Haskell.
Besides the fact that hacking in Haskell is a great deal of fun, the main
reason I see for learning Haskell: it makes you a better programmer. After
a couple of years of playing with Haskell, I can now solve problems that I
couldn't before. It's of course hard to tell if Haskell is the reason here,
or just experience, but I feel it really is Haskell (actually, functional
programming). Haskell made me see the world in a different way (and if I see
Oleg's and co's code, I still have an infinitely long road ahead.
The main reason why you should not learn Haskell: it's a bit of a drug;
after you learned Haskell, programming in an industrial strength language
suddenly feels like a waste of time, time better spent learning more
Haskell...
On Wed, Sep 30, 2009 at 10:26 AM, Deniz Dogan deniz.a.m.do...@gmail.comwrote:
2009/9/30 Andrew Coppin andrewcop...@btinternet.com:
(Mr C++ argues that homo sapiens fundamentally think in an imperative
way,
and therefore functional programming in general will never be popular.
Sounds more like Mr C++ fundamentally thinks in an imperative way
because that's what he is used to.
I recently started working with C# and struggled for way too long with
for/foreach loops to do things that in Haskell could be expressed
using only folding, mapping and filtering. When I realised that those
ideas actually exist in System.Linq I suddenly started liking the
language a bit more.
txtCommaSeparatedNames.Text.Split(',').Select(x = x.Trim()).Where(x
= x.Length 0).Select(x = Convert.ToInt32(x)).ToList();
Ah, the joy of FP.
--
Deniz Dogan
___
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] Type synonyms vs standard types
True. But anyway newtype creates a new type which is not what I'm looking for. In this case instead of passing a string myAttrName user should pass constructor as well. And the next step of such simplification will be a smart constructor attrName? :) And that's all just to show user of that function what kind of parameters function expects! :-D On Wed, Sep 30, 2009 at 5:47 AM, wren ng thornton w...@freegeek.org wrote: Olex P wrote: This idea with new level of abstraction is good but in some cases it can make things overcomplicated / less efficient. Does that mean leave simple built-in types as is? That's what newtypes are for. A newtype is like a type alias, except that it is type checked. All newtype wrappering/unwrappering is compiled away so the representations are the same. The only performance difference is (== should be) that there can be overhead for strange ways of providing typeclass instances.[1] [1] By strange ways of providing typeclass instances I mean things like using classPeano p where ... data Z = Z newtype S n = S n instance Peano Zwhere ... instance Peano n = Peano (S n) where ... instead of a straightforward data ZorS = Z | S Peano instance Peano ZorS where ... Because of the newtype, the representation of (S n) is the same as the representation of Z, thus all peano numbers are the same size. However, we still need to keep that info around somewhere, and consequently the size of the (Peano n) dictionary is linear in n (because it needs a pointer to the (Peano (n-1)) dictionary, and so on until (Peano Z)). On the other hand, with the straightforward version, the size of (n :: ZorS) is linear in n, but the size of the (Peano ZorS) dictionary is constant. -- Live well, ~wren ___ 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] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Deniz Dogan wrote: 2009/9/30 Andrew Coppin andrewcop...@btinternet.com: (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. Sounds more like Mr C++ fundamentally thinks in an imperative way because that's what he is used to. Entirely plausible, yes. Consider, for a moment, the task of counting how many elements there are in a linked list. The imperative way: Initialise counter to zero. Start at the beginning of the list. If we have reached the end of the list, return the counter. Otherwise, increase the counter by one and fetch the next list node. The FP way: The size of an empty list is zero. The size of a nonempty list is one plus the sum of the suffix of the list. It does read kind of like a riddle. It's not even immediately obvious that this is the entire definition. (Unless you already happen to be a maths nerd, like myself.) The first one reads like a list of instructions explaining HOW to count the list size. The second reads more like a definition of WHAT the list size is. It doesn't immediately look like there's even a way to execute this. (They don't call it declarative programming for nothing...) I note in passing that, even in English, the FP version is shorter. ;-) I think if you wanted to count the size of a tree, it seems a lot more natural though: If this is a leaf node, return one. Otherwise: Initialise counter to zero. Count size of left subtree and add to counter. Count size of right subtree and add to counter. Return counter. The size of a leaf node is one. The size of a branch node is the sum of the sizes of the two subtrees. Arguably most people are probably more accustomed to thinking in terms of do this, do that, do the other (think about, e.g., a cooking recipy or a task list) then they are to defining task goals as self-referential riddles. On the other hand, from what I've experienced, computer programming is already a task that some people get, and others simply don't. Maybe in another forty years, all programming will be functional programming, and anybody who doesn't get recursion just won't become a programmer? Who knows... Ah, the joy of FP. Amen! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] convert a list of booleans into Word*
Hello, I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. I have written one which seems very inefficient : toWord8 :: [Bool] - Word8 toWord8 bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs Is there a better way to do this out there ? (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). Cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
paul.brau...@loria.fr wrote: (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). By a strange coincidence, I did the self same thing a while back. There is Data.Binary which supports efficient reading and writing of binary data. However, sadly it does not support bit alignment, only whole byte alignment. I did put together a library to fix this, but I don't have the source code any more. Maybe I should finish it and put it on Hackage... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Wed, Sep 30, 2009 at 9:32 AM, Andrew Coppin andrewcop...@btinternet.com wrote: I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. (Not to mention some of the standard I/O functions doing slightly strange things because GHC is calling POSIX compatibility functions rather than native I/O functions. For example, doesDirectoryExist C:\\ = False.) This is a problem of C / Posix, not a problem of Haskell. Haskell C bindings compile on Windows without issues IF the corrisponding library is available. It is compiling the (usually posix) C library in Windows the real issue. Anyway, on Windows Vista, cmd.exe: GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Prelude :m System.Directory Prelude System.Directory doesDirectoryExist C:\\ True Salvatore ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
I wrote a few variants for fun. Probably equally inefficient. I suggest you look at Data.Binary as Andrew suggested. -- Your original function, but with a more generic type signature. encodeBits :: Bits n = [Bool] - n encodeBits bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs -- Combine the flags with their index and then set bits when appropriate. encodeBits2 :: Bits n = [Bool] - n encodeBits2 = foldr (\(n, b) x - setBitIf b x n) 0 . zip [0..] where setBitIf False x _ = x setBitIf True x n = setBit x n -- Shift the result left while constructing and only toggle the first bit. encodeBits3 :: Bits n = [Bool] - n encodeBits3 bs = foldr (\b x - setBitIf b (x `shiftL` 1)) 0 bs where setBitIf False x = x setBitIf True x = setBit x 0 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Any working example of using genericserialize?
Hi, I am trying to use the genericserialize package (http://hackage.haskell.org/package/genericserialize) but cannot get things working. While buildList (sexpSerialize [1, 2, 3]) yields (1 2 3) as it might be expected, I cannot deserialize it back: *Main (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Integer] Nothing or *Main (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Int] Nothing while I would expect at least one of these cases result in Just [1, 2, 3] What am I missing? Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] i am missing something really trivial with parsec
On Tue, Sep 29, 2009 at 12:54:21AM -0700, Anatoly Yakovenko wrote:
number = do { num - natural
; return $ num
}
main = do
txt - hGetContents stdin
print $ parse number stdin txt
why doesn't that work?
Could you be a little more specific? What are you expecting to
happen, and what happens instead/what error message do you get?
-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
Here's another approach for Bool lists with msb leftmost: bitsToInt :: [Bool] - Integer bitsToInt = foldr((.(flip shiftL 1)).(+)) 0. map (fromIntegral.fromEnum) Hallo paul.brau...@loria.fr, je schreef op 30-09-09 11:18: Hello, I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. I have written one which seems very inefficient : toWord8 :: [Bool] - Word8 toWord8 bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs Is there a better way to do this out there ? (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). Cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Met vriendelijke groet, =@@i ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
Sorry, msb rigthmost Here's another approach for Bool lists with msb leftmost: bitsToInt :: [Bool] - Integer bitsToInt = foldr((.(flip shiftL 1)).(+)) 0. map (fromIntegral.fromEnum) Hallo paul.brau...@loria.fr, je schreef op 30-09-09 11:18: Hello, I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. I have written one which seems very inefficient : toWord8 :: [Bool] - Word8 toWord8 bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs Is there a better way to do this out there ? (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). Cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Met vriendelijke groet, =@@i ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] suggestion for hslogger
On Tue, 2009-09-29 at 14:31 -0400, Sean McLaughlin wrote: Hello, I have a program that does a lot of unicode manipulation. I'd like to use hslogger to log various operations. However, since hslogger uses System.IO.putX, the unicode comes out mangled. I hacked the source to use System.IO.UTF8 instead, but it would be nice if that was an option so I don't have to rehack the code whenever there is a new release. Note that this will Just Worktm in ghc-6.12. By default the System.IO functions will use the locale encoding and convert to/from the Unicode String type. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Market Place for Haskell development teams?
Curt, 2009/9/29 Curt Sampson c...@starling-software.com On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona wrote: Java is part of the Java platform, that brought OS independence and interoperability at the right time. .Download-execution on the client was also a reason for the initial success of Java in the Internet era. I was a die-hard Java hacker from 1999 until some undetermined time in the early-to-mid-2000s. (I abandoned it more or less completely sometime around late 2005, if I recall correctly.) This may be somewhat anecdotal evidence, but I disagree with both of your statements here. Of course, I´m not talking about real advantages of Java or any PL. I told about the reasons that people used at the time to introduce the language in the mainstream, either is desirable this for haskell or not. I think it is. Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. Rubi and Python came with libraries targeted to Rapid development of Internet applications. No, neither originally came with that. Rubi and Pyton came into existencie without their internet libraries, but they would´nt be popular without them. Although I conffess I don´t know the history in detail. What is the vehicle that haskell can use to enter the mainstream?. That may be the wrong question. Avoid success at all costs still rings true to me. A year or so ago I seemed like one of the few on the haskell-libraries list voting in favour of fixing API problems in libraries, rather than etching in stone those problems in the name of backwards compatibility so that we could become more popular. Said above. We have different goals. Do you really want, in 2020, to look back at the 2010 revision of the Haskell standard and think, we entrenched things that for a decade everybody agreed was dumb? I see no problem in haskell having both. experimental and fixed versions. Haskell 2020 for you and me and haskell 2010 for my commercial code. Both woukd ve maintained and enriched by far more people. I can tell you, even when you're a Java enthusiast, there's nothing more depressing than looking at java.util.Date and thinking, That should have been immutable, but it's going to be mutable for the rest of eternity. We will never fix that. But let's try this again: What is the vehicle that haskell can use to enter the mainstream?. Become more stupid. Is that a better answer? I'm not just a geek; I do marketing too (this is what happens when you start your own company), and if you asked me, using the utmost of my technical knowledge and marketing skills, to make Haskell popular, this is what I'd recommend. Become more stupid may mean give exactly what the people want that transaltes to be more stable, give libraries, platforms etc. That is not a extra effor. that will come naturally as more people use the language. some people is naturally more abstract. some are more practical. (I suppose it's a sign of my professionalism that to do this would nearly break my heart, but if you wanted me to tell you the best way to do this, and I couldn't tell you to get lost, that's what I'd say.) Many people will play with Haskell in the spare time, and many of them will be permitted to develop some non critical applications at work. But that is all. Hm. So I suppose that this options trading system I'm working on, which is the sole way our business makes money and is entirely written in Haskell, doesn't actually exist. Congratulations.!! I think that all the current niches are filled, but new niches are coming. Haskell already has a good niche. In fact, a brilliant one. We have a whole bunch of academics doing truly wonderful stuff (imagine the world without monads!--thank you Philip Wadler (and Eugenio Moggi)) that the rest of us (relatively) dumb idiots can use to make our lives better. We've got several very good implementations of the language, one of which is a truly shit-hot compiler[1]. And we can use that to do commercial applications quite comfortably[2]. Right. ;) My personal opinion is, yes, let's let Haskell stick to the niche where it's great, but it changes so fast that it's scary to everybody else. To echo Paul Graham, I'm extremely happy to see my competition use Java. [1] Like that's so important. Ruby's standard implementation to this day is an interpreter that implements all the popular extensions and has a reasonably decent FFI. In Haskell-land, we call that Hugs. It's only because we have GHC as well that we can look down on Hugs; in the Ruby (and Python, and PHP) worlds, they're saying that interpreters are just fine for all sorts of enterprise applications. [2] (Warning: self-promotion): http://www.starling-software.com/misc/icfp-2009-cjs.pdf Financial applications are an example of higher level programming where tasks usually
Re: [Haskell-cafe] Any working example of using genericserialize?
On Wed, Sep 30, 2009 at 3:37 AM, Dimitry Golubovsky golubov...@gmail.comwrote: Hi, I am trying to use the genericserialize package (http://hackage.haskell.org/package/genericserialize) but cannot get things working. While buildList (sexpSerialize [1, 2, 3]) yields (1 2 3) as it might be expected, I cannot deserialize it back: *Main (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Integer] Nothing or *Main (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Int] Nothing while I would expect at least one of these cases result in Just [1, 2, 3] What am I missing? I'm not sure. I've never seen this library before, but I noticed this: withList sexpDeserialize $ 12 :: Maybe Int 12 withList sexpDeserialize $ (12) :: Maybe [Int] Just [12] So it would seem that the sexpDeserialize is not handling the spaces in the input. But, I don't think that's the real problem, look at this: withList sexpDeserialize $ \1 2 3\ :: Maybe String Just 1 2 3 withList sexpDeserialize $ (\1 2 3\) :: Maybe String Nothing withList sexpDeserialize $ (\1 2 3\) :: Maybe [String] Just [1 2 3] So, it seems that the parens are making it into a list. But, this fails also: withList sexpDeserialize $ (\1\ \2\ \3\) :: Maybe [String] Nothing Seems like using withList is wrong or the deserializer is simply buggy. It certainly doesn't work the way I would expect SExp reading to work. I also notice from reading the source on hackage that there may not be any tests for this package and it is a 0.1 release. I'd contact the author, as it seems there is a deficiency in the documentation or a bug in the implementation. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Deniz Dogan wrote: 2009/9/30 Andrew Coppin andrewcop...@btinternet.com: (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. Sounds more like Mr C++ fundamentally thinks in an imperative way because that's what he is used to. This may or may not be true. It would be interesting to see some research on this. Without that, I think we cannot decide either way. Cheers, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
The cross-platform features have been extremely important to the success of Java, because they have greatly expanded the number of libraries available to developers. On Haskell Cafe, not a week goes by that Windows (and sometimes Mac) developers don't complain about not being able to use some Hackage library because of cross-platform issues. The actual number of people encountering these issues is orders of magnitude larger than the number of posts you see here. These issues impede the growth of Haskell significantly. Moreover, the importance of cross-platform libraries on the Java platform is evinced by the fact that developers of major native libraries _always_ make their libraries cross-platform (Jogl, jmonkeyengine, swt, etc.). They wouldn't go to this trouble if it weren't something the community was demanding. From a risk management perspective, a manager really likes the ability to seamlessly move across platforms and architectures without recompilation. 32 - 64? No problem. Linux - BSD? Sure, why not? Yes, I'm sure even Amazon, Yahoo, and Google make these kinds of considerations. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 30, 2009, at 5:28 AM, Alberto G. Corona wrote: Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
Hi, On 9/30/09, Jason Dagit da...@codersbase.com wrote: [skip] Seems like using withList is wrong or the deserializer is simply buggy. It certainly doesn't work the way I would expect SExp reading to work. I also notice from reading the source on hackage that there may not be any tests for this package and it is a 0.1 release. I'd contact the author, as it seems there is a deficiency in the documentation or a bug in the implementation. Thanks Jason for trying this. The genericserialize package is probably not finished yet. What else exists that could be used to serialize in generic way (i. e., anything that is an instance of Data and Typeable) into a string? It does not need to be very efficient as structures to be serialized are not huge (but may be pretty complex), and serialization is a part of an utility not to be used frequently. It only needs to just work. One thing I thought of was to serialize to JSON (there is a generic serializer in one of packages although I did not test it other way) which has higher overhead than S-expressions though. Any other thoughts? Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
Thanks for the answers. I already had a look at Binary but, as said above, it doesn't support bit manipulation, only bytes. On Wed, Sep 30, 2009 at 11:18:03AM +0200, paul.brau...@loria.fr wrote: Hello, I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. I have written one which seems very inefficient : toWord8 :: [Bool] - Word8 toWord8 bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs Is there a better way to do this out there ? (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). Cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? On Wed, Sep 30, 2009 at 1:58 PM, Jochem Berndsen joc...@functor.nl wrote: Deniz Dogan wrote: 2009/9/30 Andrew Coppin andrewcop...@btinternet.com: (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. Sounds more like Mr C++ fundamentally thinks in an imperative way because that's what he is used to. This may or may not be true. It would be interesting to see some research on this. Without that, I think we cannot decide either way. Cheers, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.comjoc...@%e7%89%9b%e5%9c%a8%e7%94%b0%e9%87%8c.com ___ 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: Fwd: [Haskell-cafe] suggestion for hslogger
If you want to send me a patch that makes it an option (not mandatory), I would be happy to apply it. -- John Antoine Latter wrote: Forwarding on to the maintainer, in case he's not on the list. -- Forwarded message -- From: Sean McLaughlin sean...@gmail.com Date: Tue, Sep 29, 2009 at 1:31 PM Subject: [Haskell-cafe] suggestion for hslogger To: haskell-cafe@haskell.org Hello, I have a program that does a lot of unicode manipulation. I'd like to use hslogger to log various operations. However, since hslogger uses System.IO.putX, the unicode comes out mangled. I hacked the source to use System.IO.UTF8 instead, but it would be nice if that was an option so I don't have to rehack the code whenever there is a new release. Thanks! Sean ___ 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] convert a list of booleans into Word*
Hello Paul, Wednesday, September 30, 2009, 1:18:03 PM, you wrote: I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. sum . zipWith (*) (map (2^) [0..]) -- 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] convert a list of booleans into Word*
Bulat Ziganshin wrote: Hello Paul, Wednesday, September 30, 2009, 1:18:03 PM, you wrote: I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. sum . zipWith (*) (map (2^) [0..]) I'd turn this into sum . zipWith (*) (iterate (2*) 1) , but it's probably not very important. Regards, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
...Or let's fuse it. sum . zipWith ((*).(2^)) [0..] 2009/9/30 Jochem Berndsen joc...@functor.nl: Bulat Ziganshin wrote: Hello Paul, Wednesday, September 30, 2009, 1:18:03 PM, you wrote: I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. sum . zipWith (*) (map (2^) [0..]) I'd turn this into sum . zipWith (*) (iterate (2*) 1) , but it's probably not very important. Regards, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
FWIW, writing your own is not hard. I wrote a serializer for GHC using Data in less than 150 (simple) LOC. It produces [Word8], but producing strings instead would be easy. You can check out the code here: http://darcs.haskell.org/ghc/compiler/utils/Serialized.hs Cheers, Max 2009/9/30 Dimitry Golubovsky golubov...@gmail.com: Hi, On 9/30/09, Jason Dagit da...@codersbase.com wrote: [skip] Seems like using withList is wrong or the deserializer is simply buggy. It certainly doesn't work the way I would expect SExp reading to work. I also notice from reading the source on hackage that there may not be any tests for this package and it is a 0.1 release. I'd contact the author, as it seems there is a deficiency in the documentation or a bug in the implementation. Thanks Jason for trying this. The genericserialize package is probably not finished yet. What else exists that could be used to serialize in generic way (i. e., anything that is an instance of Data and Typeable) into a string? It does not need to be very efficient as structures to be serialized are not huge (but may be pretty complex), and serialization is a part of an utility not to be used frequently. It only needs to just work. One thing I thought of was to serialize to JSON (there is a generic serializer in one of packages although I did not test it other way) which has higher overhead than S-expressions though. Any other thoughts? Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ 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: Re: [Haskell-cafe] Problem with result-type context restrictions in typeclasses.
I think
instance Bar (Ret c) = Foo c where
...
will do what you are asking.
Alex
On Tue, Sep 29, 2009 at 10:25 PM, DNM dnme...@gmail.com wrote:
Dan, thanks again for the response.
I changed my code to use type families to let each Cls instance (actually a
more complicated instance in my code) determine which Bar instance type it
will return, but this didn't seem to work. The problem is that the client
of the typeclass instance methds ('useThisStuff', which calls on 'toNum' and
'foo' in the contrived example) expects some guarantee that (Ret c) is going
to be an instance of Bar. The actual client code I'm using complains when
it sees that the associated type doesn't guarantee that an instance of the
appropriate class is instantiated. I don't see any way to guarantee this
without adding a context restriction in the class-level definition of Ret c,
something like:
class Cls c where
type Ret c :: (Bar *) = * -- or a better name
foo :: c - Ret c
which isn't legal Haskell. What I want to say is define Ret c however you
want, but make sure it is an instance of Bar in the *class-level definition
of Ret c*, so that any client of 'Cls' will know that Ret c will be
foo-able.
Maybe I'm missing some subtlety of type families...
Any suggestions?
--D.N.
Daniel Peebles wrote:
In your class, you have:
class Cls c where
foo :: (Bar b) = c - b
There's an implicit forall for b, meaning that the caller of the
method gets to choose what it wants for b (as long as it's an instance
of Bar). For you to be able to write such a method you'd need to write
functions that can return any instance of Bar. One solution to this is
to turn on the GHC extension -XTypeFamilies, and then modify your code
as follows:
class Cls c where
type Ret c :: * -- or a better name
foo :: c - Ret c
instance Cls G where
type Ret G = FU
foo = fuu
That should work (although I haven't tested it).
What type families do in this case is allow you to write not only
methods associated with typeclasses, but type functions associated
with them too. In this case you can think of Ret as a function that
takes a type (G in the instance above) and returns another type (FU).
Each instance can define new mappings for Ret.
Hope this helps!
Dan
On Tue, Sep 29, 2009 at 10:48 PM, DNM dnme...@gmail.com wrote:
Correction by the author:
It seems that ghc doesn't like the fact that I am saying 'foo' must
return a class 'b' of typeclass 'Bar', while providing a function that
returns a concrete data instance of 'Bar' (viz., FU or FI) later on
when I implement 'foo' in each type classes.
Should read:
It seems that ghc doesn't like the fact that I am saying 'foo' must
return something of TYPE 'b' implementing typeclass 'Bar', while
providing
a function that returns a concrete data instance of 'Bar' (viz., FU or
FI)
later on when I implement 'foo' in each type classes.
On Sep 29, 10:43 pm, DNM dnme...@gmail.com wrote:
N.B. I'm a newbie to Haskell, and this problem is a bit complex, so
bear with me.
I'm using typeclasses to implement a sort of common interface for all
things -- call them things of type 'Cls' -- that can be expected to
implement a set of functions -- an 'interface' in OOP-speak. (Yes,
yes, I'm aware that typeclasses are subtly different and far superior,
but my Haskell-ese is still a bit rudimentary.)
Essentially, I want to have a typeclass that expects its instances to
have an accessor function that results in something that is an
instance of another typeclass whose instances can perform some
operation. The ghc type-checker doesn't seem to like my code,
though, and I can't seem to figure out why.
To make it concrete, I've typed up some dummy typeclasses and a dummy
function that uses their instances to illustrate what I mean, as well
as the form of the ghc(i) error.
- BEGIN CODE --
class Cls c where
foo :: (Bar b) = c - b
class Bar b where
toNum :: b - Int
-- | One implementation of Cls
data D = D {fu :: FU}
data FU = FU {num :: Int}
instance Cls D where
foo = fu
instance Bar FU where
toNum f = (num f) + 47
-- | Another implementation of Cls
data E = E {fi :: FI}
data FI = FI {nuum :: Int}
instance Cls E where
foo = fi
instance Bar FI where
toNum f = (nuum f) + 100
-- | Yet another (this one re-uses FI)
data F = F {fii :: FI}
instance Cls F where
foo = fii
-- | And one last one, just to stress that
-- I really need to implement multiple
-- instances of Cls.
data G = G {fuu :: FU}
instance Cls G where
foo = fuu
-- | Good. Now, the function 'useThisStuff' need
-- not know anything about it's payload
-- other than that it its args are Cls's
-- (hence they are foo'able things that
-- can be used to construct an Int answer).
useThisStuff :: (Cls x, Cls y) = x - y - Int
useThisStuff x y =
(toNum $ foo x) + (toNum $ foo y)
[Haskell-cafe] New OpenGL package: efficient way to convert datatypes?
The newest package seems to require using GLdouble/GLfloat. What is the most efficient way to convert Double/Float to GLdouble/GLfloat? I'm currently using realToFrac. But essentially the operation should be a nop on my machine. I haven't looked at the core code yet (on Windows, last time I checked, the ghc-core util did not work, and without it, reading core is even harder) Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] I read somewhere that for 90% of a wide classof computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
As one C++ expert I know is fond of telling me, Haskell will only become popular when obscure mathematics becomes popular. That might be true, but the calculus and even arithmetic were once considered obscure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide classof computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Mmm, to the average student calculus is still very obscure ;-) On Wed, Sep 30, 2009 at 3:56 PM, Kalani Thielen kthie...@lab49.com wrote: As one C++ expert I know is fond of telling me, Haskell will only become popular when obscure mathematics becomes popular. That might be true, but the calculus and even arithmetic were once considered obscure. ___ 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[2]: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
Hello Max, Wednesday, September 30, 2009, 5:53:37 PM, you wrote: afaik, SYB just provides gshow/gread functions what serialize any Data instance to String FWIW, writing your own is not hard. I wrote a serializer for GHC using Data in less than 150 (simple) LOC. It produces [Word8], but producing strings instead would be easy. You can check out the code here: http://darcs.haskell.org/ghc/compiler/utils/Serialized.hs Cheers, Max 2009/9/30 Dimitry Golubovsky golubov...@gmail.com: Hi, On 9/30/09, Jason Dagit da...@codersbase.com wrote: [skip] Seems like using withList is wrong or the deserializer is simply buggy. It certainly doesn't work the way I would expect SExp reading to work. I also notice from reading the source on hackage that there may not be any tests for this package and it is a 0.1 release. I'd contact the author, as it seems there is a deficiency in the documentation or a bug in the implementation. Thanks Jason for trying this. The genericserialize package is probably not finished yet. What else exists that could be used to serialize in generic way (i. e., anything that is an instance of Data and Typeable) into a string? It does not need to be very efficient as structures to be serialized are not huge (but may be pretty complex), and serialization is a part of an utility not to be used frequently. It only needs to just work. One thing I thought of was to serialize to JSON (there is a generic serializer in one of packages although I did not test it other way) which has higher overhead than S-expressions though. Any other thoughts? Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ 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 -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
Bulat, OK, gread/gshow seem to be like the basis primitives. If they work properly, then it is what is needed. Thanks. On 9/30/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Max, Wednesday, September 30, 2009, 5:53:37 PM, you wrote: afaik, SYB just provides gshow/gread functions what serialize any Data instance to String FWIW, writing your own is not hard. I wrote a serializer for GHC using Data in less than 150 (simple) LOC. It produces [Word8], but producing strings instead would be easy. You can check out the code here: http://darcs.haskell.org/ghc/compiler/utils/Serialized.hs Cheers, Max [skip] -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
Very fast for long boolean lists by using a strict foldl and reversing the input: bsToInt :: [Bool] - Integer bsToInt = foldl' ((.fromIntegral.fromEnum).(+).join(+)) 0. reverse Try this: (1) $ bsToInt $ take 10 $ cycle [True,True,False,True,True,False,True] bitsToInt :: [Bool] - Integer bitsToInt = foldr((.(flip shiftL 1)).(+)) 0. map (fromIntegral.fromEnum) -- Met vriendelijke groet, =@@i ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: frag game-compiling error
On Mon, Sep 28, 2009 at 11:36 AM, selahaddin selahattin.ger...@gmail.com wrote: Lyndon Maydwell wrote: src/Quaternion.hs:22:27 This would probably be the place to start. Ok,I managed to get past the error like this: newMatrix ColumnMajor [realToFrac r00,realToFrac r01,realToFrac r02,realToFrac r03, realToFrac r10,realToFrac r11,realToFrac r12,realToFrac r13, realToFrac r20,realToFrac r21,realToFrac r22,realToFrac r23, realToFrac r30,realToFrac r31,realToFrac r32,realToFrac r33] So Quaternion.hs compiled fine,but now it gives error messages in another file. As far as I understand, this games code is incompatible with the new version of haskell opengl libraries. Am I right? A style note: it looks to me like it'd be better to write 'newMatrix columnMajor $ map realToFrac $ [r1...' Did that get Frag compiling working? If it did, perhaps you could send in a patch to dons, who is the listed maintainer of frag. -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. Luckily, this is being fixed ... by the Free Software movement. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Peter Verswyvelen wrote: I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say something about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. Very few of them will answer that the sum of an empty list is defined to be zero, and the sum of a non-empty list is defined to be the first number plus the sum of the list tail. Then again, few non-programmers will set anything about creating a counter variable and initialising it to zero either; this is a programming artifact. (Humans don't think like this internally, but most programming languages conceptually require it.) Nobody has much difficulty with this, so maybe the only problem with Haskell is that everybody learns to program the other way first, before they get to Haskell... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Wed, Sep 30, 2009 at 12:32 AM, Andrew Coppin andrewcop...@btinternet.com wrote: Casey Hawthorne wrote: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language. If this is true, it needs to be pushed. And if by changing a few lines of source code one can develop a whole family of similar applications, that needs to be pushed, also. :) As one C++ expert I know is fond of telling me, Haskell will only become popular when obscure mathematics becomes popular. You can argue about whether or not this is true. Myself I think we just need to start documenting things more clearly. (E.g., Mr C++ apparently spent half an hour trying to figure out why an expression wouldn't parse. Turns out you have to write negative numbers in brackets. Which isn't hard, but you have to already know this.) It's clear Haskell has become popular, and without the need for the obscure math. (though I have to admit, I find the math highly interesting, yet I'm quite the novice) I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. (Not to mention some of the standard I/O functions doing slightly strange things because GHC is calling POSIX compatibility functions rather than native I/O functions. For example, doesDirectoryExist C:\\ = False.) YES The lack of a big shiny whizzy-looking IDE probably stops quite a few people too. (I gather the Leksah guys are working on that one.) I personally have found 2 IDEs to be worth bothering with in my entire life. One is Visual Studio. The other is Borland's Turbo C++ 3.0 IDE for DOS. (I even coerced it to run on my 16MHz 286 geeze 16MHz was fast back then :-) ) Lack of a good way to write native-looking Windows GUI applications - or indeed any GUI applications without requiring a stack of DLLs - probably doesn't help either. None of these look fundamentally insumountable to me. (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. We shall see...) I think that's a bunch of garbage :-). People think algorithmically, or we wouldn't design algorithms to deal with complexity. Algorithms very often have steps that are quite imperative, but many of the sub-pieces of a step are clearly pure and functional. Being able to see the difference in a set of instructions, and being able to isolate them, can be quite a powerful way to break a problem down to a manageable set of steps. If it wasn't, Functional Programming would have died long ago, and it clearly hasn't, and is gaining ground. See F#, Erlang, O'Caml, and Haskell. I don't think you can argue with the quantitative data that is the user base. The number of people in #haskell on freenode, or the subscribers on Reddit. People are paying attention and trying it out. Whether haskell will completely fail to Avoid success at all costs or not is hard to say :-). In fact, Intel is porting their concurrent collections libraries to Haskell now. How's that for an endorsement? (It *was* just a C++ library). Tell your friend to stick that in their pipe and smoke it... then pass it to me! :-) Dave ___ 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] Market Place for Haskell development teams?
fwiw I found it difficult getting a Haskell installation onto Windows. Packages that would 'cabal install' just fine on Linux were much more of a pain on Windows. Eventually, I actually found it easiest to cross compile to Windows using wine: wine HaskellPlatform-2009.2.0.2-setup.exe wine cabal wine cabal install yst The resulting yst.exe seems to work fine on actual Windows machines. Quite cool I thought as I prefer to stay in Linux, but if you're starting from a Windows based development environment, Haskell does seem problematic. -Rob John A. De Goes wrote: The cross-platform features have been extremely important to the success of Java, because they have greatly expanded the number of libraries available to developers. On Haskell Cafe, not a week goes by that Windows (and sometimes Mac) developers don't complain about not being able to use some Hackage library because of cross-platform issues. The actual number of people encountering these issues is orders of magnitude larger than the number of posts you see here. These issues impede the growth of Haskell significantly. Moreover, the importance of cross-platform libraries on the Java platform is evinced by the fact that developers of major native libraries _always_ make their libraries cross-platform (Jogl, jmonkeyengine, swt, etc.). They wouldn't go to this trouble if it weren't something the community was demanding. From a risk management perspective, a manager really likes the ability to seamlessly move across platforms and architectures without recompilation. 32 - 64? No problem. Linux - BSD? Sure, why not? Yes, I'm sure even Amazon, Yahoo, and Google make these kinds of considerations. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 30, 2009, at 5:28 AM, Alberto G. Corona wrote: Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. ___ 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] New OpenGL package: efficient way to convert datatypes?
If you are *really* sure that the runtime representation is the same you could use usafeCoerce. You could use a small test function for profiling, something like: convertGLfloat :: GLfloat - Float convertGLFloat = realToFrac -- convertGLFloat = unsafeCoerce and toggle between the two (assuming you won't get a segmentation fault). Another option is to not convert at all but use the GL types everywhere. Either explicitly or by exploiting polymorphism. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Sure, but it doesn't mean that because someone uses an imperative way of counting, that it means people's brains work imperatively all the way. People tend to talk and communicate a lot in a declarative way no? For example ask someone that doesn't know programming how he we would make a paddleball game. I have no idea what that person would say, but I think it would something like: I tell the computer that the paddle should move along with the mouse; and when the ball bounces against the paddle, the ball reverses direction; if the paddle misses the ball, it's game over. I don't think anybody would say: each frame, the ball's position moves by a tiny timestep; when the mouse is sampled, copy the mouse position to the paddle; etc... On Wed, Sep 30, 2009 at 4:43 PM, Andrew Coppin andrewcop...@btinternet.comwrote: Peter Verswyvelen wrote: I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say something about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. Very few of them will answer that the sum of an empty list is defined to be zero, and the sum of a non-empty list is defined to be the first number plus the sum of the list tail. Then again, few non-programmers will set anything about creating a counter variable and initialising it to zero either; this is a programming artifact. (Humans don't think like this internally, but most programming languages conceptually require it.) Nobody has much difficulty with this, so maybe the only problem with Haskell is that everybody learns to program the other way first, before they get to Haskell... ___ 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] New OpenGL package: efficient way to convert datatypes?
I don't want to use the GL types directly since the OpenGL renderer is not exposes in the rest of the API. I was hoping that realToFrac would be a nop in case it would be identical to an unsafeCoerce. I guess one could make rules for that, but this tickets makes me wander if that really works: http://hackage.haskell.org/trac/ghc/ticket/1434 On Wed, Sep 30, 2009 at 4:58 PM, Roel van Dijk vandijk.r...@gmail.comwrote: If you are *really* sure that the runtime representation is the same you could use usafeCoerce. You could use a small test function for profiling, something like: convertGLfloat :: GLfloat - Float convertGLFloat = realToFrac -- convertGLFloat = unsafeCoerce and toggle between the two (assuming you won't get a segmentation fault). Another option is to not convert at all but use the GL types everywhere. Either explicitly or by exploiting polymorphism. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Am Mittwoch 30 September 2009 09:32:08 schrieb Andrew Coppin: I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. Contribute your share, switch to Linux or BSD 8-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
On Wed, Sep 30, 2009 at 7:54 AM, Robert Wills wrwi...@gmail.com wrote: fwiw I found it difficult getting a Haskell installation onto Windows. Packages that would 'cabal install' just fine on Linux were much more of a pain on Windows. Eventually, I actually found it easiest to cross compile to Windows using wine: The only time I have trouble with a Haskell library is when it requires some foreign library that isn't Windows friendly. HSQL and yi are two examples I remember from some time ago. However, many libraries are just fine: HDBC, lhs2tex, hlint, for example. The Haskell Platform has made this even simpler because I have a compatible base that I know will work. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: frag game-compiling error
gwern0: On Mon, Sep 28, 2009 at 11:36 AM, selahaddin selahattin.ger...@gmail.com wrote: Lyndon Maydwell wrote: src/Quaternion.hs:22:27 This would probably be the place to start. Ok,I managed to get past the error like this: newMatrix ColumnMajor [realToFrac r00,realToFrac r01,realToFrac r02,realToFrac r03, realToFrac r10,realToFrac r11,realToFrac r12,realToFrac r13, realToFrac r20,realToFrac r21,realToFrac r22,realToFrac r23, realToFrac r30,realToFrac r31,realToFrac r32,realToFrac r33] So Quaternion.hs compiled fine,but now it gives error messages in another file. As far as I understand, this games code is incompatible with the new version of haskell opengl libraries. Am I right? A style note: it looks to me like it'd be better to write 'newMatrix columnMajor $ map realToFrac $ [r1...' Did that get Frag compiling working? If it did, perhaps you could send in a patch to dons, who is the listed maintainer of frag. Please send patches! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Splitting data and function declarations over multiple files
I guess this is related to the expression problem. Suppose I have a datatype *data Actor = Ball ... | Paddle ... | Wall ...* and a function *move (Ball ...) = * *move (Paddle ...) = * *move (Wall ...) = * in Haskell one must put *Actor* and *move* into a single file. This is rather cumbersome if you work with multiple people or want to keep the files small and readable. Surely it is possible to use type classes, existentials, etc to split the data type into multiple ones, but that's already advanced stuff in a sense. But wouldn't it be possible to allow these to be put into multiple files, and let the compiler merge them back into one? A bit like C#'s partial keyword: in file Ball.hs: *partial data Actor = Ball ...* *move (Ball ...) =* in Paddle.hs *partial data Actor = Paddle ...* *move (Paddle ...) =* The compiler would then merge all partial data types and functions into one. As far as no overlap exists in the pattern matches in move, so that the order of the pattern matches does not matter at all, the partial trick should be possible no? Cheers, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
Hi Peter, sounds to me you want to have a look at Open Data Types and Open Functions by Andres Löh and Ralf Hinze: http://people.cs.uu.nl/andres/OpenDatatypes.pdf Cheers, /Niklas On Wed, Sep 30, 2009 at 5:54 PM, Peter Verswyvelen bugf...@gmail.com wrote: I guess this is related to the expression problem. Suppose I have a datatype data Actor = Ball ... | Paddle ... | Wall ... and a function move (Ball ...) = move (Paddle ...) = move (Wall ...) = in Haskell one must put Actor and move into a single file. This is rather cumbersome if you work with multiple people or want to keep the files small and readable. Surely it is possible to use type classes, existentials, etc to split the data type into multiple ones, but that's already advanced stuff in a sense. But wouldn't it be possible to allow these to be put into multiple files, and let the compiler merge them back into one? A bit like C#'s partial keyword: in file Ball.hs: partial data Actor = Ball ... move (Ball ...) = in Paddle.hs partial data Actor = Paddle ... move (Paddle ...) = The compiler would then merge all partial data types and functions into one. As far as no overlap exists in the pattern matches in move, so that the order of the pattern matches does not matter at all, the partial trick should be possible no? Cheers, Peter ___ 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] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On Mon, Sep 28, 2009 at 11:50 PM, Hong Yang hyang...@gmail.com wrote: learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better. The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already: import Data.Array.Diff import Data.IArray update :: (Char - [Int]) - DiffArray Int ModP - Char - DiffArray Int ModP update lookup arr c = arr // (map calc . lookup $ c) where calc i = (i, (arr ! i) + (arr ! (i-1))) solve line sol = (foldl' (update lookup) iArray line) ! snd (bounds iArray) where iArray = listArray (0, length sol) $ 1 : map (const 0) sol lookup c = map (+1) . findIndices (== c) $ sol I've not been following Haskell too much and am completely lost when reading code like that. I understand (+1), : and ! but what the hell are . and $ for? And that weird monad symbol in the Haskell logo is not even used! = Not quite the worst example of such line noise much of Haskell idiomatic code uses nowadays, though. Point is: = . $ : ! `` and meaningful whitespace are all nice shortcuts, but also hairy confusing... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On Wed, Sep 30, 2009 at 6:45 PM, namekuseijin namekusei...@gmail.comwrote: On Mon, Sep 28, 2009 at 11:50 PM, Hong Yang hyang...@gmail.com wrote: learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better. The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already: import Data.Array.Diff import Data.IArray update :: (Char - [Int]) - DiffArray Int ModP - Char - DiffArray Int ModP update lookup arr c = arr // (map calc . lookup $ c) where calc i = (i, (arr ! i) + (arr ! (i-1))) solve line sol = (foldl' (update lookup) iArray line) ! snd (bounds iArray) where iArray = listArray (0, length sol) $ 1 : map (const 0) sol lookup c = map (+1) . findIndices (== c) $ sol I've not been following Haskell too much and am completely lost when reading code like that. I understand (+1), : and ! but what the hell are . and $ for? And that weird monad symbol in the Haskell logo is not even used! = Not quite the worst example of such line noise much of Haskell idiomatic code uses nowadays, though. Point is: = . $ : ! `` and meaningful whitespace are all nice shortcuts, but also hairy confusing... I overall agree with the sentiment (I avoid declaring operators at all costs), but the example is a bad one. $, ., and = are all very basic to Haskell, and should be picked up almost immediately. As far as becoming line noise like Perl, well, I happen to like Perl :). Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
On Wed, Sep 30, 2009 at 8:54 AM, Peter Verswyvelen bugf...@gmail.comwrote: I guess this is related to the expression problem. Actually, this is exactly the expression problem :) Suppose I have a datatype *data Actor = Ball ... | Paddle ... | Wall ...* and a function *move (Ball ...) = * *move (Paddle ...) = * *move (Wall ...) = * in Haskell one must put *Actor* and *move* into a single file. This is rather cumbersome if you work with multiple people or want to keep the files small and readable. Surely it is possible to use type classes, existentials, etc to split the data type into multiple ones, but that's already advanced stuff in a sense. Yes, and type classes are the current solution. I think the most elegant solution right now is provided by Data Types a la Carte; see http://www.cse.chalmers.se/~wouter/publications.html But wouldn't it be possible to allow these to be put into multiple files, and let the compiler merge them back into one? A bit like C#'s partial keyword: in file Ball.hs: *partial data Actor = Ball ...* *move (Ball ...) =* in Paddle.hs *partial data Actor = Paddle ...* *move (Paddle ...) =* The compiler would then merge all partial data types and functions into one. As far as no overlap exists in the pattern matches in move, so that the order of the pattern matches does not matter at all, the partial trick should be possible no? Yes, that's true. There's some good reading about this proposal here: http://www.haskell.org/haskellwiki/Extensible_datatypes -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On Wed, Sep 30, 2009 at 11:45 AM, namekuseijin namekusei...@gmail.com wrote: I've not been following Haskell too much and am completely lost when reading code like that. I understand (+1), : and ! but what the hell are . and $ for? Function composition and lowest-precedence function application, respectively. And that weird monad symbol in the Haskell logo is not even used! = Not quite the worst example of such line noise much of Haskell idiomatic code uses nowadays, though. That's the monadic bind operator. As far as sugar, I think you've got it backwards — the do syntax is sugar for = and friends. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell for Physicists
Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
Hallo, On 9/30/09, ed...@ymonad.com ed...@ymonad.com wrote: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Haskell for physicists ? -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
Some ideas of highly variable quality: Getting Functional with Physics Bosons, Fermions, and Monads? Haskell for Physicists Purer Programming for Physicists Use Haskell for Physics, and Say 'C'-You-Later - ted On Wed, Sep 30, 2009 at 10:42 AM, ed...@ymonad.com wrote: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar ___ 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] Fwd: Uniplate + strict fields = fail. Why?
Hi,
I've been playing with generics in general (pardon the pun) and Uniplate in
particular, and found out that strict data fields somehow derail Uniplate.
Observe:
=== code ===
{-# LANGUAGE DeriveDataTypeable #-}
module Test where
import Data.Generics (Data(..),Typeable(..))
import Data.Generics.PlateData
import Data.ByteString
import Data.ByteString.Char8 as C
data Foo = Foo String deriving (Show, Data, Typeable)
tst1 = [ Foo a, Foo b ]
test1 = [ show x | Foo x - universeBi tst1 ]
-- *Test test1
-- [\a\,\b\]
data Bar = Bar ByteString deriving (Show, Data, Typeable)
tst2 = [ Bar (C.pack a), Bar (C.pack b) ]
test2 = [ show x | Bar x - universeBi tst2 ]
-- *Test test2
-- *** Exception: Prelude.undefined
=== end of code ===
First, I thought that instance of Data for ByteString is somehow deficient,
but this is not the case.
If you change definition of Foo to data Foo = Foo !String, you would get
the same error with Prelude.undefined.
Since all fields in ByteString constructors are strict, I have no joy trying
to use it with Uniplate.
Howere, my type-foo is not strong enough to understand what's wrong. Could
someone give me a hint?
PS
ghc 6.10.4
uniplate 1.2.0.3
bytestring 0.9.1.4
PPS
Neil Mitchell is receiving a copy of this email
--
Dmitry Astapov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide classof computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
В сообщении от 30 сентября 2009 18:05:28 Peter Verswyvelen написал: On Wed, Sep 30, 2009 at 3:56 PM, Kalani Thielen kthie...@lab49.com wrote: That might be true, but the calculus and even arithmetic were once considered obscure. Mmm, to the average student calculus is still very obscure ;-) Really? One professor said that it's possible to teach monkey to differentiate. In principle I agree with him (-; ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
В сообщении от 30 сентября 2009 15:58:40 Jochem Berndsen написал: Deniz Dogan wrote: 2009/9/30 Andrew Coppin andrewcop...@btinternet.com: (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. Sounds more like Mr C++ fundamentally thinks in an imperative way because that's what he is used to. This may or may not be true. It would be interesting to see some research on this. Without that, I think we cannot decide either way. Cheers, Jochem One of my first impressiions with haskell was absence of impendance mismatch between my thoughts and my code. This is not nessesarily true for everyone because people has different ways of thinking I beleive. P.S. And haskell doesn't have tendency to eat brain away like C++ does. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] convert a list of booleans into Word*
Bulat Ziganshin-2 wrote: sum . zipWith (*) (map (2^) [0..]) foldr1 $ \b - (+b) . (*2) -- View this message in context: http://www.nabble.com/convert-a-list-of-booleans-into-Word*-tp25677589p25686400.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) And what if they're in Portuguese? ;) Cheers, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
В сообщении от Среда 30 сентября 2009 22:37:52 вы написали: Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) And what if they're in Portuguese? ;) Nothing is impossible for a man with another dictionary then. (Portuguese- Russian if you don't mind :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
reminds me of a well-known story, told to me some years back at cornell: richard feynman was set to deliver a series of lectures in brazil, and he spent a good deal of time learning spanish in preparation; that was until a visting professor from brazil told him he might want to try portuguese instead On Wed, Sep 30, 2009 at 11:44 AM, Khudyakov Alexey alexey.sklad...@gmail.com wrote: В сообщении от Среда 30 сентября 2009 22:37:52 вы написали: Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) And what if they're in Portuguese? ;) Nothing is impossible for a man with another dictionary then. (Portuguese- Russian if you don't mind :) ___ 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] Haskell for Physicists
Khudyakov Alexey wrote: В сообщении от Среда 30 сентября 2009 22:25:14 вы написали: Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) I am also interested in seeing the slides (being a physicist myself). Also, that'd be portuguese, not spanish, that would be spoken in Brazil. The dictionary comment still applies though :) I suppose you aimed for cafe but missed. (: Yep, sure did. I just hit `reply' assuming haskell-cafe was in the reply-to. I do that more often than not it seems. Going back to the OP, what area of physics, and how on earth are you going to convert years of fortran users to haskell? I mean, in particle physics (were I came from) it seems as though only recently have they moved from fortran to C++ (note: C was skipped). There are things written in python (like Athena) but, well..., they are unreliable crap (I do like python though). In fact, when I was in undergraduate, not 4 years ago, a PhD student was writing his big QCD project in fortran from the ground up. I'm not even familiar enough with fortran to attempt such a thing (I would have used C). Case in point, I think there are some areas of physics that exist as a communal project (i.e. experimental particle physics) and because of this, you are limited to the tools and data used by your peers (Athena, Geant4, etc...). It is really hard to introduce anything new. So I guess my advice would be to avoid Haskell as a 'replacement' for anything to a physicist (including mathematica -- which I never liked myself). They will immediately ignore you. Approach it as a new tool, and focus on what it can do that software-x can't. That was my take on it though, so it may be a bit incorrect and/or biased. -Jack ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen bugf...@gmail.com wrote:
I guess this is related to the expression problem.
Suppose I have a datatype
data Actor = Ball ... | Paddle ... | Wall ...
and a function
move (Ball ...) =
move (Paddle ...) =
move (Wall ...) =
in Haskell one must put Actor and move into a single file.
This is rather cumbersome if you work with multiple people or want to keep
the files small and readable.
Surely it is possible to use type classes, existentials, etc to split the
data type into multiple ones, but that's already advanced stuff in a sense.
You can do it without type classes and existentials. The
functionality you want is already supported by Haskell, you just have
to let go of your syntactical expectations. The trick is that you
should rewrite your data type not as an algebra (a set of
constructors), but as a coalgebra (a set of projections).
Let's say your two open functions are:
move :: Actor - Actor
isAlive :: Actor - Bool
This gives rise to the definition of an Actor type:
data Actor = Actor { move :: Actor, isAlive :: Bool }
And then the alternatives of your open data type are just values of type Actor:
ball :: Vector - Vector - Actor
ball pos vel = Actor {
move = ball (pos + vel) vel,
isAlive = True
}
etc.
This trick works well until you get to the encoding of functions that
pattern match on multiple Actors at the same time. As far as I can
tell, that cannot be encoded in this style in any reasonable way.
Such functions must be rephrased in a coalgebraic style; i.e. instead
of asking about constructors, using projection functions it knows are
available.
So for example instead of implementing collide by asking about
pairs, add functions which report a shape function and a normal, or
whatever your collide algorithm needs from shapes.
You would probably end up having to do this anyway even with your
proposed extension, because watch:
partial data Actor = Ball ...
collide (Ball ...) (Ball ...) = ...
collide (Ball ...) x = ...
We don't know about any other constructors, so the second line has to
contain a pattern-free x. So you would have to use projection
functions to get any information about it, exactly as you would when
you're writing in the coalgebraic style.
So, Yes! Haskell can do that!
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Again, i missed to forward the message to the list:
I experince also the drug effect. Evolutionary psychologists would say that,
because it was vital for our survival, since the stone age, we appreciate
any tool powerful enough to solve many problems while at the same time
remain simple. So whenever the utility versus learning.-using-,maintaining
costs of a tool is low. then the tool is more appreciated and more pleasure
we experiencie by using it. That applies either to a sword, a horse, a car
or a programming language.
Haskell has an execution strategy and a type system that cares for himself
about code consistency and a reasonable optimization, It has only a few
keywords, and a intuitive syntax , But combining the security that gives the
first two factors and the flexibility of the other two, one can reach high
levels of abstraction maintaining a high degree of confidence in the
generated code, And such code can be applied to a wider variety of
problems.
For that matter I think that while other languages can borrow some features
of haskell, they will never have the power that can be achieved by having
them all. And most of them are deep in the core.
2009/9/30 Peter Verswyvelen bugf...@gmail.com
Yep, LINQ makes C# more enjoyable :-) Scala and haXe also look nice, a bit
of a mix between OCaml/F#, C#/Java and Haskell.
Besides the fact that hacking in Haskell is a great deal of fun, the main
reason I see for learning Haskell: it makes you a better programmer. After
a couple of years of playing with Haskell, I can now solve problems that I
couldn't before. It's of course hard to tell if Haskell is the reason here,
or just experience, but I feel it really is Haskell (actually, functional
programming). Haskell made me see the world in a different way (and if I see
Oleg's and co's code, I still have an infinitely long road ahead.
The main reason why you should not learn Haskell: it's a bit of a drug;
after you learned Haskell, programming in an industrial strength language
suddenly feels like a waste of time, time better spent learning more
Haskell...
On Wed, Sep 30, 2009 at 10:26 AM, Deniz Dogan
deniz.a.m.do...@gmail.comwrote:
2009/9/30 Andrew Coppin andrewcop...@btinternet.com:
(Mr C++ argues that homo sapiens fundamentally think in an imperative
way,
and therefore functional programming in general will never be popular.
Sounds more like Mr C++ fundamentally thinks in an imperative way
because that's what he is used to.
I recently started working with C# and struggled for way too long with
for/foreach loops to do things that in Haskell could be expressed
using only folding, mapping and filtering. When I realised that those
ideas actually exist in System.Linq I suddenly started liking the
language a bit more.
txtCommaSeparatedNames.Text.Split(',').Select(x = x.Trim()).Where(x
= x.Length 0).Select(x = Convert.ToInt32(x)).ToList();
Ah, the joy of FP.
--
Deniz Dogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Haskell for Physicists
I´m a physicist, so I think they would be attracted by something like Haskell: high level physics modelling at Fortran speeds Haskell: mathematics beyond numerical calculus 2009/9/30 ed...@ymonad.com Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar ___ 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
Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
I would say that pure knowledge is pure and functional. but human planning and problem solving is imperative because implies sequencing of operations based on this pure knowledge. haskell express both nicely. 2009/9/30 Andrew Coppin andrewcop...@btinternet.com Peter Verswyvelen wrote: I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say wsomething about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. Very few of them will answer that the sum of an empty list is defined to be zero, and the sum of a non-empty list is defined to be the first number plus the sum of the list tail. Then again, few non-programmers will set anything about creating a counter variable and initialising it to zero either; this is a programming artifact. (Humans don't think like this internally, but most programming languages conceptually require it.) Nobody has much difficulty with this, so maybe the only problem with Haskell is that everybody learns to program the other way first, before they get to Haskell... ___ 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
Fwd: [Haskell-cafe] Market Place for Haskell development teams?
forwarded to the list: Curt, Rubi and Pyton came into existencie without their internet libraries, but they would´nt be popular without them. Although I conffess I don´t know the history in detail. Academics is not mainstream. 2009/9/29 Curt Sampson c...@starling-software.com On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona wrote: Java is part of the Java platform, that brought OS independence and interoperability at the right time. .Download-execution on the client was also a reason for the initial success of Java in the Internet era. I was a die-hard Java hacker from 1999 until some undetermined time in the early-to-mid-2000s. (I abandoned it more or less completely sometime around late 2005, if I recall correctly.) This may be somewhat anecdotal evidence, but I disagree with both of your statements here. Of course, I´m not talking about real advantages of Java or any PL. I told about the reasons that people used at the time to introduce the language in the mainstream, either is desirable this for haskell or not. I think it is. Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. Rubi and Python came with libraries targeted to Rapid development of Internet applications. No, neither originally came with that. Rubi and Pyton came into existencie without their internet libraries, but they would´nt be popular without them. Although I conffess I don´t know the history in detail. What is the vehicle that haskell can use to enter the mainstream?. That may be the wrong question. Avoid success at all costs still rings true to me. A year or so ago I seemed like one of the few on the haskell-libraries list voting in favour of fixing API problems in libraries, rather than etching in stone those problems in the name of backwards compatibility so that we could become more popular. Said above. We have different goals. Do you really want, in 2020, to look back at the 2010 revision of the Haskell standard and think, we entrenched things that for a decade everybody agreed was dumb? I see no problem in haskell having both. experimental and fixed versions. Haskell 2020 for you and me and haskell 2010 for my commercial code. Both woukd ve maintained and enriched by far more people. I can tell you, even when you're a Java enthusiast, there's nothing more depressing than looking at java.util.Date and thinking, That should have been immutable, but it's going to be mutable for the rest of eternity. We will never fix that. But let's try this again: What is the vehicle that haskell can use to enter the mainstream?. Become more stupid. Is that a better answer? I'm not just a geek; I do marketing too (this is what happens when you start your own company), and if you asked me, using the utmost of my technical knowledge and marketing skills, to make Haskell popular, this is what I'd recommend. Become more stupid may mean give exactly what the people want that transaltes to be more stable, give libraries, platforms etc. That is not a extra effor. that will come naturally as more people use the language. some people is naturally more abstract. some are more practical. (I suppose it's a sign of my professionalism that to do this would nearly break my heart, but if you wanted me to tell you the best way to do this, and I couldn't tell you to get lost, that's what I'd say.) Many people will play with Haskell in the spare time, and many of them will be permitted to develop some non critical applications at work. But that is all. Hm. So I suppose that this options trading system I'm working on, which is the sole way our business makes money and is entirely written in Haskell, doesn't actually exist. Congratulations.!! I think that all the current niches are filled, but new niches are coming. Haskell already has a good niche. In fact, a brilliant one. We have a whole bunch of academics doing truly wonderful stuff (imagine the world without monads!--thank you Philip Wadler (and Eugenio Moggi)) that the rest of us (relatively) dumb idiots can use to make our lives better. We've got several very good implementations of the language, one of which is a truly shit-hot compiler[1]. And we can use that to do commercial applications quite comfortably[2]. Right. ;) My personal opinion is, yes, let's let Haskell stick to the niche where it's great, but it changes so fast that it's scary to everybody else. To echo Paul Graham, I'm extremely happy to see my competition use Java. [1] Like that's so important. Ruby's standard implementation to this day is an interpreter that implements all the popular extensions and has a reasonably decent FFI. In Haskell-land, we call that Hugs. It's only because we have GHC as well that we can look down on Hugs; in the Ruby (and Python, and PHP) worlds, they're saying that interpreters are just fine
Re: [Haskell-cafe] Haskell for Physicists
On Wed, Sep 30, 2009 at 9:24 PM, Alberto G. Corona agocor...@gmail.com wrote: Haskell: mathematics beyond numerical calculus I'd imagine most physicists know a fair bit of mathematics beyond numerical calculus; what they might not know much about is *computation* beyond numerical calculus. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
This reminds me of the whole agent thing -- pretty much dominated by Java (e.g., Jade, Jason, Jack) nowadays --, for which I would bet lots things are done more straigthforward using Haskell -- especially those parts the Java coders are usually proud of... Let's maybe speak of *second order scalability*: As first order scalability would rather be a matter in space time load increased by repetitions, the concern of second order scalability would be more about a *fractal* expansion of concepts like a *closure* -- Haskell, already in a vivid exchange with interactive theorem proving (e.g. Coq adopts type classes from Haskell and dependent types vice versa) seems excellently prepared... :-) Interesting. I´m working in something like second order scalability. Instead of brute performance by redundancy, high speed networks and fast disks, scalability can be achieved by looking at the properties of the data. I ever tended to say financial applications are especially prone to be boring -- the prototype of repetitive IT, even for strategy the stupid 'traffic lights cockpits' or OLAP(!) ... But this problem is rather supply driven to me. For sure. This is supply driven. There are a lack of new ideas mainly because the technology is low level and obsolete. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
В сообщении от Среда 30 сентября 2009 23:08:02 вы написали: Yep, sure did. I just hit `reply' assuming haskell-cafe was in the reply-to. I do that more often than not it seems. Going back to the OP, what area of physics, and how on earth are you going to convert years of fortran users to haskell? I mean, in particle physics (were I came from) it seems as though only recently have they moved from fortran to C++ (note: C was skipped). There are things written in python (like Athena) but, well..., they are unreliable crap (I do like python though). In fact, when I was in undergraduate, not 4 years ago, a PhD student was writing his big QCD project in fortran from the ground up. I'm not even familiar enough with fortran to attempt such a thing (I would have used C). Case in point, I think there are some areas of physics that exist as a communal project (i.e. experimental particle physics) and because of this, you are limited to the tools and data used by your peers (Athena, Geant4, etc...). It is really hard to introduce anything new. So I guess my advice would be to avoid Haskell as a 'replacement' for anything to a physicist (including mathematica -- which I never liked myself). They will immediately ignore you. Approach it as a new tool, and focus on what it can do that software-x can't. I'm particle physicist too. And sometimes I think that it would be better if they stay with fortran. Object-disoriented which is done in C++ scares me. Random segfaults in ROOT, or even worse segfault loops... It's possible to use safety as argument for haskell. Type safety, no segfaults. As for existing code there are two strategies. First is to dump all code into Geneva lake. There are environmental concerns of course. And it's difficult to throw away tested code. Second one - do not touch it and use haskell for small isolated tasks. It's easier to do this in smaller experiments. I use haskell to process experimental data with reasonable success. Code is much cleaner and easier to understand that C++ code. In fact I just reworded your statement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
В сообщении от Среда 30 сентября 2009 23:29:32 Max Rabkin написал: On Wed, Sep 30, 2009 at 9:24 PM, Alberto G. Corona agocor...@gmail.com wrote: Haskell: mathematics beyond numerical calculus I'd imagine most physicists know a fair bit of mathematics beyond numerical calculus; what they might not know much about is *computation* beyond numerical calculus. Could you elaborate this. As physicist I don't quite get it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
On Wed, 30 Sep 2009 21:24:11 +0200, you wrote: I?m a physicist, so I think they would be attracted by something like Haskell: high level physics modelling at Fortran speeds Haskell: mathematics beyond numerical calculus And, easier to make use of multi-core machines than threaded Fortran. I suppose one could have a Haskell parser convert Fortran to monadal code. Then, a parser to convert, hopefully, most of the resulting code to pure code. -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
Khudyakov Alexey wrote: В сообщении от Среда 30 сентября 2009 23:08:02 вы написали: Yep, sure did. I just hit `reply' assuming haskell-cafe was in the reply-to. I do that more often than not it seems. Going back to the OP, what area of physics, and how on earth are you going to convert years of fortran users to haskell? I mean, in particle physics (were I came from) it seems as though only recently have they moved from fortran to C++ (note: C was skipped). There are things written in python (like Athena) but, well..., they are unreliable crap (I do like python though). In fact, when I was in undergraduate, not 4 years ago, a PhD student was writing his big QCD project in fortran from the ground up. I'm not even familiar enough with fortran to attempt such a thing (I would have used C). Case in point, I think there are some areas of physics that exist as a communal project (i.e. experimental particle physics) and because of this, you are limited to the tools and data used by your peers (Athena, Geant4, etc...). It is really hard to introduce anything new. So I guess my advice would be to avoid Haskell as a 'replacement' for anything to a physicist (including mathematica -- which I never liked myself). They will immediately ignore you. Approach it as a new tool, and focus on what it can do that software-x can't. I'm particle physicist too. And sometimes I think that it would be better if they stay with fortran. Object-disoriented which is done in C++ scares me. Random segfaults in ROOT, or even worse segfault loops... It's possible to use safety as argument for haskell. Type safety, no segfaults. As for existing code there are two strategies. First is to dump all code into Geneva lake. There are environmental concerns of course. And it's difficult to throw away tested code. Second one - do not touch it and use haskell for small isolated tasks. It's easier to do this in smaller experiments. I use haskell to process experimental data with reasonable success. Code is much cleaner and easier to understand that C++ code. In fact I just reworded your statement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Root has pissed me off more times than I can remember. I've also done lots of Geant4 work (my thesis work actually), and that is a steaming pile of OO confusion. Geant4 is getting close to 40MB of source, and it is still nothing more than a library of interfaces to interfaces to to the CLHEP C++ library. It is OOP gone mad. Not to mention that if anyone asks for a feature implemented, it gets implemented. There are features in the geant4 library that I'm sure even geant4 developers don't know about. Functional programming should be the to-go tool in physics, but it isn't. Somewhere down the road, someone thought OOP was the messiah and worthy of a fortran replacement. I fail to see the logic in this. If anything I would start by scolding the physicists in the room on their programming practices. Then introduce Haskell as you wish. If I were to give a talk about programming to physicists, the first words out of my mouth would probably be I'm embarrassed by you all. Ok I'm done, I think you all get my point. A comp-sci minor should be required for every physics major. -jack ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
I am *not* a physicist, but I imagine many physicists know at least something of functional analysis, algebra, Lie algebras, etc. However, when physicists write programs (this is my inference from the widespread use of Fortran and the computational assignments given to undergraduate students) they are almost exclusively numerical: very often evaluating some integrals or integrating a system of differential equations. Although Haskell can do these things, it's not a place where Haskell really shines (compared to symbolic computation). Since I'm not a physicist, I can't give a good example, but think more of the things Mathematica is good for, rather than Fortran or Matlab. My impression is that Haskell's advantage over Mathematica is in its generality: Mathematica is great if it has a builtin function to do what you want, but it's not a very pleasant programming language. HTH, Max On Wed, Sep 30, 2009 at 9:39 PM, Khudyakov Alexey alexey.sklad...@gmail.com wrote: В сообщении от Среда 30 сентября 2009 23:29:32 Max Rabkin написал: On Wed, Sep 30, 2009 at 9:24 PM, Alberto G. Corona agocor...@gmail.com wrote: Haskell: mathematics beyond numerical calculus I'd imagine most physicists know a fair bit of mathematics beyond numerical calculus; what they might not know much about is *computation* beyond numerical calculus. Could you elaborate this. As physicist I don't quite get it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
Good ones! Specially the second, since I will show a real example where I used Haskell to model a boson condensate. Thanks for the suggestions. Edgar On Wed, 30/Sep/2009 at 10:52 -0700, Ted Nyman wrote: Some ideas of highly variable quality: Getting Functional with Physics Bosons, Fermions, and Monads? Haskell for Physicists Purer Programming for Physicists Use Haskell for Physics, and Say 'C'-You-Later - ted On Wed, Sep 30, 2009 at 10:42 AM, ed...@ymonad.com wrote: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar ___ 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] Haskell for Physicists
On Wed, 30/Sep/2009 at 22:27 +0200, Max Rabkin wrote: I am *not* a physicist, but I imagine many physicists know at least something of functional analysis, algebra, Lie algebras, etc. However, when physicists write programs (this is my inference from the widespread use of Fortran and the computational assignments given to undergraduate students) they are almost exclusively numerical: very often evaluating some integrals or integrating a system of differential equations. Although Haskell can do these things, it's not a place where Haskell really shines (compared to symbolic computation). Well, if you want to write all the code in Haskell, maybe this is true (some parts an imperative code still is the most efficient, but nothing that you can't do in C and use in Haskell via FFI). But in my case, Haskell really shined using as an interface to GSL/Lapack via the wonderful hmatrix lib. Since I'm not a physicist, I can't give a good example, but think more of the things Mathematica is good for, rather than Fortran or Matlab. My impression is that Haskell's advantage over Mathematica is in its generality: Mathematica is great if it has a builtin function to do what you want, but it's not a very pleasant programming language. And speed is other advantage! The code that I wrote to solve a problem in bose condensation is dozen times fastest that the Mathematica equivalent, and much more clean and simple to expand or modify. Edgar HTH, Max On Wed, Sep 30, 2009 at 9:39 PM, Khudyakov Alexey alexey.sklad...@gmail.com wrote: В сообщении от Среда 30 сентября 2009 23:29:32 Max Rabkin написал: On Wed, Sep 30, 2009 at 9:24 PM, Alberto G. Corona agocor...@gmail.com wrote: Haskell: mathematics beyond numerical calculus I'd imagine most physicists know a fair bit of mathematics beyond numerical calculus; what they might not know much about is *computation* beyond numerical calculus. Could you elaborate this. As physicist I don't quite get it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
On Wed, 30/Sep/2009 at 22:21 +0400, Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. I won't focus in a specific area, just a general exposition and maybe, if I have time, I'm going to show an example which I used to solve a problem in a simple quantum mechanical model of a bose condensate. Most of the public will be formed by mathematical physicists. Edgar Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) ___ 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] Haskell for Physicists
On Wed, 30/Sep/2009 at 22:21 +0400, Khudyakov Alexey wrote: В сообщении от 30 сентября 2009 21:42:57 ed...@ymonad.com написал: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) What area of physics? They all face somewhat different problems from computation. Could you publish your slides from seminar (if any) and even if they are in Spanish (nothing is impossible for man with a dictionary) Of course, no problem (and yes, will be in portuguese ;) Edgar ___ 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] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Wed, Sep 30, 2009 at 8:32 AM, Andrew Coppin andrewcop...@btinternet.comwrote: (Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. We shall see...) You could use the same argument against, say, utensils. Being natural or intuitive is a 100% irrelevant metric for any tool. What matters is if it's effective or not. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] suggestion for hslogger
On Wed, 2009-09-30 at 08:36 -0500, John Goerzen wrote: If you want to send me a patch that makes it an option (not mandatory), I would be happy to apply it. When reviewing it do consider the new Unicode IO library. http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/ One option is to do nothing and just wait. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] suggestion for hslogger
Duncan Coutts wrote: On Wed, 2009-09-30 at 08:36 -0500, John Goerzen wrote: If you want to send me a patch that makes it an option (not mandatory), I would be happy to apply it. When reviewing it do consider the new Unicode IO library. http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/ One option is to do nothing and just wait. That is probably the best. -- John Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] river crossing puzzle
pat browne-2 wrote: Hi, Does anyone know where there are any Haskell implementations of the the River Crossing puzzle (AKA Farmer/Fox/Goose/Grain). Here is an implementation of the similar problem with good explanation (see PDF): http://web.engr.oregonstate.edu/~erwig/zurg/ It isn't quite Farmer/Fox but it is rather generic. -- View this message in context: http://www.nabble.com/river-crossing-puzzle-tp25651350p25690342.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type class question
Ben schrieb: dear haskellers -- i'm trying this question again, in haskell-cafe. i got some responses in haskell-beginners but am looking for more guidance. also, i understand this functionality is encapsulated in the Workflow module in hackage, but i'd like to understand this myself. this email is an (il)literate haskell file. suppose i have class of computations a - State s b. for concreteness, let's say i'm writing a library of on-line statistical summary functions, like I used functions of such type to describe causal processes. In order make them an arrow, I had to hide the state s using existential quantification. http://code.haskell.org/synthesizer/core/src-4/Synthesizer/Causal/Process.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] error on --++ bla bla bla
Hi, I got an error if one of lines reads --++ bla bla bla where I tried to comment, but -- ++ bla bla bla (notice the space after --) is OK. Do you think this revealed a tiny bug in the GHC compiler (I am using Windows Haskell Platform 2009.2.0.2)? Thanks, Hong ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error on --++ bla bla bla
I don't think it's a bug. --++ is a valid operator, whereas -- introduces a comment. In GHCI: Prelude let (--++) = (+) in 5 --++ 6 11 Hope this helps, Dan On Wed, Sep 30, 2009 at 7:52 PM, Hong Yang hyang...@gmail.com wrote: Hi, I got an error if one of lines reads --++ bla bla bla where I tried to comment, but -- ++ bla bla bla (notice the space after --) is OK. Do you think this revealed a tiny bug in the GHC compiler (I am using Windows Haskell Platform 2009.2.0.2)? Thanks, Hong ___ 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] convert a list of booleans into Word*
On Wed, 30 Sep 2009, Jochem Berndsen wrote: Bulat Ziganshin wrote: Hello Paul, Wednesday, September 30, 2009, 1:18:03 PM, you wrote: I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. sum . zipWith (*) (map (2^) [0..]) I'd turn this into sum . zipWith (*) (iterate (2*) 1) , but it's probably not very important. Or sum . zipWith (*) (iterate (flip shiftL 1) 1) . map fromEnum in order to make the bitset nature more explicit. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error on --++ bla bla bla
On Thu, Oct 1, 2009 at 12:52 AM, Hong Yang hyang...@gmail.com wrote: Hi, I got an error if one of lines reads --++ bla bla bla where I tried to comment, but -- ++ bla bla bla (notice the space after --) is OK. Do you think this revealed a tiny bug in the GHC compiler (I am using Windows Haskell Platform 2009.2.0.2)? Line comments start with -- , not just --. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On 2009-09-29 13:28 -0700 (Tue), Don Stewart wrote: I'd welcome input on how to best present all this -- the Haskell Platform gives us a chance to package up the docs in a better format for consumption. Part of the issue is that the Haskell libraries are so different in many ways that there's a (relatively) large amount of background required to be able to understand how things normally fit together. One of the best resources I've seen for this is Brent Yorgey's article The Typeclassopedia. How we get from particular bits of design in random libraries back to an understanding of why they were designed that way that would be informed by something like the above, I'm not sure. Including a design document with libraries that explains how and why they were designed that way might be a big help. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On 2009-09-30 13:45 -0300 (Wed), namekuseijin wrote: The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already: [examples deleted] No, I disagree with your particular examples; they're bog-standard Haskell that don't use any syntatic sugar (. and $ are just library functions), and I find them perfectly fine to read. Note that nothing in there is inconsistent or interpreted in any sort of exceptional way, unlike many things that look like that in Perl. It does take time to learn to read that sort of stuff, but once you've got it, simplifying this sort of thing would only make it harder to read, because it would be more verbose without saying anything more. Haskell's concision is one of its most important strengths. (Incidently, a good exercise for learning to understand stuff like that might be to go thorugh it and convert it to use parens instead of $, full application instead of ., and so on.) cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
There is a significant difference between: * A $ function without a type system * A statically checked $ function * A $ keyword without static checking Curt Sampson wrote: On 2009-09-30 13:45 -0300 (Wed), namekuseijin wrote: The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already: [examples deleted] No, I disagree with your particular examples; they're bog-standard Haskell that don't use any syntatic sugar (. and $ are just library functions), and I find them perfectly fine to read. Note that nothing in there is inconsistent or interpreted in any sort of exceptional way, unlike many things that look like that in Perl. It does take time to learn to read that sort of stuff, but once you've got it, simplifying this sort of thing would only make it harder to read, because it would be more verbose without saying anything more. Haskell's concision is one of its most important strengths. (Incidently, a good exercise for learning to understand stuff like that might be to go thorugh it and convert it to use parens instead of $, full application instead of ., and so on.) cjs -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Portability of libraries.
On 2009-09-30 07:16 -0600 (Wed), John A. De Goes wrote: The cross-platform features have been extremely important to the success of Java Moreover, the importance of cross-platform libraries on the Java platform is evinced by the fact that developers of major native libraries _always_ make their libraries cross-platform Hm. It is interesting to note, then, that Ruby, which has worse cross-platform support than Haskell[1], is yet still quite popular, orders of magnitude more so than Haskell. So while that portability may have helped Java, it doesn't seem required to become popular. [1] I've ported a fair amount of both Ruby and Haskell code from Unix to Windows, so I think I have a pretty good handle on the the relative portability of both. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: combinatorial search with running bound
I wish I had enough of your code to type-check my code and perhaps even
try running it!
Michael Mossey m...@alumni.caltech.edu wrote in article
3942.75.50.175.130.1253997756.squir...@mail.alumni.caltech.edu in
gmane.comp.lang.haskell.cafe:
-- This is state used in the state monad.
data SearchState = SearchState { -- running maximum:
ssMaximum :: Int
-- remember the full list of right boxes
-- so we can initiate a new outer loop
, ssRights :: [Box]
}
boxesSep2 :: [Box] - [Box] - Int
boxesSep2 lefts rights =
let ls = sortBy ((flip compare) `on` rightExtent) lefts
rs = sortBy ((flip compare) `on` leftExtent) rights
in fst $ runState (boxesSep2' ls rs) (SearchState minBound rs)
First, ssRights never changes, so it should not be kept inside the state
monad. Also, ssMaximum is already stored in the state, so boxesSep2'
need not return it.
data SearchState = SearchState { ssMaximum :: Int }
boxesSep2 :: [Box] - [Box] - Int
boxesSep2 lefts rights =
let ls = sortBy ((flip compare) `on` rightExtent) lefts
rs = sortBy ((flip compare) `on` leftExtent) rights
in ssMaximum (execState (boxesSep2' ls rs) (SearchState minBound))
boxesSep2' :: [Box] - [Box] - State SearchState Int
-- Termination of algorithm:
boxesSep2' [] _ = gets ssMaximum
-- Initiate a new inner loop:
boxesSep2' (l:ls) [] = do
rights - gets ssRights
boxesSep' ls rights
Instead, boxesSep2' can simply iterate through the left boxes.
boxesSep2' :: [Box] - [Box] - State SearchState ()
boxesSep2' ls rs = mapM_ (flip boxesSep2'' rs) ls
-- Common case:
boxesSep2' lss@(l:ls) (r:rs) = do
-- In this way of writing the code, we distinguish between the
-- left/right separation which is the sum of the extents, and the
-- question of whether there is vertical overlap.
let v = isVerticalOverlap l r
sep = lrSeparation l r
ss - get
let max = ssMaximum ss
if sep = max
then boxesSep' ls (ssRights ss) --Here we prune (initiate new inner
loop)
else do
-- Update max is needed:
when v (put ss { ssMaximum = sep })
boxesSep' lss rs
The inner loop through the right boxes doesn't need to maintain the full
list of right boxes, because that list is already part of the closure
(flip boxesSep2'' rs) above.
boxesSep2'' :: Box - [Box] - State SearchState ()
boxesSep2'' l [] = return ()
boxesSep2'' l (r:rs) = do
let v = isVerticalOverlap l r
sep = lrSeparation l r
max - gets ssMaximum
when (sep max) (do
when v (put (SearchState { ssMaximum = sep }))
boxesSep2'' l rs)
Personally, I think it's slightly clearer to drop the SearchState
constructor and use foldl and explicit state-passing instead of mapM_
and the state monad. But that's less crucial than removing the full
rights list from the state. (In the state, the full rights list is a
defunctionalized delimited continuation.)
When you ask for a pair of boxes, How closely can they be brought together
without intersection? that provides a lower bound on the question How
closely can the groups be brought together? (I.e. for that pair of boxes,
bring them any closer and they intersect, so it is a lower bound.) The
maximum of all these lower bounds in the minimum needed separation.
I think I see.
Cheers!
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Computer Science is no more about computers
than astronomy is about telescopes.
-Edsger Dijkstra
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On 2009-10-01 11:42 +1000 (Thu), Tony Morris wrote: There is a significant difference between: * A $ function without a type system * A statically checked $ function * A $ keyword without static checking Sure, but I'm not not clear on the point you're trying to make, since we all know which one of these that Haskell uses. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Wed, Sep 30, 2009 at 03:43:12PM +0100, Andrew Coppin wrote: Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say something about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. Very few of them will answer that the sum of an empty list is defined to be zero, and the sum of a non-empty list is defined to be the first number plus the sum of the list tail. Maybe they would say that you have to go adding each number to the others, i.e. they're thinking with a fold. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error on --++ bla bla bla
But in my program, I did not define --++. Also in GHCI, Prelude :t (--++) No in scope: '--++' Prelude :t (+) (+) :: (Num a) = a - a - a Thanks, Hong On Wed, Sep 30, 2009 at 7:05 PM, Daniel Peebles pumpkin...@gmail.comwrote: I don't think it's a bug. --++ is a valid operator, whereas -- introduces a comment. In GHCI: Prelude let (--++) = (+) in 5 --++ 6 11 Hope this helps, Dan On Wed, Sep 30, 2009 at 7:52 PM, Hong Yang hyang...@gmail.com wrote: Hi, I got an error if one of lines reads --++ bla bla bla where I tried to comment, but -- ++ bla bla bla (notice the space after --) is OK. Do you think this revealed a tiny bug in the GHC compiler (I am using Windows Haskell Platform 2009.2.0.2)? Thanks, Hong ___ 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
