[Haskell-cafe] [Fwd: Termination Competition 2009 live on the web!]
Hi all, This contest should be of interest to Haskellers. There is an FP Category in which termination of Haskell programs is automatically checked. The current state can be observed by following the corresponding View Results link from the page http://termcomp.uibk.ac.at/termcomp/competition/categoryList.seam?competitionId=101722cid=51 Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ---BeginMessage--- Termination Competition 2009 December 16-20 The annual termination competition has started today. The progress of the competition can be seen live on the web at http://termcomp.uibk.ac.at/termcomp/competition/categoryList.seam?competitionId=101722cid=51 As usual, the most powerful termination provers compete against each other in this competition. The competition has several categories for termination analysis of different programming paradigms, including * Term Rewriting * Java Bytecode * Haskell * Prolog * etc. Moreover, there are competitions on * certified termination analysis and on * automated complexity analysis. More information can be found at http://termcomp.uibk.ac.at/status/rules.html ---End Message--- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On 18 Dec 2009, at 06:39, Richard O'Keefe wrote: My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. Wouldn't it be something like Editor (Preset (Color Scatter)) in Haskell? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Thu, Dec 17, 2009 at 6:58 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: (Why do people call baStudly syle camel? Is there somewhere in the world a species of camel with three or four humps, like XmlNodeSansChildren?) As near as I can tell (from googling) you're the one calling it baStudlyCaps :) See this mail were you seem to coin the phrase and mention african gender prefix (what is that?): http://www.mail-archive.com/disc...@ppig.org/msg01199.html It seems that if you want this name baStudlyCaps to catch on it should be added to the list of alternate names for camel case: http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms Cheers, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pattern matching, and bugs
Hello,
I was advised respectfully to post my query here.
Please, read the whole letter before you do anything, because I tried to
construct the problem step by step.
Also keep in mind, that the problem I query here is more general, and
similar cases occur elsewhere, not just in this particular example I present
below.
*Intro story* ( Skip if you are in a hurry )
I'm participating in several open-source server development projects, most
of them are written in C, and some of them have C++ code hidden here and
there.
These programs, are developed by many, and by many ways, and so, more often
than not it is very hard to determine the 'real cause of bugs'.
This almost always leads to 'bugfixes' which 'treat the crash'. Sometimes
they are a few lines of extra checks, like IFs.
Sometimes they are complex, and even surprisingly clever hacks.
Thus understanding the 'code' of them is challenging, but the end result is
a pile of ... hacks fixing bugs fixing hacks fixing bug, which also were put
there to fix yet another bugs.
+
When I started to learn functional programming, I was told, that
the correctness of a functional program can be proved a lot more easily, in
fact in a straight mathematical way.
+
*My concern*
is about predictable failure of sw written in Haskell.
To illustrate it let's see a Haskell pattern matching example:
Let's say I have defined some states my object could be in, and I did in a
switch in some C-like language:
switch ( x )
{
Case 0:
Unchecked
Case 1:
Checked
Case 2:
Unknown
}
And in Haskell pattern matching:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
Let's say, these are clearly defined states of some objects.
Then let's say something unexpected happens: x gets something else than 0 1
2.
Now we have a problem, which is most generally fixed in these ways:
C-like:
switch ( x )
{
Case 0:
Unchecked
Case 1:
Checked
Case 2:
Unknown
Default:
Nothing
}
Haskell like:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
switch x = Nothing
These general ways really avoid this particular crash, but does something
real bad to the code in my opinion.
Below are some cases x can go wrong:
*1. The bad data we got as 'x', could have came from an another part of our
very program, which is the REAL CAUSE of the crash, but we successfully hide
it.*
*
Which makes it harder to fix later, and thus eventually means the death of
the software product. Eventually someone has to rewrite it.
Which is economically bad for the company, since rewriting implies increased
costs.
2. The bad data we got as 'x', could also could have come form a real
word object,
we have underestimated, or which changed in the meantime.
3. This 'x' could have been corrupted over a network, or by 'mingling' or by
other faulty software or something.
Point 1:
If we allow ourself such general bugfixes, we eventually kill the ability of
the project to 'evolve'.
Point 2:
Programmers eventually take up such 'arguably bad' habits, thus making
harder to find such bugs.
Thus it would be wiser to tell my people to never write Default cases, and
such general pattern matching cases.
*
Which leads to the very reason I wrote to you:
I want to propose this for Haskell prime:
I would like to have a way for Haskell, not to crash, when my coders write
pattern matching without the above mentioned general case.
Like having the compiler auto-include those general cases for us,
but when those cases got hit, then* instead of crashing*, it *should **report
some error* on *stdout *or *stderr*.
(It would be even nicer if it cold have been traced.)
This is very much like warning suppression, just that it's crash
suppression, with the need of a report message of course.
*I would like to hear your opinion on this.*
I also think, that there are many similar cases in haskell, where not
crashing, just error reporting would be way more beneficial.
In my case for server software, where network corrupted data,
( and data which has been 'tampered with' by some 'good guy' who think he's
robin hood if he can 'hack' the server )
is an every day reality.
Thanks for your time reading my 'storm'.
Greets,
Andrew
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching, and bugs
András Mocsáry wrote:
*My concern*
is about predictable failure of sw written in Haskell.
To illustrate it let's see a Haskell pattern matching example:
And in Haskell pattern matching:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
Let's say, these are clearly defined states of some objects.
Then let's say something unexpected happens: x gets something else than 0 1
2.
Now we have a problem, which is most generally fixed in these ways:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
switch x = Nothing
These general ways really avoid this particular crash, but does something
real bad to the code in my opinion.
Agreed. The real cause of the problem is that the programmer didn't
prove that x is in {1,2,3} when calling switch.
Below are some cases x can go wrong:
*1. The bad data we got as 'x', could have came from an another part of our
very program, which is the REAL CAUSE of the crash, but we successfully hide
it.*
*
Which makes it harder to fix later, and thus eventually means the death of
the software product. Eventually someone has to rewrite it.
Which is economically bad for the company, since rewriting implies increased
costs.
Yes.
2. The bad data we got as 'x', could also could have come form a real
word object,
we have underestimated, or which changed in the meantime.
You should not assume that your input is correct in fault-tolerant programs.
3. This 'x' could have been corrupted over a network, or by 'mingling' or by
other faulty software or something.
Unlikely. There is nothing you can do about this, though.
Point 1:
If we allow ourself such general bugfixes, we eventually kill the ability of
the project to 'evolve'.
Point 2:
Programmers eventually take up such 'arguably bad' habits, thus making
harder to find such bugs.
Thus it would be wiser to tell my people to never write Default cases, and
such general pattern matching cases.
It is a better idea to use the type system to prevent this kind of bugs.
In this particular case, it's better to try to have a datatype like
data X = One | Two | Three
*
Which leads to the very reason I wrote to you:
I want to propose this for Haskell prime:
I would like to have a way for Haskell, not to crash, when my coders write
pattern matching without the above mentioned general case.
Like having the compiler auto-include those general cases for us,
but when those cases got hit, then* instead of crashing*, it *should **report
some error* on *stdout *or *stderr*.
(It would be even nicer if it cold have been traced.)
And, how would it continue?
Suppose that we have the function
head :: [a] - a
head (x:_) = x
What would you propose that would happen if I call head [] ? Print an
error on stderr, say, but what should it return? Surely it cannot make
an value of type a out of thin air?
Nowadays, head [] crashes the program, and you get an error message to
standard error.
This is very much like warning suppression, just that it's crash
suppression, with the need of a report message of course.
This is already possible with exception handling.
*I would like to hear your opinion on this.*
I don't think it can be implemented in a sane way, or that it's a good
idea to suppress this silently, when an explicit solution already exists.
I also think, that there are many similar cases in haskell, where not
crashing, just error reporting would be way more beneficial.
In my case for server software, where network corrupted data,
( and data which has been 'tampered with' by some 'good guy' who think he's
robin hood if he can 'hack' the server )
is an every day reality.
You should validate your data in any case. You may even turn a DoS
attack into a real security problem with your solution.
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] Pattern matching, and bugs
I would like to have a way for Haskell, not to crash, when my coders write pattern matching without the above mentioned general case. Like having the compiler auto-include those general cases for us, but when those cases got hit, then instead of crashing, it should report some error on stdout or stderr. (It would be even nicer if it cold have been traced.) You should not wait for Haskell prime. What you are asking is already in libraries: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Exception.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: lhs2tex-1.15 (was: lhs2tex, Haskell Platform and cygwin)
Also, it would be nice if there were an lhs2tex version which worked out-of-the-box with base=4, since hacking the Makefile for that seems, er, sub-optimal? I've just uploaded 1.15 which should work better on Windows. Sorry, I should have released a new version a long time ago. Please let me know if this works. Cheers, Andres -- Andres Loeh, Universiteit Utrecht mailto:and...@cs.uu.nl mailto:m...@andres-loeh.de http://www.andres-loeh.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] naming naming conventions (was: Re: Allowing hyphens in identifiers)
I used to refer to them as dromedaryCase and BactrianCase, but the names never caught on :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching, and bugs
András Mocsáry amo...@gmail.com writes:
Now we have a problem, which is most generally fixed in these ways:
C-like:
switch ( x )
{
Case 0:
Unchecked
Case 1:
Checked
Case 2:
Unknown
Default:
Nothing
}
This is not a fix, this is a workaround for a design bug, namely that
x is of a type that allows meaningless data.
Haskell like:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
switch x = Nothing
These general ways really avoid this particular crash, but does something
real bad to the code in my opinion.
Yes. The type of the parameter should be designed so that it only allows
the three legal values. Using an integer value when there are only
three real options is bad design.
*1. The bad data we got as 'x', could have came from an another part of our
very program, which is the REAL CAUSE of the crash, but we successfully hide
it.*
2. The bad data we got as 'x', could also could have come form a real
word object, we have underestimated, or which changed in the meantime.
I think these two are the same - in case 2, it is the parser that
should produce an error. If it may fail, there's a plethora of
solutions, for instance, wrapping the result in a Maybe. This will force
users of the data to take failure into account.
3. This 'x' could have been corrupted over a network, or by 'mingling' or by
other faulty software or something.
I'm not really sure how a Haskell program would react to memory errors
or similar. Badly, I expect.
I would like to have a way for Haskell, not to crash, when my coders write
pattern matching without the above mentioned general case.
I think this just encourages sloppy programming, and as has been pointed
out, you can catch the exception if you think you can deal with it
reasonably.
GHC warns you if you do incomplete pattern matching, and I think it's a
good idea to adhere to the warnings.
In my case for server software, where network corrupted data,
( and data which has been 'tampered with' by some 'good guy' who think he's
robin hood if he can 'hack' the server ) is an every day reality.
I like the Erlang approach: let it (the subsystem) crash, catch the
exception, report it, and restart.
-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] Double free-ing (was: Reading from a process)
Hi! On Fri, Dec 18, 2009 at 8:16 AM, Jason Dusek jason.du...@gmail.com wrote: Concatenating two `ByteString`s is O(n)? This is what it is written here: http://haskell.org/ghc/docs/latest/html/libraries/bytestring-0.9.1.5/Data-ByteString.html#v%3Aappend Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Pattern matching, and bugs
Hello, Date: Fri, 18 Dec 2009 13:04:47 +0100 From: Andr?s Mocs?ry amo...@gmail.com switch 1 = Unchecked switch 2 = Checked switch 3 = Unknown switch x = Nothing These general ways really avoid this particular crash, but does something real bad to the code in my opinion. ...snip... Which leads to the very reason I wrote to you: I want to propose this for Haskell prime: I would like to have a way for Haskell, not to crash, when my coders write pattern matching without the above mentioned general case. I will first make a recommendation, then some comments on your proposal. My recommendation is this: if you know that a function should only be called with certain values, you should create a data type that has *only* those values, like: data ForSwitch = One | Two | Three then your switch function is switch :: ForSwitch - String and now it can be guaranteed *at compile-time* that switch will never be called with an incorrect argument, because only arguments are available in the ForSwitch type and they're all valid. It's now impossible for another part of the program to generate invalid data. It either generates a ForSwitch, which is guaranteed to be valid, or it doesn't, in which case the code won't typecheck. Note that if you really just want to wrap Int's, you can use a newtype and a smart constructor, which if written correctly gives you the same guarantees but is in my mind less convenient. Now, as for a general response to your proposal, I'm not sure that what you're requesting is possible, and I'm quite certain it would be more trouble than it's worth. Like having the compiler auto-include those general cases for us, but when those cases got hit, then* instead of crashing*, it *should **report some error* on *stdout *or *stderr*. (It would be even nicer if it cold have been traced.) What should the program do after reporting an error? Because of Haskell's non-strict evaluation, a function is only evaluated when your program *needs the result*. The compiler can't infer a meaningful value for an arbitrary type, and the only value that can be in every type is undefined. So now the program needs a result of some type (String in your example) and gets an undefined, and then immediately crashes with an Exception - undefined error. As for network-corrupted data, the solution is the same. Make a type that reflects *only* the values you want. Then it's the responsibility of the serializer/deserializer to ensure that you have a correct value, using explicit error handling (Maybe or Either come to mind). Then you know that all data in your system is valid, and you only need to worry about invalid data at borders, where the problem is much easier to address. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Pattern matching, and bugs
On Fri, Dec 18, 2009 at 02:13:02PM +, John Lato wrote: So now the program needs a result of some type (String in your example) and gets an undefined, and then immediately crashes with an Exception - undefined error. I think this is the second time this is said in this thread, but please don't as it may confuse the OP. undefineds, including those generated by missing cases, do *not* crash the program. They also do not *immediately* close the program. They are propagated as exceptions are, however most of the time we write programs without explicitly catching them. So the proper wording would be that the undefineds propagate through the functions and whenever they reach the top function (i.e. main), they are caught by the runtime system, which prints the String associated with the undefined and exits the proccess with an error code. I should note also that *pure* code *can't* catch those undefineds. If they could, then Nasty Things Would Happen(TM) and we don't want that. However IO code may catch them without any problem using Control.Exception's functions. HTH and clarifies things, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Fri, 18 Dec 2009 16:39:21 +1300, you wrote: My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. I wouldn't notice the difference between Preset and Present in either case. And in the latter example, my eyes would actually be drawn away from Preset/Present and towards Colour, noticing that it is spelled incorrectly... Count me in the prefers hyphens camp, by the way. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
Patai Gergely schrieb: I have a function for mixing sounds at different (relative) start times. I feel that it does not get maximum speed in GHC, but is still ready for realtime application. http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/Synthesizer-Storable-Cut.html#v%3Aarrange And how can you mix that with changing frequencies (effectively resampling on the fly)? I would do resampling (with some of the Interpolation routines) and mixing in two steps, that is I would prepare (lazy) storable vectors with the resampled sounds and mix them. Since Haskell is lazy, this is still somehow on the fly, although one could still wish to eliminate the interim storable vectors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Pattern matching, and bugs
On Fri, 2009-12-18 at 13:04 +0100, András Mocsáry wrote:
Hello,
I was advised respectfully to post my query here.
Please, read the whole letter before you do anything, because I tried
to construct the problem step by step.
Also keep in mind, that the problem I query here is more general, and
similar cases occur elsewhere, not just in this particular example I
present below.
Intro story ( Skip if you are in a hurry )
I'm participating in several open-source server development projects,
most of them are written in C, and some of them have C++ code hidden
here and there.
These programs, are developed by many, and by many ways, and so, more
often than not it is very hard to determine the 'real cause of bugs'.
This almost always leads to 'bugfixes' which 'treat the crash'.
Sometimes they are a few lines of extra checks, like IFs.
Sometimes they are complex, and even surprisingly clever hacks.
Thus understanding the 'code' of them is challenging, but the end
result is a pile of ... hacks fixing bugs fixing hacks fixing bug,
which also were put there to fix yet another bugs.
+
When I started to learn functional programming, I was told, that
the correctness of a functional program can be proved a lot more
easily, in fact in a straight mathematical way.
+
My concern
is about predictable failure of sw written in Haskell.
To illustrate it let's see a Haskell pattern matching example:
Let's say I have defined some states my object could be in, and I did
in a switch in some C-like language:
switch ( x )
{
Case 0:
Unchecked
Case 1:
Checked
Case 2:
Unknown
}
And in Haskell pattern matching:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
Let's say, these are clearly defined states of some objects.
Then let's say something unexpected happens: x gets something else
than 0 1 2.
Now we have a problem, which is most generally fixed in these ways:
C-like:
switch ( x )
{
Case 0:
Unchecked
Case 1:
Checked
Case 2:
Unknown
Default:
Nothing
}
Haskell like:
switch 1 = Unchecked
switch 2 = Checked
switch 3 = Unknown
switch x = Nothing
These general ways really avoid this particular crash, but does
something real bad to the code in my opinion.
Below are some cases x can go wrong:
1. The bad data we got as 'x', could have came from an another part of
our very program, which is the REAL CAUSE of the crash, but we
successfully hide it.
Yes. If program have bug let it be a bug that crash (then you know there
is a bug). However in Haskell you have _|_ (read bottom) which indicate
that there is an error or exception (returning _|_ is related to
throwing excaptions in other languaged).
Which makes it harder to fix later, and thus eventually means the
death of the software product. Eventually someone has to rewrite it.
Which is economically bad for the company, since rewriting implies
increased costs.
The first problem is that here int is used as enumeration like if it was
assembler. In C the enum is also strongly connected to it's binary
representation. But well - it is HL assembler and in some uses it is
justified.
data State = Unchecked | Checked | Unknown
switch Unchecked = Unchecked
switch Checked = Checked
switch Unknown = Unknown
Here compiler knows all possible inputs (Unchecked/Checked/Unknown) and
hence it can see nothing else is possible. If there is case not covered
it will produce warning.
Other module cannot run (switch 4) because 4 is not State. If there is
problem with user input you will know it in code which parse user input
(i.e. one which will convert 3 into Unknwn).
2. The bad data we got as 'x', could also could have come form a real
word object, we have underestimated, or which changed in the meantime.
3. This 'x' could have been corrupted over a network, or by 'mingling'
or by other faulty software or something.
Point 1:
If we allow ourself such general bugfixes, we eventually kill the
ability of the project to 'evolve'.
Point 2:
Programmers eventually take up such 'arguably bad' habits, thus making
harder to find such bugs.
Thus it would be wiser to tell my people to never write Default cases,
and such general pattern matching cases.
Which leads to the very reason I wrote to you:
I want to propose this for Haskell prime:
I would like to have a way for Haskell, not to crash, when my coders
write pattern matching without the above mentioned general case.
Like having the compiler auto-include those general cases for us,
but when those cases got hit, then instead of crashing,
it should report some error on stdout or stderr.
(It would be even nicer if it cold have been traced.)
This is very much like warning
[Haskell-cafe] Largest types in SYB
I was looking for a simple generic technique targeting and transforming the largest terms of a particular type. For example, with Expr and Val declared as: data Expr = Val Val | Add Expr Expr | Sub Expr Expr deriving (Show, Eq, Typeable, Data) data Val = Var String | Struct [Expr] deriving (Show, Eq, Typeable, Data) and a test Expr e, e = Sub (Val $ Var A) (Add (Val $ Var X1) (Val $ Struct [Add (Val $ Var Y1) (Val $ Var Y2)])) I wanted to replace only the inner Add expression Add (Val $ Var Y1) (Val $ Var Y2) because its parent is not of the same type as itself (it's a list), using a function such as chopAdd: chopAdd (Add _ _) = Val $ Var AddChop chopAdd e = e But using everywhere from Scrap Your BoilerPlate (SYB): everywhere (mkT repAdd) e I'd get: Sub (Val (Var A)) (Val (Var AddChop)) while I was hoping for: Sub (Val (Var A)) (Add (Val (Var X1)) (Val (Struct [Val (Var AddChop)]))) The Haskell.org SYB wiki presents listifyWholeLists. This is relevant, though it applies queries rather than transformations. It uses a function called synthesize, which I was ultimately unable to properly reference, or apply to the problem at hand. So here is my solution: everywhereBar :: GenericQ Bool - GenericT - GenericT everywhereBar q f x | q x = (gmapT (everywhereBar (typeEq x) f) x) | otherwise = f (gmapT (everywhereBar (typeEq x) f) x) where typeEq p c = typeOf p == typeOf c It's like SYB's everywhereBut, except 1. The consequence of q x being True is only to remove the application of f to the parent; not to stop traversal. 2. q is not constant. Instead it is the partial application of a local function, typeEq. An application looks like: everywhereBar (const False) (mkT repAdd) e with (const False) the user is choosing the outcome of the very first q x in everywhereBar. I'm enjoying using SYB, and had hoped to use only functions from the package, but couldn't find a way; and this does the job for now. I've also seen that there are many other approaches to generic programming than SYB (even for AST transformations in particular) but I wanted to understand SYB first. I'm interested to know if anyone has a more elegant SYB solution. And here's the monadic version: everywhereBarM :: Monad m = GenericQ Bool - GenericM m - GenericM m everywhereBarM q f x | q x = gmapM (everywhereBarM (typeEq x) f) x | otherwise = do x' - gmapM (everywhereBarM (typeEq x) f) x f x' where typeEq p c = typeOf p == typeOf c Cheers, Paul The University of Glasgow, charity number SC004401 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
I would do resampling (with some of the Interpolation routines) and mixing in two steps, that is I would prepare (lazy) storable vectors with the resampled sounds and mix them. Since Haskell is lazy, this is still somehow on the fly, although one could still wish to eliminate the interim storable vectors. You could use stream fusion, although you will need to adapt that for the interpolation, but it should work. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: parallel and distributed haskell?
Please note: We have a version of GUM in which PVM has been replaced by direct network communication. However, this project has been idle since the appearance of GHC-6, and I have not been able to get a binary of the parallel version (which is based on GHC-5) to compile itself. Murray Gross Brooklyn College, City University of New York On Thu, 17 Dec 2009, Simon Marlow wrote: On 16/12/2009 19:21, Scott A. Waterman wrote: It looks like there was a recent hackathon focusing on implementing distributed haskell. http://hackage.haskell.org/trac/ghc/wiki/HackPar I feel there is quite a bit of latent interest in the subject here, but relatively little active development (compared to erlang, clojure, etc.) Can anyone involved give a quick overview (or pointers to one)? It would be good to hear what directions people are taking, and why, and where it's going. The main directions are: GUM, which was one of the first parallel implementations of Haskell many years ago [1]. The programming API is the same as GHC has: par/pseq and strategies (indeed this API was invented in the context of GUM, we just re-used it in GHC). GUM uses PVM message passing to implement a distributed heap, and can run on clusters of machines or a multicore, or a combination of the two. GUM has in the past been integrated with GHC, but has sufferred from a lack of development effort so has rotted in recent years. Efforts are now underway to get it working with GHC HEAD again. Eden [2] also uses PVM, but does not have a distributed heap. It's implementation is much simpler, and the API is rather more explicit than par/seq and strategies. Eden has been tracking GHC more closely than GUM, but it's still a research project and there's little effort available to make releases. Neither of these are really what you'd call Distributed Haskell, they are implementations of parallel variants of Haskell running on distributed hardware. There was a Distributed Haskell project, but it is not active at the moment [3]. Cheers, Simon [1] GUM: a portable parallel implementation of Haskell http://www.macs.hw.ac.uk/~dsg/gph/papers/abstracts/gum.html [2] Parallel functional programming in Eden Journal of Functional Programming (2005), 15 [3] http://www.macs.hw.ac.uk/~dsg/gdh/ ___ 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] Cabal
On Thu, 2009-12-17 at 18:08 +, Nils Anders Danielsson wrote: I was hoping that I could make use of this feature now: $ cabal --version cabal-install version 0.7.5 using version 1.8.0.2 of the Cabal library However, when I try to use it I get the following error: So there's two bugs. One is that cabal-install doesn't know about this new stuff. Stephen Blackheath has a patch for this but it's not yet been reviewed and integrated. The other is that the feature currently fails with ghc-6.12 but we didn't notice in time to fix it before the release. Is this feature supposed to work now, or has it been postponed? It works with 6.10 if you're not using cabal-install. Both issues will be addressed in future releases in the new stable series. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Double free-ing
Hi! On Fri, Dec 18, 2009 at 8:29 AM, Ketil Malde ke...@malde.org wrote: Lazy ByteStrings should be able to append with O(1). (Or use strict BS hGetNonBlocking, and Lazy ByteString fromChunks.) Oh, true. Thanks! But ... lazy ByteString's hGetNonBlocking is probably not lazy? Could it be? It has to read at that moment whatever it can? But appending is really better. Why are lazy ByteStrings not default? Thanks again. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
I would do resampling (with some of the Interpolation routines) and mixing in two steps, that is I would prepare (lazy) storable vectors with the resampled sounds and mix them. And is that straightforward considering the peculiarities of tracked music? After all, frequency can change between ticks thanks to portamento effects, and samples can loop or end in the middle of a tick. Do I have to trim and pad the samples manually to be able to describe these transformations? -- http://www.fastmail.fm - The way an email service should be ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] sizeOf on a type
Hey everyone, I would like to write a routine like nextPtr :: Storable a = Ptr a - Ptr a nextPtr = (`plusPtr` sizeOf (undefined :: a)) which increments a pointer by the correct amount, but GHC complains that the type variable a is ambiguous. I can see what's going on: it can't tell that the a I am writing there is the same a that's in the type specification, but is there any way that I can make it identify a with the a in the specification for nextPtr? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] getPtrSize works, but is annoying
Ugh, I figured out how to write code to do what I wanted, but it seems like an ugly solution: getPtrSize :: Ptr a - Int getPtrSize = getFrom dummy where getFrom :: a - Ptr a - Int getFrom dummy _ = sizeOf dummy Any thoughts on a less ugly solution, or is this really the best that I can do? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sizeOf on a type
I would like to write a routine like nextPtr :: Storable a = Ptr a - Ptr a nextPtr = (`plusPtr` sizeOf (undefined :: a)) How about: getA :: Ptr a - a getA _ = undefined nextPtr ptr = (`plusPtr` sizeOf (getA ptr)) ptr -Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sizeOf on a type
I can see what's going on: it can't tell that the a I am writing there is the same a that's in the type specification, but is there any way that I can make it identify a with the a in the specification for nextPtr? Lexically scoped type variables: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getPtrSize works, but is annoying
On Fri, Dec 18, 2009 at 12:20 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: Ugh, I figured out how to write code to do what I wanted, but it seems like an ugly solution: getPtrSize :: Ptr a - Int getPtrSize = getFrom dummy where getFrom :: a - Ptr a - Int getFrom dummy _ = sizeOf dummy With -XScopedTypeVariables: getPtrSize :: forall a. Ptr a - Int getPtrSize p = sizeOf (undefined :: a) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sizeOf on a type
Hi, I would like to write a routine like nextPtr :: Storable a = Ptr a - Ptr a nextPtr = (`plusPtr` sizeOf (undefined :: a)) which increments a pointer by the correct amount, but GHC complains that the type variable a is ambiguous. Maybe Foreign.Marshal.Array.advancePtr is what you really need in this case. Gergely -- http://www.fastmail.fm - The professional email service ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sizeOf on a type
Yay, advancePtr is exactly what I needed! I totally missed that one in the docs. Also thanks to those of you who pointed me to the scoped type variables feature, since I had figured that a feature liked that had to exist but I just didn't know where to look for it. You guys rock! Cheers, Greg On Dec 18, 2009, at 12:09 PM, Patai Gergely wrote: Hi, I would like to write a routine like nextPtr :: Storable a = Ptr a - Ptr a nextPtr = (`plusPtr` sizeOf (undefined :: a)) which increments a pointer by the correct amount, but GHC complains that the type variable a is ambiguous. Maybe Foreign.Marshal.Array.advancePtr is what you really need in this case. Gergely -- http://www.fastmail.fm - The professional email service ___ 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] Double free-ing
Hi! On Fri, Dec 18, 2009 at 6:54 PM, Mitar mmi...@gmail.com wrote: On Fri, Dec 18, 2009 at 8:29 AM, Ketil Malde ke...@malde.org wrote: Lazy ByteStrings should be able to append with O(1). (Or use strict BS hGetNonBlocking, and Lazy ByteString fromChunks.) Oh, true. Thanks! But ... lazy ByteString's hGetNonBlocking is probably not lazy? Could it be? It has to read at that moment whatever it can? But appending is really better. Why are lazy ByteStrings not default? Tried it and it really works great! Thanks to all. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with cabal install zlib
Hi, When I run cabal install zlib or cabal upgrade zlib I get the following error: Resolving dependencies... Configuring zlib-0.5.2.0... Preprocessing library zlib-0.5.2.0... Only one output file may be specified cabal: Error: some packages failed to install: zlib-0.5.2.0 failed during the building phase. The exception was: exit: ExitFailure 1 I have zlib-0.5.0.0 installed now. The OS is Snow Leopard. I couldn't find anything related to this error, that's why I'm asking community's opinion. Best, -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
