Re: [Haskell-cafe] Announcing OneTuple-0.1.0
G'day all. I asked: But more to the point: Can it send email? Quoting John Dorsey [EMAIL PROTECTED]: Can you give an example of a use case? I don't need one. It's not maximally flexible until it can send email. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
G'day all. Quoting Lennart Augustsson [EMAIL PROTECTED]: But I called it One. That's a _terrible_ name. One, surely is (), just as Zero is Void. While I'm at it, I really don't like the lexical syntax of comments. Someone should fix that. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announcing OneTuple-0.1.0
On Thu, 2 Oct 2008 14:46:32 -0700, Jason Dusek [EMAIL PROTECTED] wrote: John Dorsey [EMAIL PROTECTED] wrote: Now you can: * Solve any of the software problems that cannot be solved without the singleton tuple ! What would those be? I'm still trying to figure out how a singelton tuple is really distinct from a plain value. Actually, part of my original motivation for suggesting a singleton tuple had to do with in using it as a tool for modeling complete partial orders (a.k.a. cpos) (see http://en.wikipedia.org/wiki/Complete_partial_order), such as those that appear in a lattice (see http://en.wikipedia.org/wiki/Lattice_(order)). A lattice is a partially ordered set in which every pair of elements has a unique supremum (see http://en.wikipedia.org/wiki/Supremum) and infimum (see http://en.wikipedia.org/wiki/Infimum). When I was in college, one of the courses that I took was on domain theory (see http://en.wikipedia.org/wiki/Domain_theory), where we used complete partial orders to model (partial) results of a computation, where elements higher in the order extended the information of the elements below them in a consistent way. _|_ (bottom) represented an undefined result, and, if present in a cpo, was a least element for that cpo. In a lattice, unlike in a list, since every pair of elements has a unique supremum and infimum, it is possible to have an ordering where a pair of elements X1, Y1 Z1 for some element Z1, and X1, Y2 Z2 for some other elements Y2, Z2, but neither Z1 Z2 nor Z2 Z1. This kind of ordering cannot be represented in a list in which every element is a number. My idea was that it may be possible to use nesting of tuples to represent this kind of ordering if we, say, allow nesting an element in a tuple to distinguish that element from the same element not nested in a tuple, and to define elements or tuples X to have a lower ordering than either the same elements or tuples X with more nesting (e.g., X (X)), or less than elements containing either those elements or containing tuples containing those elements (e.g., X (X) and X ((X), (Y)) (in the above-mentioned example) (() as _|_ being a unique least element). E.g. (in the above-mentioned example), let: X1 = (X) Y1 = (Y) Y2 = ((Y)) Then, in order to define Z1 and Z2, since X1 Z1, Y1 Z1 i.e., (X) Z1, (Y) Z1 and X1 Z1, Y2 Z2 i.e., (X) Z1, ((Y)) Z2 just define: Z1 = ((X), (Y)) Z2 = ((X), ((Y))) Then: X1 Z1 i.e., (X) ((X), (Y)) and Y1 Z1 i.e., (Y) ((X), (Y)) and X1 Z2 i.e., (X) ((X), ((Y))) Y2 Z2 i.e., ((Y)) ((X), ((Y))) but not: Z1 Z2 i.e., not: ((X), (Y)) ((X), ((Y))) (since they cannot be compared) and not: Z2 Z1 i.e., not: ((X), ((Y))) ((X), (Y)) (again, since they cannot be compared) Forgive me if this makes little sense, but I just thought that being able to define, say, (X) = X1 ((X)) = X2 (((X))) = X3 .. (..(^nX)..)^n = Xn would be useful in this kind of ordering. Then, X is not the same as (X), because X = X0, (X) = X1, ..., (..(^nX)..)^n = Xn, and in the context of this example, X (X) ... (..(^nX)..)^n. Having a singleton tuple might then allow the representation of lattices using tuples, in which _|_ (bottom) = () is a unique least element, and for each element X in the lattice, X (X) and X each tuple containing X. Without a singleton tuple, we cannot define X (X), because then X = (X). Does this sound plausible? -- Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about constraints
On Thu, Oct 2, 2008 at 7:51 AM, jean-christophe mincke
[EMAIL PROTECTED] wrote:
Hello,
Thank you for your comments.
Would not it be feasible to add constraints at type definition, something
like, in a somewhat free style syntax
data String2 = String2 (s::String) with length s = 5
and with a polymorphic type
data List5 a= List5 (l::[a]) with length l = 5
Well, yeah, it is possible that to a language. However, it's a
question of how far you take it. What do you want that to do? Is it
a runtime check on the constructor? Is it a compile-time guarantee?
If it's runtime, how lazy is it -- i.e. when does it check? If it's
compile-time, how do you enforce it?
Basically it dumps the contents of pandora's box all over the design
space, so it's easier to leave it out and just let module abstraction
take care of the hard questions. There are definitely ways to
simulate it:
You can simulate the runtime checks as follows:
subtype :: (a - Bool) - (a - b) - a - b
subtype p f x = if p x then f x else error Subtype constraint failed
string2 :: String - String2
string2 = subtype (\s - length s 5) String2
-- And don't expose String2 from the module, so string2 is the only
way to make them
But to give an example of why this is not a straightforward thing to
answer, here's a different way which might also be correct, depending
on what you want:
string2 :: String - String2
string2 s = partial 5 s
where
partial 0 _ = error Subtype constraint failed
partial n [] = []
partial n (x:xs) = x:partial (n-1) xs
Which lazily checks the constraint; i.e. only errors if a value is
demanded beyond the index 5 and exists.
Implementing Compile-time checks is typically much harder, and demands
a bit more cleverness, since the way you do it is different for each
type of constraint you have. For this example, you could create an
algebra of lengthed lists:
import Prelude hiding (++)
-- Type level numbers; Z = 0, S n = n + 1.
data Z
data S n
-- Lists of length exactly n
data Listn n a where
Nil :: Listn Z a
Cons :: a - Listn n a - Listn (S n) a
-- Type-level addition of numbers
type family Plus m n :: *
type instance Plus Z n = n
type instance Plus (S m) n = S (Plus m n)
-- Typed append; appends the lists, adds the lengths.
-- The compiler verifies that the implementation actually does this!
(++) :: Listn m a - Listn n a - Listn (Plus m n) a
Nil ++ ys = ys
Cons x xs ++ ys = Cons x (xs ++ ys)
-- Type-level less than or equal; represents the type of *proofs* that m = n.
data m := n where
LeN :: n := n
LeS :: m := n - m := S n
-- A List5 a is a function which takes a proof than n = 5, and
returns a Listn n a
type List5 a = forall n. n := S (S (S (S (S Z - Listn n a
So that was a bit of work, wasn't it? But this solution is quite
expressive; the compiler will not even compile your code if you try to
construct a list with more than 5 elements. Furthermore, you can
actually write most things you'd expect to because of Haskell's great
GADT typechecking features :-)
The downside is that you have to redefine all the standard list
operations, because, well, they have different types now.
The above is approaching what dependently typed languages do. My
favorite is Coq (a lot of haskell folks like Agda 2), and in it you
can express directly the constraint you want without all this type
boilerplate:
Definition List5 a := { l : List a | length l = 5 }.
But internally it is doing something very similar to the above Haskell
program. This also has the property that it is impossible to write a
well-typed program that constructs a List5 of length 5. In
addition, you can use all the standard list functions, however you
have to prove what they do to the constraint:
Theorem append_length : forall m n a (xs ys : List a), (length xs =
m) - (length ys = n) - (length (xs ++ ys) = m+n).
(* prove prove prove *)
Qed.
And then you can use that theorem to prove that the parts of your
program that use List5 are well-typed.
Whew, so now that we're done with that, in summary, it depends on your
situation how you want to do it, and there's really no easy answer.
I hope you got something out of seeing these techniques.
Adding notation like that you suggest is a challenge for the language,
since a runtime constraint changes the strictness properties of the
object, and a compile-time constraint written that concisely actually
does require full dependent types. Best to leave it to the users.
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell participating in big science like CERN Hadrian...
Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
Jason Dagit [EMAIL PROTECTED] wrote: Jason Dusek [EMAIL PROTECTED] wrote: John Dorsey [EMAIL PROTECTED] wrote: Now you can: * Solve any of the software problems that cannot be solved without the singleton tuple ! What would those be? I'm still trying to figure out how a singelton tuple is really distinct from a plain value. Careful when making (or not making) this distinction. It could lead to infinite types such as, a = OneTuple a. Perhaps I am lacking in imagination, but I still can't see the value of one tuples. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Hmm, what license to use?
Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. Thanks Neil == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is Haskell-Cafe down?
About two hours ago, I sent two follow-ups to the Announcing OneTuple-0.1.0 thread on the Haskell-Cafe mailing list, neither of which has appeared in either my newsreader or my Inbox, even though they have both appeared on the Web archive; viz.: [Haskell-cafe] Re: Announcing OneTuple-0.1.0 http://www.haskell.org/pipermail/haskell-cafe/2008-October/048633.html [Haskell-cafe] Re: Announcing OneTuple-0.1.0 http://www.haskell.org/pipermail/haskell-cafe/2008-October/048636.html Is Haskell-Cafe down? -- Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Announcing OneTuple-0.1.0
Quoting Lennart Augustsson [EMAIL PROTECTED]: But I called it One. I did a similar one for Yhc, and I think I called it Box. My guess was that boxing/unboxing wasn't an overloaded enough term :-) Thanks Neil == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial
On Wed, Oct 1, 2008 at 7:38 PM, Don Stewart [EMAIL PROTECTED] wrote: Awesome, native packages now available, http://aur.archlinux.org/packages.php?ID=20422 Thanks Don! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Kind-agnostic type classes
I'm trying to encode a well-known, informally-specified type system in Haskell. What causes problems for me is that type classes force types to be of a specific kind. The system I'm targeting however assumes that its equivalent of type classes are kind-agnositic. For instance, I've got class Assignable a where assign :: a - a - IO () class Swappable a where swap :: a - a - IO () class CopyConstructible a where copy :: a - IO a class (Assignable a, CopyConstructible a) = ContainerType a class (Swappable c, Assignable c, CopyConstructible c) = Container c where size :: (Num i, ContainerType t) = c t - IO i I suppose I could address this with creating aliases for the relevant classes, but I wonder if there is a better workaround. I see that the ML module system has a similar restriction on type sharing. Is there a fundamental reasons behind this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mysql (hsql-mysql-1.7) on Linux with GHC 8.3 - cabal issues
John, Thank you for your reply. I benchmarked HDBC.ODBC with MySQL and it is indeed working well. So whatever slow results I used to get were due to that particular setup. It looks that HDBC will suit my needs as well. Thanks, --A What's more, HDBC has a stronger and more versatile API than HSQL, which permits even more speed improvements. Features such as precompiled queries can be huge for many apps, as can referencing result columns as an ordered list instead of an association list or map. Personally, I spent the time to write the Sqlite3, ODBC, and PostgreSQL bindings for HDBC owing to existing needs. I have no need for a MySQL binding because I avoid MySQL wherever possible, and where not possible, use ODBC. That said, the API is designed to make development of database backends easy. FFI also is quite nice. It should not be a significant task for an interested party to write a MySQL backend. I think it has not happened yet because the ODBC backend is fully functional for MySQL. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
Let me pick one example. Let's make a class that can convert between tuples and lists. Of course there are restriction when this works, but it can still be useful. class TupleList t l | t - l where tupleToList :: t - l listToTuple :: l - t instance TupleList () [a] where tupleToList () = [] listToTuple [] = () -- XXX This doesn't work, and is just wrong. --instance TupleList (a) [a] where --tupleToList (a) = [a] --listToTuple [a] = (a) instance TupleList (a,a) [a] where tupleToList (a1,a2) = [a1, a2] listToTuple [a1,a2] = (a1, a2) instance TupleList (a,a,a) [a] where tupleToList (a1,a2,a3) = [a1, a2, a3] listToTuple [a1,a2,a3] = (a1, a2, a3) On Fri, Oct 3, 2008 at 8:17 AM, Jason Dusek [EMAIL PROTECTED] wrote: Jason Dagit [EMAIL PROTECTED] wrote: Perhaps I am lacking in imagination, but I still can't see the value of one tuples. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell-Cafe down?
2008/10/3 Benjamin L. Russell [EMAIL PROTECTED]: About two hours ago, I sent two follow-ups to the Announcing OneTuple-0.1.0 thread on the Haskell-Cafe mailing list, neither of which has appeared in either my newsreader or my Inbox, even though they have both appeared on the Web archive; viz.: [Haskell-cafe] Re: Announcing OneTuple-0.1.0 http://www.haskell.org/pipermail/haskell-cafe/2008-October/048633.html [Haskell-cafe] Re: Announcing OneTuple-0.1.0 http://www.haskell.org/pipermail/haskell-cafe/2008-October/048636.html Is Haskell-Cafe down? I've received both, if it is what you ask... Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hmm, what license to use?
Magnus Therning wrote:
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow [EMAIL PROTECTED] wrote:
[..]
Dynamic linking doesn't solve all the problems, we still have the problem
that GHC does a lot of cross-module inlining, regardless of whether dynamic
linking is used. However, I really would like to have a way to have
complete control over what is exposed across a package boundary. We need
this not just for licensing reasons, but also for making a dynamic library
with a fixed ABI, so it can be upgraded later.
I have a really hard time following this. Are you seriously saying
that GHC is inlining code from modules _and_ link dynamically at the
same time. That seems like a remarkably strange thing to do, or maybe
I'm just missing something.
That's exactly what would happen, if we shipped dynamic linking support
with GHC as it stands. It's just a linking mechanism, an alternative to
static linking, and has no impact on the amount or nature of
inter-module optimisation that GHC does.
My understanding from another thread on here was that dynamic linking
isn't working reliably, not even on Windows, where it once was
supported. It has never worked on any other platform.
The fundamental mechanisms are working on {x86, x86-64, PPC, PPC64} /
{Linux, OS X, Windows} and possibly other OSs. However right now you
need a few small patches to the source tree to get it to build. Most of
the unresolved issues are around how to construct binary installs, and
how executables will find their libraries when the run (e.g. if you
install GHC privately in your home directory).
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Kind-agnostic type classes
On Fri, 2008-10-03 at 12:22 +0200, Florian Weimer wrote: I'm trying to encode a well-known, informally-specified type system in Haskell. What causes problems for me is that type classes force types to be of a specific kind. The system I'm targeting however assumes that its equivalent of type classes are kind-agnositic. For instance, I've got class Assignable a where assign :: a - a - IO () class Swappable a where swap :: a - a - IO () class CopyConstructible a where copy :: a - IO a class (Assignable a, CopyConstructible a) = ContainerType a class (Swappable c, Assignable c, CopyConstructible c) = Container c where size :: (Num i, ContainerType t) = c t - IO i instane Container Maybe where... What does copy :: Maybe - IO Maybe mean? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Kind-agnostic type classes
On Fri, Oct 3, 2008 at 4:22 AM, Florian Weimer [EMAIL PROTECTED] wrote:
I'm trying to encode a well-known, informally-specified type system in
Haskell. What causes problems for me is that type classes force types
to be of a specific kind. The system I'm targeting however assumes that
its equivalent of type classes are kind-agnositic.
There is no choice of kinds, they are forced by the methods (since the
kind of an actual argument is * by definition). But see below.
For instance, I've got
class Assignable a where
assign :: a - a - IO ()
class Swappable a where
swap :: a - a - IO ()
class CopyConstructible a where
copy :: a - IO a
class (Assignable a, CopyConstructible a) = ContainerType a
class (Swappable c, Assignable c, CopyConstructible c) = Container c where
size :: (Num i, ContainerType t) = c t - IO i
Which is illegal because the three above classes force c to be kind *,
but you're using it here as kind * - *.
What you want is not this informal kind-agnostic classes so much as
quantification in constraints, I presume. This, if it were supported,
would solve your problem.
class (forall t. Swappable (c t), forall t. Assignable (c t), forall
t. CopyConstructible (c t)) = Contanter c where ...
Incidentally, you *can* do this if you go to a dictionary passing
style (because then you are providing the proofs, rather than asking
the compiler to infer them, which is probably undecidable (what isn't
;-)).
data Assignable a = Assignable { assign :: a - a - IO () }
data Swappable a = Swappable { swap :: a - a - IO () }
data CopyConstructible a = CopyConstructible { copy :: a - IO a }
data ContainerType a = ContainerType (Assignable a) (CopyConstructor a)
data Container c t = Container {
containerAssignable :: forall t. ContainerType t - Assignable (c t),
containerSwappable :: forall t. ContainerType t - Swappable (c t),
containerCopyConstructible :: forall t. ContainerType t -
CopyConstructible (c t),
size :: forall i. (Num i) = ContainerType t - c t - IO i }
And then to make an instance of Container (construct an object of
it), you need to provide a proof of eg. forall t. ContainerType t -
Assignable (c t).
For what it's worth, this is a well-known but very infrequently used
technique. Try to come up with something simpler that accomplishes
the big picture you have in mind (spend more time thinking about
the problem and less about the solution you think you want).
Also, OO-esque modeling like this in Haskell almost always leads to
overcomplexity, pain, and desire for yet more missing features. A
more functional solution will serve you well (it takes time to learn
how to come up with functional solutions).
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Kind-agnostic type classes
* Derek Elkins: On Fri, 2008-10-03 at 12:22 +0200, Florian Weimer wrote: I'm trying to encode a well-known, informally-specified type system in Haskell. What causes problems for me is that type classes force types to be of a specific kind. The system I'm targeting however assumes that its equivalent of type classes are kind-agnositic. For instance, I've got class Assignable a where assign :: a - a - IO () class Swappable a where swap :: a - a - IO () class CopyConstructible a where copy :: a - IO a class (Assignable a, CopyConstructible a) = ContainerType a class (Swappable c, Assignable c, CopyConstructible c) = Container c where size :: (Num i, ContainerType t) = c t - IO i instane Container Maybe where... What does copy :: Maybe - IO Maybe mean? Maybe is not an instance of CopyConstructible, so this shouldn't compile. On the other hand, for IORef a, copy = (= newIORef) . readIORef and for mutable arrays, copy = mapArray id (if I'm not mistaken). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
...gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place... Sounds like a good application for lazy evaluation! (Actually, they may have to read over it all to make sure they can throw it away...) On Fri, Oct 3, 2008 at 6:47 AM, Dougal Stanton [EMAIL PROTECTED]wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
On Fri, Oct 3, 2008 at 07:47, Dougal Stanton [EMAIL PROTECTED]wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) Man, that was almost as good as the Large Hardon Colliderhttp://largehardoncollider.com/ !!! I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). There is a lot of data filtering, looking for the right trigger event... -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
Dougal Stanton wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) That's close: http://www.motivatedphotos.com/?id=3343d=2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hmm, what license to use?
On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow [EMAIL PROTECTED] wrote: Magnus Therning wrote: On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow [EMAIL PROTECTED] wrote: [..] Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later. I have a really hard time following this. Are you seriously saying that GHC is inlining code from modules _and_ link dynamically at the same time. That seems like a remarkably strange thing to do, or maybe I'm just missing something. That's exactly what would happen, if we shipped dynamic linking support with GHC as it stands. It's just a linking mechanism, an alternative to static linking, and has no impact on the amount or nature of inter-module optimisation that GHC does. Ah, now I understand. The object for GHC would be to reduce the system-wide use of memory rather than substitutability of DLLs then, right? Why would it be interesting to have sharable objects without substitutability? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hmm, what license to use?
Magnus Therning wrote: On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow [EMAIL PROTECTED] wrote: Magnus Therning wrote: On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow [EMAIL PROTECTED] wrote: [..] Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later. I have a really hard time following this. Are you seriously saying that GHC is inlining code from modules _and_ link dynamically at the same time. That seems like a remarkably strange thing to do, or maybe I'm just missing something. That's exactly what would happen, if we shipped dynamic linking support with GHC as it stands. It's just a linking mechanism, an alternative to static linking, and has no impact on the amount or nature of inter-module optimisation that GHC does. Ah, now I understand. The object for GHC would be to reduce the system-wide use of memory rather than substitutability of DLLs then, right? Why would it be interesting to have sharable objects without substitutability? It'll make our binary distributions a lot smaller for one thing. Also, the on-disk size of binaries will be a lot smaller - this is something you notice if you run a GHC test suite, for example. Also, the GHCi binary contains the base package, but loads up another complete copy when it starts up. And if you load up the GHC package inside GHCi, then you have two complete copies of GHC in memory. Dynamic linking fixes all this. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex and Flex
On Oct 3, 2008, at 09:24 , Manlio Perillo wrote: Manlio Perillo ha scritto: However I have noted that there are some difference in the syntax between Alex and Flex? What is the rationale? By the way, here is the list of differences between Alex and Flex I have found, for people interested: 3) Alex does not support [_a-z0-9-] that must be rewritten as [_a-z0-9\-] The only *reliable* way to write that cset is to put the '-' as the first item. Likewise for ']' (and if you must match both, [-]...]). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Kind-agnostic type classes
* Luke Palmer: For instance, I've got class Assignable a where assign :: a - a - IO () class Swappable a where swap :: a - a - IO () class CopyConstructible a where copy :: a - IO a class (Assignable a, CopyConstructible a) = ContainerType a class (Swappable c, Assignable c, CopyConstructible c) = Container c where size :: (Num i, ContainerType t) = c t - IO i Which is illegal because the three above classes force c to be kind *, but you're using it here as kind * - *. What you want is not this informal kind-agnostic classes so much as quantification in constraints, I presume. This, if it were supported, would solve your problem. class (forall t. Swappable (c t), forall t. Assignable (c t), forall t. CopyConstructible (c t)) = Contanter c where ... In the meantime, I figured out that in ML, it suffices to make the Container type c non-polymorphic (although the syntactic overhead is rather problematic). Trying to the same in Haskell, I learnt something about functional dependencies. I actually ended up with: class (Assignable c, CopyConstructible c, Swappable c, ContainerType t, Num s) = Container c s t | c - s, c - t where size :: c - IO Int empty ::c - IO Bool empty c = do sz - size c return (sz == 0) (In fact, I stumbled across A Comparative Study of Language Support for Generic Programming by Garcia et al., which contains a very helpful Haskell example with functional dependencies and multi-parameter type classes.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
Am Freitag, 3. Oktober 2008 13:36 schrieben Sie: […] What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I've never heard about problems with macros etc. but I think that the LGPL is problematic if you use templates. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
Lennart Augustsson [EMAIL PROTECTED] wrote: Let me pick one example. Let's make a class that can convert between tuples and lists. -- XXX This doesn't work, and is just wrong. -- instance TupleList (a) [a] where --tupleToList (a) = [a] --listToTuple [a] = (a) It's not clear to me what is so wrong about it. If the 1-ary tuple is the 1-ary product, it makes sense. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
On Fri, Oct 3, 2008 at 4:36 AM, minh thu [EMAIL PROTECTED] wrote: 2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I don't know what happens on platforms that don't have shared libraries with LGPL. If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled. Dave Thanks, Thu ___ 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] Hmm, what license to use?
On Fri, 2008-10-03 at 10:08 -0700, David Leimbach wrote: On Fri, Oct 3, 2008 at 4:36 AM, minh thu [EMAIL PROTECTED] wrote: 2008/10/3 Mitchell, Neil [EMAIL PROTECTED]: Hi You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Example 1: foo x | test `isPrefixOf` xs = ... | otherwise = ... If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value. Example 2: (a :: Int) + b If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application. One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude. What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? I don't know what happens on platforms that don't have shared libraries with LGPL. If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled. What I've always heard is that in that case you have to distribute object files. This would work for Haskell, except that changing the distributed library is still liable to invalidate the object files, due to cross-module inlining. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Tillmann Rendel wrote: Seriously, what are you talking about? The haddock page for Control.Applicative hoogle links to begins with This module describes a structure intermediate between a functor and a monad: it provides pure expressions and sequencing, but no binding. (Technically, a strong lax monoidal functor.) For more details, see Applicative Programming with Effects, by Conor McBride and Ross Paterson, online at http://www.soi.city.ac.uk/~ross/papers/Applicative.html. This interface was introduced for parsers by Niklas Röjemo, because it admits more sharing than the monadic interface. The names here are mostly based on recent parsing work by Doaitse Swierstra. This class is also useful with instances of the Traversable class. I agree that this is hard to understand, but it's more then just strong lax monoidal functor, isn't it? More importantly, there is a reference to a wonderful and easy to read paper. (easy in the easy for Haskell programmers sense, not in the easy for the authors, and maybe the inventors of Haskell sense). Just give it a try. Just in case you missed the link for some reason, here is it again: http://www.soi.city.ac.uk/~ross/papers/Applicative.html You must have a radically different idea of easy to read paper than I have. ;-) Anyway, after multiple hours of staring at this paper and watching intricate type signatures swim before my eyes, I simply ended up being highly confused. (I especially like the way that what's described in the paper doesn't quite match what's in the actual Haskell standard libraries...) After many hours of thinking about this, I eventually began to vaguely comprehend what it's saying. (I suspect the problem is that, rather like monads, the concepts it's attempting to explain are just so extremely abstract that it's hard to develop an intuitive notion about them.) So... something that's applicative is sort-of like a monad, but where the next action cannot vary depending on the result of some prior action? Is that about the size of it? (If so, why didn't you just *say* so?) But on the other hand, that would seem to imply that every monad is trivially applicative, yet studying the libraries this is not the case. Indeed several of the libraries seem to go out of their way to implement duplicate functionallity for monad and applicative. (Hence the sea of identical and nearly identical type sigantures for functions with totally different names that had me confused for so long.) If you think in terms of containers, then c x is a container of x values. Then, the type signature sequence :: c1 (c2 x) - c2 (c1 x) kind-of makes sense. (Obviously the two containers are constrained to particular classes.) So that's traversable, is it? Again, we have sequence and sequenceA, indicating that monads and applicatives aren't actually the same somehow. Also, before you can put anything into Traversable, it has to be in Functor (no hardship there) and Foldable. Foldable seems simplish, except that it refers to some odd monoid class that looks suspiciously like MonadPlus but isn't... wuh? OK, maybe I should just stop attempting to comprehend this stuff and write the code... At this point learning about applicative and traversable isn't actually solving my problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Kind-agnostic type classes
On Fri, Oct 3, 2008 at 9:49 AM, Luke Palmer [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 4:22 AM, Florian Weimer [EMAIL PROTECTED] wrote: I'm trying to encode a well-known, informally-specified type system in Haskell. What causes problems for me is that type classes force types to be of a specific kind. The system I'm targeting however assumes that its equivalent of type classes are kind-agnositic. There is no choice of kinds, they are forced by the methods (since the kind of an actual argument is * by definition). But see below. For instance, I've got class Assignable a where assign :: a - a - IO () class Swappable a where swap :: a - a - IO () class CopyConstructible a where copy :: a - IO a class (Assignable a, CopyConstructible a) = ContainerType a class (Swappable c, Assignable c, CopyConstructible c) = Container c where size :: (Num i, ContainerType t) = c t - IO i Which is illegal because the three above classes force c to be kind *, but you're using it here as kind * - *. What you want is not this informal kind-agnostic classes so much as quantification in constraints, I presume. This, if it were supported, would solve your problem. class (forall t. Swappable (c t), forall t. Assignable (c t), forall t. CopyConstructible (c t)) = Contanter c where ... Incidentally, you *can* do this if you go to a dictionary passing style (because then you are providing the proofs, rather than asking the compiler to infer them, which is probably undecidable (what isn't ;-)). You don't necessarily need explicit dictionaries. For example, I've occasionally wanted to have a constraint (forall a. Show a = Show (f a)). One fairly simple way to do this to declare a new class. class Show1 f where showsPrec1 :: (Show a) = Int - f a - ShowS instance Show1 [] where showsPrec1 = showsPrec The same technique is used in Data.Typeable. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex and Flex
Manlio Perillo ha scritto: Manlio Perillo ha scritto: Hi. I'm starting to write a CSS parser with Alex and Happy. The grammar is defined here: http://www.w3.org/TR/CSS21/grammar.html However I have noted that there are some difference in the syntax between Alex and Flex? What is the rationale? One more thing. Here: http://www.haskell.org/alex/doc/html/alex-files.html it seems that there is an error with macrodef := @smac '=' set | @rmac '=' regexp it should be macrodef := $smac '=' set | @rmac '=' regexp Ok, this is not an error, sorry. By the way, here is the list of differences between Alex and Flex I have found, for people interested: [...] Another problem. In this rule: @comment= \/\*[^\*]*\*+([^\/\*][^\*]*\*+)*\/ [^\*] means all characters except '*', but Alex seems to not include the new line character. So a comment like /* A comment */ generates a lexical error. Is this true? Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
David Menendez wrote: On Thu, Oct 2, 2008 at 3:40 PM, Andrew Coppin [EMAIL PROTECTED] wrote: David Menendez wrote: You could try using an exception monad transformer here I thought I already was? No, a monad transformer is a type constructor that takes a monad as an argument and produces another monad. So, (ErrorT ErrorType) is a monad transformer, and (ErrorT ErrorType m) is a monad, for any monad m. Right, OK. If you look at the type you were using, you see that it breaks down into (Either ErrorType) (ResultSet State), where Either ErrorType :: * - * and ResultSet State :: *. Thus, the monad is Either ErrorType. The fact that ResultSet is also a monad isn't enough to give you an equivalent to (=), without one of the functions below. OK, that makes sense. Uh... what's Applicative? (I had a look at Control.Applicative, but it just tells me that it's a strong lax monoidal functor. Which isn't very helpful, obviously.) Applicative is a class of functors that are between Functor and Monad in terms of capabilities. Instead of (=), they have an operation (*) :: f (a - b) - f a - f b, which generalizes Control.Monad.ap. (As an aside, Control.Monad.ap is not a function I've ever heard of. It seems simple enough, but what an unfortunate name...!) The nice thing about Applicative functors is that they compose. With monads, you can't make (Comp m1 m2) a monad without a function analogous to inner, outer, or swap. So I see. I'm still not convinced that Applicative helps me in any way though... From your code examples, it isn't clear to me that applicative functors are powerful enough, but I can't really say without knowing what you're trying to do. The whole list-style multiple inputs/multiple outputs trip, basically. The fact that the functions you gave take a state as an argument and return a state suggests that things could be refactored further. If you look at run_or, you'll see that this is _not_ a simple state monad, as in that function I run two actions starting from _the same_ initial state - something which, AFAIK, is impossible (or at least very awkward) with a state monad. Really, it's a function that takes a state and generates a new state, but it may also happen to generate *multiple* new states. It also consumes a Foo or two in the process. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: But on the other hand, that would seem to imply that every monad is trivially applicative, yet studying the libraries this is not the case. Indeed several of the libraries seem to go out of their way to implement duplicate functionallity for monad and applicative. (Hence the sea of identical and nearly identical type sigantures for functions with totally different names that had me confused for so long.) Actually, it is the case. It is technically possible to write: instance Monad m = Applicative m where pure = return (*) = ap We don't include the above definition because it elimimates all possibility of specialization. The reason for the separation of the two for many functions is so that types which are instances of only one of the two can still take advantage of the functionality. Foldable seems simplish, except that it refers to some odd monoid class that looks suspiciously like MonadPlus but isn't... wuh? A Monoid is simply anything that has an identity element (mempty) and an associative binary operation (mappend). It is not necessary for a complete instance of Foldable. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Jeltsch wrote: Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie: Wolfgang Jeltsch wrote: You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Maybe one of the GHC developers could comment on this? Perhaps the best approach currently for creating dynamically loadable modules in Haskell is to expose the interface via FFI, then? (I suspect that in most cases, you'd want to provide that as an option, but of course not as the only means of interfacing with the library, for those who don't want to make the DLL-vs-optimizations tradeoff.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5lq/7M8hyUobTrERAn7aAJwPz4wbu0W4RPNhlgKGmd+2glZDewCfbi9d LQtahiILQg83vkzyfAR2BV4= =mjFe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex and Flex
Manlio Perillo ha scritto: [...] Another problem. In this rule: @comment= \/\*[^\*]*\*+([^\/\*][^\*]*\*+)*\/ [^\*] means all characters except '*', but Alex seems to not include the new line character. Again sorry. The problem was not here. There was a missing rule for '.', to scan every characters. Regards Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hoogle? [Stacking monads]
Andrew Coppin wrote: After much searching (Hoogle rather failed me here), I discover that... I could probably elaborate on that point further. Try doing a Hoogle search for c1 (c2 x) - c2 (c1 x). Hoogle correctly states that Data.Traversable.sequence will do it for you. Now try doing c1 k (c2 x) - c2 (c1 k x). The 'sequence' function will also do this, but now Hoogle returns 0 results. This is puzzling, since AFAIK, the above two type signatures are equvilent in some sense. (Specifically, replace every type X with type Y and you get from one to the other.) To me, this looks like a Hoogle bug. (It goes without saying that Hoogle also failed to find anything for the more specific type signature I was searching for, despite the fact that 'sequence' unifies with it.) Is this a known issue? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: (As an aside, Control.Monad.ap is not a function I've ever heard of. It seems simple enough, but what an unfortunate name...!) I think it makes sense. It stands for apply, or at least that is what I think of when I see it. If we have a function f :: A - B - C - D and values a :: m A, b :: m B, c :: m C, then we can do: f `liftM` a `ap` b `ap` c ... which is the same as (using Applicative): f $ a * b * c ... both having type m D. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hmm, what license to use?
Hi Gour wrote: Don == Don Stewart [EMAIL PROTECTED] writes: Don * Only a small percent of Haskell libarires are LGPL, and Don nothing for which we don't have workarounds (e.g. HDBC vs Don galois-sqlite3 vs takusen). Hmm, Gtk2Hs wxhaskell - major GUI libs... wxHaskell uses a modified LGPL license (wxWidgets license). One that allows static linking. See http://www.haskell.org/haskellwiki/WxHaskell/License . From the description of the wxWidgets license http://www.wxwidgets.org/about/newlicen.htm : The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software. Greetins, Mads Lindstrøm Sincerely, Gour ___ 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] Stacking monads
Jake McArthur wrote: Andrew Coppin wrote: (As an aside, Control.Monad.ap is not a function I've ever heard of. It seems simple enough, but what an unfortunate name...!) I think it makes sense. It stands for apply, or at least that is what I think of when I see it. There can be little doubt that this is what the designers intended. However, why didn't they name it, say, apply? I just think that Haskell already has too many names like id and nub and elem and Eq and Ix. Would it kill anybody to write out more descriptive names? Also, I'm fuzzy on why ap is even a useful function to have in the first place. I can see what it does, but when are you ever going to need a function like that? (I'm not saying we should get rid of it, I'm just puzzled as to why anybody thought to include it to start with.) If we have a function f :: A - B - C - D and values a :: m A, b :: m B, c :: m C, then we can do: f `liftM` a `ap` b `ap` c ... which is the same as (using Applicative): f $ a * b * c ... both having type m D. Again we seem to have two different sets of functions which none the less appear to do exactly the same thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, Oct 3, 2008 at 1:39 PM, Andrew Coppin [EMAIL PROTECTED] wrote: David Menendez wrote: Applicative is a class of functors that are between Functor and Monad in terms of capabilities. Instead of (=), they have an operation (*) :: f (a - b) - f a - f b, which generalizes Control.Monad.ap. (As an aside, Control.Monad.ap is not a function I've ever heard of. It seems simple enough, but what an unfortunate name...!) I believe it's short for apply. ap generalizes the liftM* functions, so liftM2 f a b = return f `ap` a `ap` b liftM3 f a b c = return f `ap` a `ap` b `ap` c and so forth. It wasn't until fairly recently that people realized that you could do useful things if you had return and ap, but not (=), which why we have some unfortunate limitations in the Haskell prelude, like Applicative not being a superclass of Monad. This leads to all the duplication between Applicative and Monad. In a perfect world, we would only need the Applicative versions. The nice thing about Applicative functors is that they compose. With monads, you can't make (Comp m1 m2) a monad without a function analogous to inner, outer, or swap. So I see. I'm still not convinced that Applicative helps me in any way though... To be honest, neither am I. But it's a useful thing to be aware of. From your code examples, it isn't clear to me that applicative functors are powerful enough, but I can't really say without knowing what you're trying to do. The whole list-style multiple inputs/multiple outputs trip, basically. Would you be willing to share the implementation of ResultSet? If you're relying on a list somewhere, then it should be possible to switch the implementation to one of the nondeterminism monad transformers, which would give you the exception behavior you want. The fact that the functions you gave take a state as an argument and return a state suggests that things could be refactored further. If you look at run_or, you'll see that this is _not_ a simple state monad, as in that function I run two actions starting from _the same_ initial state - something which, AFAIK, is impossible (or at least very awkward) with a state monad. Really, it's a function that takes a state and generates a new state, but it may also happen to generate *multiple* new states. It also consumes a Foo or two in the process. That's what happens if you apply a state monad transformer to a nondeterminism monad. plusMinusOne :: StateT Int [] () plusMinusOne = get s = \s - mplus (put $ s + 1) (put $ s - 1) execStateT plusMinusOne 0 == [1,-1] execStateT (plusMinusOne plusMinusOne) 0 == [2,0,0,-2] (FYI, execStateT is similar to runStateT, except that it discards the return value, which is () in our example.) So it might be possible to rewrite your code along these lines: type M = StateT State [] run :: Foo - M () runOr :: Foo - Foo - M () runOr x y = mplus (run x) (run y) runAnd :: Foo - Foo - M () runAnd x y = run x run y The type StateT State [] alpha is isomorphic to State - [(alpha, State)], which means that each of the computations in mplus gets its own copy of the state. There are a few ways to add exceptions to this, depending on how you want the exceptions to interact with the non-determinism. 1. StateT State (ErrorT ErrorType []) alpha This corresponds to State - [(Either ErrorType alpha, State)]. Each branch maintains its own state and is isolated from exceptions in other branches. In other words, catchErr (mplus a b) h == mplus (catchErr a h) (catchErr b h) 2. StateT State (NondetT (Either ErrorType)) alpha (NondetT isn't in the standard libraries, but I can provide code if needed.) This corresponds to State - Either ErrorType [(alpha, State)]. Left uncaught, an exception raised in any branch will cause all branches to fail. mplus (throw e) a == throw e -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, Oct 3, 2008 at 3:10 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Jake McArthur wrote: Andrew Coppin wrote: But on the other hand, that would seem to imply that every monad is trivially applicative, yet studying the libraries this is not the case. Actually, it is the case. It is technically possible to write: instance Monad m = Applicative m where pure = return (*) = ap We don't include the above definition because it elimimates all possibility of specialization. I don't follow. For some monads, there are implementations of * which are more efficient than the one provided by ap. Similarly, there are ways to implement fmap which are more efficient than using liftM. Of course, the *real* reason we don't define the instance given above is that there are instances of Applicative that aren't monads, and we want to avoid overlapping instances. The reason for the separation of the two for many functions is so that types which are instances of only one of the two can still take advantage of the functionality. Well, that makes sense once you assume two seperate, unconnected classes. I'm still fuzzy on that first point though. It's historical. Monad pre-dates Applicative by several years. Because it's part of the Haskell 98 standard, no one is willing to change Monad to make Applicative a superclass. Thus all the duplication. (Also, many of the duplicate functions are found in the Haskell 98 report, so we can't replace them with their more-general Applicative variants.) Foldable seems simplish, except that it refers to some odd monoid class that looks suspiciously like MonadPlus but isn't... wuh? A Monoid is simply anything that has an identity element (mempty) and an associative binary operation (mappend). It is not necessary for a complete instance of Foldable. Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? There are at least three reasons why MonadPlus and Monoid are distinct. First, MonadPlus is older than Monoid, even though Monoid is more general. Second, MonadPlus and Monoid have different kinds, * - * and *, respectively. Instances of MonadPlus are more restricted, because they have to work with any type parameter, whereas instances of Monoid can place constraints. Third, instances of MonadPlus must follow additional laws relating the behavior of mplus and mzero to return and (=). -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Jake McArthur wrote: Andrew Coppin wrote: But on the other hand, that would seem to imply that every monad is trivially applicative, yet studying the libraries this is not the case. Actually, it is the case. It is technically possible to write: instance Monad m = Applicative m where pure = return (*) = ap We don't include the above definition because it elimimates all possibility of specialization. I don't follow. The reason for the separation of the two for many functions is so that types which are instances of only one of the two can still take advantage of the functionality. Well, that makes sense once you assume two seperate, unconnected classes. I'm still fuzzy on that first point though. Foldable seems simplish, except that it refers to some odd monoid class that looks suspiciously like MonadPlus but isn't... wuh? A Monoid is simply anything that has an identity element (mempty) and an associative binary operation (mappend). It is not necessary for a complete instance of Foldable. Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
wchogg: On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton [EMAIL PROTECTED] wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful. How about EDSLs for producing high assurance controllers, and other robust devices they might need. I imagine the LHC has a good need for verified software components... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 3:17 AM, Jason Dusek [EMAIL PROTECTED] wrote: Perhaps I am lacking in imagination, but I still can't see the value of one tuples. You can use them to defeat seq. undefined `seq` x == undefined OneTuple undefined `seq` x == x That might be useful if a polymorphic function is using seq to force evaluation, and you don't want it to. But I can't imagine that coming up much in practice. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
Andrew Coppin wrote: Oh, no. The entire bar is 2 Kg, I wasn't actually planning to eat the whole thing! o_O My god, my pancreas would explode or something... My Dad once ate two bars of dark cooking chocolate. He said he got some odd visual distortions; flickering auras around things, and size distortions where small things looked big and big things looked small. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, Oct 3, 2008 at 12:10 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? MonadPlus is a class for type constructors, generic over the type of the elements: class MonadPlus m where mzero :: m a mplus :: m a - m a - m a (note the lack of a in the class signature; the methods have to be defined for ALL possible a). whereas monoid is a class for concrete types: class Monoid a where mempty :: a mappend :: a - a - a The MonadPlus instance for lists is very constrained: instance MonadPlus [] where mzero = [] -- only possibly definition mplus = (++) There's no other possible fully-defined definition of mzero, and the laws for mplus constrain its definition significantly; the only real change you are allowed to make is to merge the elements of the two input lists in some interesting fashion. Even then you need to keep the relative ordering of the elements within a list the same. The monoid definition is far more open, however; there are many possible monoid definitions for lists. This admits a definition like the following: instance Monoid a = Monoid [a] where mempty = [mempty] mappend xs ys = [x `mappend` y | x - xs, y - ys] Of course, other definitions are possible; this one fits the monoid laws: mempty `mappend` a == a a `mappend` mempty == a but there are other choices that do so as well (one based on zipWith, for example, , or drop the Monoid a constraint and just use [] and ++) It's similar to Monad vs. Applicative; you can use any Monad definition to create a valid Applicative definition, but it's possible that other definitions exist, or, at the least, are more efficient. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
David Menendez wrote: On Fri, Oct 3, 2008 at 1:39 PM, Andrew Coppin [EMAIL PROTECTED] wrote: (As an aside, Control.Monad.ap is not a function I've ever heard of. It seems simple enough, but what an unfortunate name...!) I believe it's short for apply. Yeah, but shame about the name. ;-) ap generalizes the liftM* functions, so liftM2 f a b = return f `ap` a `ap` b liftM3 f a b c = return f `ap` a `ap` b `ap` c and so forth. Now that at least makes sense. (It's non-obvious that you can use it for this. If it weren't for curried functions, this wouldn't work at all...) It wasn't until fairly recently that people realized that you could do useful things if you had return and ap, but not (=), which why we have some unfortunate limitations in the Haskell prelude, like Applicative not being a superclass of Monad. This leads to all the duplication between Applicative and Monad. In a perfect world, we would only need the Applicative versions. OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) So I see. I'm still not convinced that Applicative helps me in any way though... To be honest, neither am I. But it's a useful thing to be aware of. OK. (Now that I've figured out what it *is*...) Would you be willing to share the implementation of ResultSet? If you're relying on a list somewhere, then it should be possible to switch the implementation to one of the nondeterminism monad transformers, which would give you the exception behavior you want. Consider the following: factorise n = do x - [1..] y - [1..] if x*y == n then return (x,y) else fail not factors This is a very stupid way to factorise an integer. (But it's also very general...) As you may already be aware, this fails miserably because it tries all possible values for y before trying even one new value for x. And since both lists there are infinite, this causes an endless loop that produces (almost) nothing. My ResultSet monad works the same way as a list, except that the above function discovers all finite solutions in finite time. The result is still infinite, but all the finite solutions are within a finite distance of the beginning. Achieving this was Seriously Non-Trivial. (!) As in, it's several pages of seriously freaky code that took me days to develop. AFAIK, nothing like this already exists in the standard libraries. If you look at run_or, you'll see that this is _not_ a simple state monad, as in that function I run two actions starting from _the same_ initial state - something which, AFAIK, is impossible (or at least very awkward) with a state monad. Really, it's a function that takes a state and generates a new state, but it may also happen to generate *multiple* new states. It also consumes a Foo or two in the process. That's what happens if you apply a state monad transformer to a nondeterminism monad. So it might be possible to rewrite your code along these lines: type M = StateT State [] run :: Foo - M () runOr :: Foo - Foo - M () runOr x y = mplus (run x) (run y) runAnd :: Foo - Foo - M () runAnd x y = run x run y The type StateT State [] alpha is isomorphic to State - [(alpha, State)], which means that each of the computations in mplus gets its own copy of the state. What does mplus do in this case? (I know what it does for Maybe, but not for any other monad.) There are a few ways to add exceptions to this, depending on how you want the exceptions to interact with the non-determinism. 1. StateT State (ErrorT ErrorType []) alpha Each branch maintains its own state and is isolated from exceptions in other branches. Nope, that's wrong. In this program, Foo is provided by the user, and an exception indicates that user entered an invalid expression. Thus all processing should immediately abort and a message should be reported to the wetware for rectification. (That also means that there will never be any need to catch exceptions, since they are all inherantly fatal.) 2. StateT State (NondetT (Either ErrorType)) alpha (NondetT isn't in the standard libraries, but I can provide code if needed.) Left uncaught, an exception raised in any branch will cause all branches to fail. That looks more like it, yes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
David Menendez wrote: For some monads, there are implementations of * which are more efficient than the one provided by ap. Similarly, there are ways to implement fmap which are more efficient than using liftM. Of course, the *real* reason we don't define the instance given above is that there are instances of Applicative that aren't monads, and we want to avoid overlapping instances. OK, now I understand. (Of course, if Applicative was already a superclass of Monad, presumably that last wouldn't still stand?) Well, that makes sense once you assume two seperate, unconnected classes. I'm still fuzzy on that first point though. It's historical. Ah. So brokenness in the name of backwards compatibility? (Is this why we have alternate Prelude modules?) Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? There are at least three reasons why MonadPlus and Monoid are distinct. First, MonadPlus is older than Monoid, even though Monoid is more general. Second, MonadPlus and Monoid have different kinds, * - * and *, respectively. Instances of MonadPlus are more restricted, because they have to work with any type parameter, whereas instances of Monoid can place constraints. Third, instances of MonadPlus must follow additional laws relating the behavior of mplus and mzero to return and (=). OK, good. Also, I notice that the documentation for Monoid mentions that numbers form one. But that's not actually correct. Numbers for *several*! And yet, a given number type can only have *one* Monoid instance. (Or indeed, only one instance for _any_ typeclass.) How do you get round that? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, Oct 3, 2008 at 12:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: factorise n = do x - [1..] y - [1..] if x*y == n then return (x,y) else fail not factors This is a very stupid way to factorise an integer. (But it's also very general...) As you may already be aware, this fails miserably because it tries all possible values for y before trying even one new value for x. And since both lists there are infinite, this causes an endless loop that produces (almost) nothing. You should look at LogicT at http://okmij.org/ftp/Computation/monads.html The magic words you are looking for are fair disjunction and fair conjunction. The paper is full of mind-stretching code but it already does everything you want. And it is a monad transformer already, so it's easy to attach Error to it. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
Paul Johnson wrote: Andrew Coppin wrote: Oh, no. The entire bar is 2 Kg, I wasn't actually planning to eat the whole thing! o_O My god, my pancreas would explode or something... My Dad once ate two bars of dark cooking chocolate. He said he got some odd visual distortions; flickering auras around things, and size distortions where small things looked big and big things looked small. I understand that chocolate does contain chemicals which are actually moderately toxic. (It just doesn't contain very much of them - or at least, the normal *milk* chocolate doesn't. Dark chocolate would presumably contain more of these.) For what it's worth, 80% of my diet is cheese, and 10% is chocolate. Apparently that particular combination is supposed to have all sorts of dire effects (including severe headaches). I suffer no such symptoms that I'm aware of. Never have. (But then, people tell me they get a lift from caffine, and I find no such effect. Nor do I have severe withdrawal symptoms when I stop taking it.) Maybe I'm just weird? (Oh, wait... I use Haskell!) In other news... apparently chocolate is leathaly toxic to dogs. Random. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
Hallo, Andrew Coppin wrote: In other news... apparently chocolate is leathaly toxic to dogs. Random. Chicolate is extremely toxic to cats. Cheers, -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: run_or s0 x y = let either_rset1 = sequence $ run s0 x either_rset2 = sequence $ run s0 y either_rset3 = do rset1 - either_rset1; rset2 - either_rset2; return (merge rset1 rset2) in case either_rset3 of Left e- throwError e Right rset - lift rset Do you realise, this single snippet of code utilises the ErrorT monad [transformer], the ResultSet monad, *and* the Either monad, all in the space of a few lines?? That's three monads in one function! o_O I scare *myself*, I don't know about you guys... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, 2008-10-03 at 20:43 +0100, Andrew Coppin wrote: David Menendez wrote: It wasn't until fairly recently that people realized that you could do useful things if you had return and ap, but not (=), which why we have some unfortunate limitations in the Haskell prelude, like Applicative not being a superclass of Monad. This leads to all the duplication between Applicative and Monad. In a perfect world, we would only need the Applicative versions. OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) I'm not a big fan of backward-compatibility myself, but changing Monad to be a sub-class of Applicative actually would have broken every monad instance in existence (at the time Applicative was added, since it didn't have any instances yet). I don't know what proportion of Haskell programs/libraries/etc. have at least one Monad instance in them, but I would guess it's high. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monoids [Stacking monads]
Ryan Ingram wrote: Newtypes is the general ( sadly unsatisfactory) answer: Oh dear. Well that _is_ pretty unsatisfactory... Given the constraints of the Haskell type system, could we do better in principle? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Oct 3, 2008, at 15:10 , Andrew Coppin wrote: The reason for the separation of the two for many functions is so that types which are instances of only one of the two can still take advantage of the functionality. Well, that makes sense once you assume two seperate, unconnected classes. I'm still fuzzy on that first point though. Foldable seems simplish, except that it refers to some odd monoid class that looks suspiciously like MonadPlus but isn't... wuh? A Monoid is simply anything that has an identity element (mempty) and an associative binary operation (mappend). It is not necessary for a complete instance of Foldable. Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? Because typeclasses aren't like OO classes. Specifically: while you can specify what looks like class inheritance (e.g. this Monad is also a Monoid you can't override inherited methods (because it's a Monad, you can't specify as part of the Monad instance the definition of a Monoid class function). So if you want to define MonadPlus to look like a Monad and a Monoid, you have to pick one and *duplicate* the other (without using the same names, since they're already taken by the typeclass you *don't* choose). Usually this isn't a problem, because experienced Haskell programmers don't try to use typeclasses for OO. But there are the occasional mathematically-inspired relationships (Functor vs. Monad, MonadPlus vs. Monoid, Applicative vs. Monad, etc.) that can't be expressed properly as a result. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Jonathan Cast wrote: On Fri, 2008-10-03 at 20:43 +0100, Andrew Coppin wrote: OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) I'm not a big fan of backward-compatibility myself, but changing Monad to be a sub-class of Applicative actually would have broken every monad instance in existence (at the time Applicative was added, since it didn't have any instances yet). I don't know what proportion of Haskell programs/libraries/etc. have at least one Monad instance in them, but I would guess it's high. Hmm, that's quite a lot of breakage. So if it had been set up this way from day 1, we wouldn't be having this conversation, but it's now too expensive to change it. Is that basically what it comes down to? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, 2008-10-03 at 21:02 +0100, Andrew Coppin wrote: Jonathan Cast wrote: On Fri, 2008-10-03 at 20:43 +0100, Andrew Coppin wrote: OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) I'm not a big fan of backward-compatibility myself, but changing Monad to be a sub-class of Applicative actually would have broken every monad instance in existence (at the time Applicative was added, since it didn't have any instances yet). I don't know what proportion of Haskell programs/libraries/etc. have at least one Monad instance in them, but I would guess it's high. Hmm, that's quite a lot of breakage. So if it had been set up this way from day 1, we wouldn't be having this conversation, but it's now too expensive to change it. Is that basically what it comes down to? Sort of. (Although I note that Monad isn't a sub-class of Functor, either, and I think those are coeval.) It is too expensive to change it during the period between when Applicative was discovered and now. But that could change in the future --- I'm sure a much higher of types with Monad instances happen to have Applicative instances as well now. If that proportion rises by enough, the backward compatibility argument would become less compelling. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building gtkhs, OpenSolaris x86
Hey folks, I know it seems an obtuse OS to build on, but trust me, it's pretty nice despite the hassles. I'm getting these three errors (repeated a few times) while building gtkhs-0.9.13 on ghc 6.8.3, and was hoping for any suggestions on where to go from here: tools/c2hs/base/general/Map.hs:16:7: Could not find module `Data.Map': it is a member of package containers-0.1.0.2, which is hidden tools/c2hs/base/errors/Errors.hs:44:0: Failed to load interface for `Position': Use -v to see a list of the files searched for. glib/System/Glib.hs:13:0: Failed to load interface for `System.Glib.UTFString': Use -v to see a list of the files searched for. What did I screw up? Is there something else I should load? Maybe an older version of gtkhs? ghc? Thanks for any help! -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
But (a) is not a lifted version of a, whereas (a,b) is a lifted version of the a b product. So it's not consistent, and thereby wrong. -- Lennart On Fri, Oct 3, 2008 at 6:07 PM, Jason Dusek [EMAIL PROTECTED] wrote: Lennart Augustsson [EMAIL PROTECTED] wrote: Let me pick one example. Let's make a class that can convert between tuples and lists. -- XXX This doesn't work, and is just wrong. -- instance TupleList (a) [a] where --tupleToList (a) = [a] --listToTuple [a] = (a) It's not clear to me what is so wrong about it. If the 1-ary tuple is the 1-ary product, it makes sense. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Brandon S. Allbery KF8NH wrote: On Oct 3, 2008, at 15:10 , Andrew Coppin wrote: Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? Because typeclasses aren't like OO classes. Specifically: while you can specify what looks like class inheritance (e.g. this Monad is also a Monoid you can't override inherited methods (because it's a Monad, you can't specify as part of the Monad instance the definition of a Monoid class function). So if you want to define MonadPlus to look like a Monad and a Monoid, you have to pick one and *duplicate* the other (without using the same names, since they're already taken by the typeclass you *don't* choose). I was thinking more, why not just delete MonadPlus completely, and have any function that needs a monad that's also a monoid say so in its context? (Obviously one of the answers to that is because it would break vast amounts of existing code.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, 2008-10-03 at 12:59 -0700, Jonathan Cast wrote: On Fri, 2008-10-03 at 21:02 +0100, Andrew Coppin wrote: Jonathan Cast wrote: On Fri, 2008-10-03 at 20:43 +0100, Andrew Coppin wrote: OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) I'm not a big fan of backward-compatibility myself, but changing Monad to be a sub-class of Applicative actually would have broken every monad instance in existence (at the time Applicative was added, since it didn't have any instances yet). I don't know what proportion of Haskell programs/libraries/etc. have at least one Monad instance in them, but I would guess it's high. Hmm, that's quite a lot of breakage. So if it had been set up this way from day 1, we wouldn't be having this conversation, but it's now too expensive to change it. Is that basically what it comes down to? Sort of. (Although I note that Monad isn't a sub-class of Functor, either, and I think those are coeval.) It is too expensive to change it during the period between when Applicative was discovered and now. But that could change in the future --- I'm sure a much higher of types with ^ proportion Monad instances happen to have Applicative instances as well now. If that proportion rises by enough, the backward compatibility argument would become less compelling. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
On Oct 3, 2008, at 15:38 , Paul Johnson wrote: Andrew Coppin wrote: Oh, no. The entire bar is 2 Kg, I wasn't actually planning to eat the whole thing! o_O My god, my pancreas would explode or something... My Dad once ate two bars of dark cooking chocolate. He said he got some odd visual distortions; flickering auras around things, and size distortions where small things looked big and big things looked small. Theobromine is interesting stuff. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: I was thinking more, why not just delete MonadPlus completely, and have any function that needs a monad that's also a monoid say so in its context? (Obviously one of the answers to that is because it would break vast amounts of existing code.) Because they are not the same. MonadPlus has more restrictions than Monoid. For an instance of the form instance MonadPlus m where, m a _must_ be a Monoid for _all_ a, whereas instance Monoid (m a) where may be defined for some specific a instead. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex and Flex
Brandon S. Allbery KF8NH ha scritto: On Oct 3, 2008, at 09:24 , Manlio Perillo wrote: Manlio Perillo ha scritto: However I have noted that there are some difference in the syntax between Alex and Flex? What is the rationale? By the way, here is the list of differences between Alex and Flex I have found, for people interested: 3) Alex does not support [_a-z0-9-] that must be rewritten as [_a-z0-9\-] The only *reliable* way to write that cset is to put the '-' as the first item. Likewise for ']' (and if you must match both, [-]...]). Escaping the character solve the problem, or at least I have tested and it works. It seems, however, that Alex is quite strict in accepted characters. As an example, this rule [ \t\r\n\f] does not match the space character; this character must be escaped: [\ \t\r\n\f] Flex seems to be more smart, here. Note that the escaping solve the problem 7): [EMAIL PROTECTED]@nmchar* Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, 2008-10-03 at 21:12 +0100, Andrew Coppin wrote: Brandon S. Allbery KF8NH wrote: On Oct 3, 2008, at 15:10 , Andrew Coppin wrote: Again, it looks like MonadPlus == Monad + Monoid, except all the method names are different. Why do we have this confusing duplication? Because typeclasses aren't like OO classes. Specifically: while you can specify what looks like class inheritance (e.g. this Monad is also a Monoid you can't override inherited methods (because it's a Monad, you can't specify as part of the Monad instance the definition of a Monoid class function). So if you want to define MonadPlus to look like a Monad and a Monoid, you have to pick one and *duplicate* the other (without using the same names, since they're already taken by the typeclass you *don't* choose). I was thinking more, why not just delete MonadPlus completely, and have any function that needs a monad that's also a monoid say so in its context? This would be clunky. Consider: select as = msum $ do (as0, a:as) - breaks as return $ do x - a return (x, as0 ++ as) -- | Divide a list into (snoc-list, cons-list) pairs every possible -- way breaks :: [a] - [([a], [a])] breaks as = breaks [] as where breaks' as0 [] = [(as0, [])] breaks' as0 (a:as) = (as0, a:as) : breaks' (a:as0) as You can say select :: MonadPlus m = [m a] - m (a, [m a]) but not select :: (Monad m, Monoid (m a)) = [m a] - m (a, [m a]) --- for this particular implementation, you need select :: (Monad m, Monoid (m (a, [m a]))) = [m a] - m (a, [m a]) but then if you want to write select_ = fmap fst . select you have select_ :: (Monad m, Monoid (m (a, [m a]))) = [m a] - m a . This is a wtf constraint, obviously. You can avoid this by writing select_ :: (Monad m, forall b. Monoid (m b)) = [m a] - m a but that's somewhat beyond the scope of the existing type class system. Unless you write a new type class that is *explicitly* (Monad m, forall b. Monoid (m b)). Which is what MonadPlus is. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Jake McArthur wrote: Andrew Coppin wrote: I was thinking more, why not just delete MonadPlus completely, and have any function that needs a monad that's also a monoid say so in its context? (Obviously one of the answers to that is because it would break vast amounts of existing code.) Because they are not the same. MonadPlus has more restrictions than Monoid. For an instance of the form instance MonadPlus m where, m a _must_ be a Monoid for _all_ a, whereas instance Monoid (m a) where may be defined for some specific a instead. OK, fair enough then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Fri, Oct 3, 2008 at 3:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: David Menendez wrote: It wasn't until fairly recently that people realized that you could do useful things if you had return and ap, but not (=), which why we have some unfortunate limitations in the Haskell prelude, like Applicative not being a superclass of Monad. This leads to all the duplication between Applicative and Monad. In a perfect world, we would only need the Applicative versions. OK. So it's broken for compatibility then? (Presumably any time you change something from the Prelude, mass breakage ensues!) Exactly. Since the Prelude is specified in the Haskell 98 report, you can't add or subtract things without losing Haskell 98 compatibility. We *could* define a new Prelude that did things more sensibly, but then code either has to pick which Prelude to support or else jump through extra hoops to be cross-compatible. Would you be willing to share the implementation of ResultSet? If you're relying on a list somewhere, then it should be possible to switch the implementation to one of the nondeterminism monad transformers, which would give you the exception behavior you want. Consider the following: factorise n = do x - [1..] y - [1..] if x*y == n then return (x,y) else fail not factors This is a very stupid way to factorise an integer. (But it's also very general...) As you may already be aware, this fails miserably because it tries all possible values for y before trying even one new value for x. And since both lists there are infinite, this causes an endless loop that produces (almost) nothing. My ResultSet monad works the same way as a list, except that the above function discovers all finite solutions in finite time. The result is still infinite, but all the finite solutions are within a finite distance of the beginning. Achieving this was Seriously Non-Trivial. (!) As in, it's several pages of seriously freaky code that took me days to develop. AFAIK, nothing like this already exists in the standard libraries. Now I'm even more curious to see how you did it. I spent some time a few months ago developing a monad that does breadth-first search. It would be able to handle the example you gave almost without change. Some other possibilities: (1) logict http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logict This defines a backtracking monad transformer (the NondetT I mentioned in my previous message), and provides a fair variant of (=) that you could use to define factorise. It's not as foolproof as the other options. (2) control-monad-omega http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-monad-omega This is a monad similar to [] that uses a diagonal search pattern. (3) Oleg Kiselyov's fair and backtracking monad http://okmij.org/ftp/Computation/monads.html#fair-bt-stream This uses a search pattern that I don't fully understand, and only satisfies the Monad and MonadPlus laws if you ignore the order of results, but think it's at least as robust as Omega. If you look at run_or, you'll see that this is _not_ a simple state monad, as in that function I run two actions starting from _the same_ initial state - something which, AFAIK, is impossible (or at least very awkward) with a state monad. Really, it's a function that takes a state and generates a new state, but it may also happen to generate *multiple* new states. It also consumes a Foo or two in the process. That's what happens if you apply a state monad transformer to a nondeterminism monad. So it might be possible to rewrite your code along these lines: type M = StateT State [] run :: Foo - M () runOr :: Foo - Foo - M () runOr x y = mplus (run x) (run y) runAnd :: Foo - Foo - M () runAnd x y = run x run y The type StateT State [] alpha is isomorphic to State - [(alpha, State)], which means that each of the computations in mplus gets its own copy of the state. What does mplus do in this case? (I know what it does for Maybe, but not for any other monad.) mplus a b returns all the results returned by a and b. For lists, it returns all the results of a before the results of b. I suspect it corresponds to merge in your code. For true backtracking monads (that is, not Maybe), mplus also has this property: mplus a b = f == mplus (a = f) (b = f) There is a school of thought that Maybe (and Error/ErrorT) should not be instances of MonadPlus because they do not satisfy that law. 2. StateT State (NondetT (Either ErrorType)) alpha (NondetT isn't in the standard libraries, but I can provide code if needed.) Left uncaught, an exception raised in any branch will cause all branches to fail. That looks more like it, yes. That's what I figured. You'll need a transformer, then, which rules out Omega. Since you don't care about catching exceptions, you can just do something like type M = StateT State (LogicT (Either
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, 2008-10-03 at 15:38 -0400, David Menendez wrote: On Fri, Oct 3, 2008 at 3:17 AM, Jason Dusek [EMAIL PROTECTED] wrote: Perhaps I am lacking in imagination, but I still can't see the value of one tuples. You can use them to defeat seq. undefined `seq` x == undefined OneTuple undefined `seq` x == x That might be useful if a polymorphic function is using seq to force evaluation, and you don't want it to. But I can't imagine that coming up much in practice. Think element strict polymorphic containers, e.g. data HeadStrictList a = Nil | Cons !a (HeadStrictList a) then type LazyList a = HeadStrictList (OneTuple a) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
derek.a.elkins: On Fri, 2008-10-03 at 15:38 -0400, David Menendez wrote: On Fri, Oct 3, 2008 at 3:17 AM, Jason Dusek [EMAIL PROTECTED] wrote: Perhaps I am lacking in imagination, but I still can't see the value of one tuples. You can use them to defeat seq. undefined `seq` x == undefined OneTuple undefined `seq` x == x That might be useful if a polymorphic function is using seq to force evaluation, and you don't want it to. But I can't imagine that coming up much in practice. Think element strict polymorphic containers, e.g. data HeadStrictList a = Nil | Cons !a (HeadStrictList a) then type LazyList a = HeadStrictList (OneTuple a) Used in practice to prevent strict state components in list fusion leaking into user's lazy code, dataL a = L a -- lazy / lifted newtype S a = S a -- strict / unlifted class Unlifted a where instance Unlifted (L a) where expose (L _) s = s instance Unlifted (S a) where expose (S a) s = seq a s data Stream a = forall s. Unlifted s = Stream !(s - Step a s) -- ^ a stepper function !s-- ^ an initial state So we can then ensure stream :: [a] - Stream a stream xs0 = Stream next (L xs0) where next (L []) = Done next (L (x:xs)) = Yield x (L xs) Has the appropriate strictness properties. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
Lennart Augustsson [EMAIL PROTECTED] wrote: But (a) is not a lifted version of a, whereas (a,b) is a lifted version of the a b product. So it's not consistent, and thereby wrong. Well, we can't represent the unlifted product in Haskell, right? You have to use some constructor. So if we just say we are using tuples to represent unlifted products, what's so bad about that? At present, tupling doesn't lift values into anything, since we don't have generic operations on tuples. The last two messages in this thread suggests this has more to do with the internals of Haskell than they do with consistent semantics -- so I am perhaps missing the point. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
On 3 Oct 2008, at 23:50, Andrew Coppin wrote: For what it's worth, 80% of my diet is cheese, and 10% is chocolate. Remind me not to take food out of your hands, OK? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building gtkhs, OpenSolaris x86
On 2008 Oct 3, at 16:08, Lally Singh wrote: I know it seems an obtuse OS to build on, but trust me, it's pretty nice despite the hassles. I'm getting these three errors (repeated a few times) while building gtkhs-0.9.13 on ghc 6.8.3, and was hoping for any suggestions on where to go from here: tools/c2hs/base/general/Map.hs:16:7: Could not find module `Data.Map': it is a member of package containers-0.1.0.2, which is hidden tools/c2hs/base/errors/Errors.hs:44:0: Failed to load interface for `Position': Use -v to see a list of the files searched for. glib/System/Glib.hs:13:0: Failed to load interface for `System.Glib.UTFString': Use -v to see a list of the files searched for. The first error is the real one; the others happen because the gtk2hs makefile doesn't properly abort when a sub-build fails. (This is probably a bash-ism: setting -e aborts the current iteration of a loop, not the entire script/fragment containing the loop. Supposedly POSIX mandates this braindamage. I'm dubious.) I have no idea what's causing the first one, though; normally it means something is missing from a Cabal configuration file, but last I checked gtk2hs didn't use Cabal and I don't see an obvious candidate in our gtk2hs 0.9.13 source tree. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
On Fri, Oct 3, 2008 at 2:38 PM, Don Stewart [EMAIL PROTECTED] wrote: wchogg: On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton [EMAIL PROTECTED] wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful. How about EDSLs for producing high assurance controllers, and other robust devices they might need. I imagine the LHC has a good need for verified software components... ^^ totally agree on the verified Don. Don, by controller do you mean an I/O controller?? Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: having fun with GADT's
On Tue, Sep 30, 2008 at 6:25 PM, Anatoly Yakovenko [EMAIL PROTECTED] wrote: has the with syntax described in http://www.haskell.org/pipermail/haskell/2005-May/015815.html been replaced with the where syntax? so data Foo a where FooInt :: FooInt the same thing as data Foo A = FooInt with a = Int I don't see any such syntax in the aforementioned message. But yes, the where syntax is currently the only way to do GADTs (and I hope that does *not* change, because I love the GADT syntax!): data Foo a where FooInt :: Foo Int Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell participating in big science like CERN Hadrian...
I have to write in C++ everyday. I just worked at D*ll .. a total train wreck . software very unstable .. written in C++ Maybe a lot of blame can be put at the door of very lazy people; however, in my opinion, the strong/static type checking seriously corral lazy developers. I have found myself almost unconsciously thinking in the Haskell strong type checking Welt Anschauung at work! Totally rocks! Vasili On Fri, Oct 3, 2008 at 8:29 AM, Creighton Hogg [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 5:47 AM, Dougal Stanton [EMAIL PROTECTED] wrote: 2008/10/3 Galchin, Vasili [EMAIL PROTECTED]: Hello, One of my interests based on my education is grand challenge science. Ok .. let's take the CERN Hadrian Accelerator. Where do you think Haskell can fit into the CERN Hadrian effort currently? Where do you think think Haskell currently is lacking and will have to be improved in order to participate in CERN Hadrian? Is that the experiment where Picts are accelerated to just short of the speed of light in order to smash through to the Roman Empire? ;-) I don't know what the main computational challenges are to the LHC researchers. The stuff in the press has mostly been about infrastructure --- how to store the gigabytes of data per second that they end up keeping, out of the petabytes that are produced in the first place (or something). Well, with the LHC efforts I don't think a technology like Haskell really has a place...at least not now. Even just a few years back, when I worked on this stuff, we were still doing lots of simulation in preparation for the actual live experiment and Haskell might have been a good choice for some of the tools. All of the detector simulation was written in C++, because C++ is the new FORTRAN to physicists, and you ain't seen nothing till you've seen a jury-rigged form of lazy evaluation built into a class hierarchy in C++. Now, would the C++ based simulation have run faster than a Haskell based one? Quite possibly. On the other hand, I remember how many delays and problems were caused by the sheer complexity of the codebase. That's where a more modern programming language might have been extremely helpful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Health effects
On 2008 Oct 3, at 15:50, Andrew Coppin wrote: Paul Johnson wrote: Andrew Coppin wrote: Oh, no. The entire bar is 2 Kg, I wasn't actually planning to eat the whole thing! o_O My god, my pancreas would explode or something... My Dad once ate two bars of dark cooking chocolate. He said he got some odd visual distortions; flickering auras around things, and size distortions where small things looked big and big things looked small. headaches). I suffer no such symptoms that I'm aware of. Never have. (But then, people tell me they get a lift from caffine, and I find no such effect. Nor do I have severe withdrawal symptoms when I stop taking it.) I resemble that. In fact, I have to be careful with caffeine because I won't notice how much I've had until I start having heart palpitations, odd joint aches, and other signs of caffeine overdose. In other news... apparently chocolate is leathaly toxic to dogs. Random. And cats. Theobromine is fun stuff, as I said. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pure Haskell database
So the issue is one writer, many readers across processes? Creating an actual mini-db-server might be the proper way to do this. Expose a simple socket by which other processes can query the DB state. If you need persistence between runs of your main server you can always snapshot on shutdown, or for error-tolerance you can also write to a transactional log (probably with a single writer thread that takes input over a chan). Assuming its still in good shape, haxr [http:// www.haskell.org/haxr/] would simplify writing the socket portion. Depending on how you wrote the surrounding server, you might be able to avoid mvars altogether (i.e. if your server was built in an agent style with only a single request handler thread, then state could just be passed between recursive calls [or even stashed in a State monad] and the request serialization would handle concurrency issues for you). Regards, S. On Oct 1, 2008, at 3:09 PM, Manlio Perillo wrote: Graham Fawcett ha scritto: [...] Never though about sparse array, what is the advantage? For the complexity, the same of a good hash map. Almost certainly worse complexity than a hash map; but the overhead could be much smaller. If (for example) you only needed a small number of key/value pairs (say, hundreds of thousands), you could implement your database trivially, e.g. a NULL-terminated array of key/value structs in shared memory. (Though having separate arrays for keys and values might help cache locality and boost performance). Lookup might be O(n) but with a small-ish N and with such a low overhead, it could perform very, very well. This seems an interesting idea, thanks. Manlio Perillo ___ 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] Haskell-cafe-cafe? Was: Re: Health effects
What /is/ it with haskell-cafe lately? Do we need a haskell-blah mailing list? I would subscribe to that. Hell, I would post to it probably more than I post to haskell-cafe. But I'd also divert it to a separate mailbox for when I have too much free time. Maybe call it haskell-cafe-cafe? not-haskell? --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-cafe-cafe? Was: Re: Health effects
On Fri, Oct 3, 2008 at 8:01 PM, Christopher Lane Hinson [EMAIL PROTECTED] wrote: What /is/ it with haskell-cafe lately? Do we need a haskell-blah mailing list? Thanks for saying it. +1. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: ap generalizes the liftM* functions, so liftM2 f a b = return f `ap` a `ap` b liftM3 f a b c = return f `ap` a `ap` b `ap` c and so forth. Now that at least makes sense. (It's non-obvious that you can use it for this. If it weren't for curried functions, this wouldn't work at all...) Note that the documentation for ap states: In many situations, the liftM operations can be replaced by uses of ap, which promotes function application. return f `ap` x1 `ap` ... `ap` xn is equivalent to liftMn f x1 x2 ... xn Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
Andrew Coppin wrote: run_or s0 x y = let either_rset1 = sequence $ run s0 x either_rset2 = sequence $ run s0 y either_rset3 = do rset1 - either_rset1; rset2 - either_rset2; return (merge rset1 rset2) in case either_rset3 of Left e- throwError e Right rset - lift rset Just to expand on that discussion of Control.Monad.ap aka. (Control.Applicative.*) in the other half of the thread. The expression do rset1 - either_rset1 rset2 - either_rset2 return (merge rset1 rset2) follows exactly the pattern Applicative is made for: We execute some actions, and combine their result using a pure function. Which action we execute is independent from the result of the previous actions. That means that we can write this expression as: return merge `ap` either_rset1 `ap` either_rset2 Note how we avoid to give names to intermediate results just to use them in the very next line. Since return f `ap` x == f `fmap` x, we can write shorter merge `fmap` either_rset1 `ap` either_rset2 Or in Applicative style: merge $ either_rset1 * either_rset2 Now that the expression is somewhat shorter, we can inline the either_rset1, 2 and 3 as follows: case merge $ sequence (run s0 x) * sequence (run s0 y) of Left e- throwError e Right rset - lift rset Note how the structure of the code reflects what happens. The structure is merge $ ... * ..., and the meaning is: merge is called on two arguments, which are created by running some actions, and the result is again an action. While we are one it, we can get rid of the pattern matching by employing the either function as follows: either throwError lift (merge $ sequence (run s0 x) * sequence (run s0 y)) Do you realise, this single snippet of code utilises the ErrorT monad [transformer], the ResultSet monad, *and* the Either monad, all in the space of a few lines?? That's three monads in one function! o_O Now it fits on a single line! Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 2:29 PM, Jason Dusek [EMAIL PROTECTED] wrote: Lennart Augustsson [EMAIL PROTECTED] wrote: But (a) is not a lifted version of a, whereas (a,b) is a lifted version of the a b product. So it's not consistent, and thereby wrong. Well, we can't represent the unlifted product in Haskell, right? You have to use some constructor. So if we just say we are using tuples to represent unlifted products, what's so bad about that? Unless I'm confused, unboxed tuples represent unlifted products. In a sense this is [using] some constructor, but in a sense not, since an unboxed tuple constructor has no runtime representation. The last two messages in this thread suggests this has more to do with the internals of Haskell than they do with consistent semantics -- so I am perhaps missing the point. I think most Haskellers try their best to keep the first subservient to the second. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt If you don't understand the causes, it is impossible to come up with a solution. -- Joe Biden ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] maybe a goal and challenge for the Haskell in terms of scientific computing
Hello, Here is a site I discovered a while back for another language ... I guess in the back of my mind this more where I was going vis-a-vis scientific computing http://www.enthought.com/ Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-cafe-cafe? Was: Re: Health effects
On 2008 Oct 3, at 21:01, Christopher Lane Hinson wrote: What /is/ it with haskell-cafe lately? Do we need a haskell-blah mailing list? I would subscribe to that. Hell, I would post to it probably more than I post to haskell-cafe. But I'd also divert it to a separate mailbox for when I have too much free time. Oddly enough, it seems to me that haskell-*cafe* identifies a list that isn't tightly focused, as compared to [EMAIL PROTECTED] Perhaps we need to rethink names (although any changes will probably hurt). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Model-driven development (was: Haskell participting in big science like CERN Hadrian...)
G'day all. Quoting Don Stewart [EMAIL PROTECTED]: How about EDSLs for producing high assurance controllers, and other robust devices they might need. I imagine the LHC has a good need for verified software components... On a related topic, I'm curious if anyone apart from me has been secretly using Haskell for model-driven-development-lite. My current boss, not being a programmer, doesn't care where the code comes from, so the following conversation is unlikely to happen. Still. other people must also have thought of doing this: Well, the reason why I've produced so much C++ lately is because I've been generating all the boilerplate automatically. What with? Glad you asked... Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] maybe a goal and challenge for the Haskell in terms of scientific computing
On Oct 3, 2008, at 8:26 PM, Galchin, Vasili wrote: Here is a site I discovered a while back for another language ... I guess in the back of my mind this more where I was going vis-a-vis scientific computing http://www.enthought.com/ I interned at Enthought over this last summer; it's a very cool place. Many of the open-source scientific libraries could be rewritten in Haskell without significant difficulty, and this actually seems like a decent idea. SciPy and NumPy are the two most significant libraries worth thinking about, in my opinion. Some of the other software, e.g. Traits, is less relevant to scientific software in the context of Haskell. Much of their stack, especially Traits, TraitsGUI, and application libraries are designed to help write applications quickly without much programming experience. With these tools, it's easy for scientists, without knowing much Python, to write large programs that work well for most of their purposes. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New System.Process
Something that has irked me in the past about System.Process is the inability to obtain an OS system handle from the haskell Process handle. Such a facility would greatly enhance the interoperabity of c and haskell libraries. Provision is made (although not standardised) to obtain OS specific handles from haskell File Handles which is very useful. The same should be provided for Haskell Process handles. The main barrier to such a facility is the variability between OS representations of such a type (aka windows Handles, unix PID). comments anyone. _ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simplifying a IsFunction type class using type equality constraints
I recently had a need to use the IsFunction typeclass described by Oleg here: http://okmij.org/ftp/Haskell/isFunction.lhs and am wondering if the use of the TypeCast class can be correctly replaced by a type equality constraint. The IsFunction and TypeCast classes were defined as: data HTrue data HFalse class IsFunction a b | a - b instance TypeCast f HTrue = IsFunction (x-y) f instance TypeCast f HFalse = IsFunction a f -- literally lifted from the HList library class TypeCast a b | a - b, b-a where typeCast :: a - b class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' () x instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast'' instance TypeCast'' () a a where typeCast'' _ x = x I found the use of TypeCast in the IsFunction could be replaced by a type family: class IsFunction a b | a - b instance (f ~ TTrue) = IsFunction (x-y) f instance (f ~ TFalse) = IsFunction a f Which, to me, is easier to understand and appears to function the same. The type equality is a stronger (?) constraint than the TypeCast class, but for the case of IsFunction the use of type equality is correct. Am I correct? Is the second definition of IsFunction actually equivalent to the original? Cheers, -Corey O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 7:26 PM, Tim Chevalier [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 2:29 PM, Jason Dusek [EMAIL PROTECTED] wrote: Lennart Augustsson [EMAIL PROTECTED] wrote: But (a) is not a lifted version of a, whereas (a,b) is a lifted version of the a b product. So it's not consistent, and thereby wrong. Well, we can't represent the unlifted product in Haskell, right? You have to use some constructor. So if we just say we are using tuples to represent unlifted products, what's so bad about that? Unless I'm confused, unboxed tuples represent unlifted products. In a sense this is [using] some constructor, but in a sense not, since an unboxed tuple constructor has no runtime representation. Well, unboxed tuples are not really lifted nor unlifed, since you can't even pass one to a function. I like to pretend tuples are unlifted. Here's how I do it: * Never use seq on tuples (or functions). I could make this precise by putting seq in a typeclass (like it used to be - like it should be), and not having instances for tuples. * Never do a strict pattern match on a tuple. I.e. instead of writing f (x,y) = ..., I will write f ~(x,y) =... everywhere. Then (_|_,_|_) might as well be _|_, we have no way to tell them apart. I like to pretend functions are unlifed the same way; i.e. const _|_ = _|_. There are apparently occasions where lazily matching on a tuple will introduce a space leak. I am not 1337 enough to recognize them yet. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 7:24 PM, Luke Palmer [EMAIL PROTECTED] wrote: Well, unboxed tuples are not really lifted nor unlifed, since you can't even pass one to a function. It's true that unboxed tuples are not first-class. But what I mean by unlifted is that the type (# Int, Int #), when interpreted as a set, does not contain _|_ as an element (and I'm purposely conflating the unlifted/liftedness distinction with the unboxed/boxness distinction here). Is that what you mean, or do you mean something else? I like to pretend tuples are unlifted. Here's how I do it: Sure. But the compiler won't check that assumption for you. I don't know whether that has anything to do with the original question, though :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt If you don't understand the causes, it is impossible to come up with a solution. -- Joe Biden ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 8:32 PM, Tim Chevalier [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 7:24 PM, Luke Palmer [EMAIL PROTECTED] wrote: Well, unboxed tuples are not really lifted nor unlifed, since you can't even pass one to a function. It's true that unboxed tuples are not first-class. But what I mean by unlifted is that the type (# Int, Int #), when interpreted as a set, does not contain _|_ as an element (and I'm purposely conflating the unlifted/liftedness distinction with the unboxed/boxness distinction here). Is that what you mean, or do you mean something else? Yeah kind of, because if it doesn't contain _|_ as an element, then it's not even a domain! :-) I like to pretend tuples are unlifted. Here's how I do it: Sure. But the compiler won't check that assumption for you. I don't know whether that has anything to do with the original question, though :-) Nobody's questions are original. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] maybe a goal and challenge for the Haskell in terms of scientific computing
Let me recuse myself What is the nature of the open source license? Vasili On Fri, Oct 3, 2008 at 8:39 PM, Jeff Wheeler [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 8:26 PM, Galchin, Vasili wrote: Here is a site I discovered a while back for another language ... I guess in the back of my mind this more where I was going vis-a-vis scientific computing http://www.enthought.com/ I interned at Enthought over this last summer; it's a very cool place. Many of the open-source scientific libraries could be rewritten in Haskell without significant difficulty, and this actually seems like a decent idea. SciPy and NumPy are the two most significant libraries worth thinking about, in my opinion. Some of the other software, e.g. Traits, is less relevant to scientific software in the context of Haskell. Much of their stack, especially Traits, TraitsGUI, and application libraries are designed to help write applications quickly without much programming experience. With these tools, it's easy for scientists, without knowing much Python, to write large programs that work well for most of their purposes. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
