Re: [Haskell-cafe] Building production stable software in Haskell
Competing packages for XML or DBM is really awful, unless they happen to be interface compatible. And there is a good way of switching imps at assembly time, such that lib code that consumes xml doesn't depend on which xml imp I have. Of course, I realize that a good interface for those is still an open topic. And bad standards really can be worse than no standard. So what it comes down to, is, how big a 'standard' library should a Haskell programmer expect? On 9/17/07, David Roundy [EMAIL PROTECTED] wrote: On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote: Ketil Malde wrote: What would the disadvantages be to replacing Data.Map with this implementation? Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. To me, it seems like a recipe for usefulness. It would allow data structures to be used in multiple libraries. Competing packages is fine and dandy for something like an XML parser or DBM interface, but I'd like data structures to be standard, so that other packages can use them in their interfaces without putting undue burden on their users (and without the users being forced to figure out how to convert back and forth between various different Data.Map.*). -- David Roundy Department of Physics Oregon State University ___ 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] What puts False before True?
Well, traditionally, a boolean algebra is a ring, which means it has two operations corresponding to plus and times, and a zero such that a plus zero is a, and a one such that a times one is a. Also by longstanding tradition, zero is less than one. Now, in most programming languages, a boolean type is an element of the two valued boolean algebra, but not all boolean algebras are two valued. Four valued boolean algebra, for example, introduces m and not m (which must be distinct). There the ordering is typically false, not m, m, true. Overall, you might as well ask why 'b' is greater than 'a'. Consistent and useful. On 6/5/07, Albert Y. C. Lai [EMAIL PROTECTED] wrote: PR Stanley wrote: What do the ≤ symbols represent? I see you are still stuck in ISO-8859-1 and deprived of international characters and symbols. (And this reply in ISO-8859-1 too accordingly; normally I use UTF-8.) Unicode and UTF-8 FTW! :) ___ 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] Re: How Albus Dumbledore would sell Haskell
I think you are right. If you used something like a theorem prover as an example, you accidentally send the messsage that Haskell is very useful for esoteric stuff that only academics are interested in. Now, that doesn't mean that the example has to solve a real problem, but it does need to be something that the audience can relate to their own problems. There's already a lot of general buzz about functional techniques. Closures and lambda expressions are being, or have been, added to several imperative languages. This naturally leads to interest in higher order functions. The concurrency revolution is driving interest in immutable values and lockless algorithms. For people who do transactional work, having launchTheMissiles in the middle of a transaction be caught by the type system is incredible. At least some of the interest in dynamic types is driven by frustration with dealing with type annotations. So really, the example code just has to solve a problem they recognize. Even the sudoko solvers would be good, trite as they are. Or, some of the unix tools in Haskell. $0.02 -SMD On 4/19/07, Lennart Augustsson [EMAIL PROTECTED] wrote: A theorem prover might be a really cool example, but if there's one person in the audience that cares then Simon is lucky. :) You need to have examples that people can recognize and see the utility of. -- Lennart On Apr 19, 2007, at 20:48 , DavidA wrote: Simon Peyton-Jones simonpj at microsoft.com writes: But, just to remind you all: I'm particularly interested in concrete examples (pref running code) of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language I have something that I think nearly fits the bill. Unfortunately, I don't think it quite works because it's a bit specialised. However, I think it suggests a possible area to look, which I'll mention at the end. It's a theorem prover for intuitionistic propositional logic: http://www.polyomino.f2s.com/david/haskell/gentzen.html It's much shorter in Haskell than it would be in other languages. (It's even shorter than the ML that I based it on, because of some shortcuts I can take using lazy evaluation.) Strengths of Haskell that it demonstrates are: * How easy it is to define datatypes (eg trees), and manipulate them using pattern matching, with constructors, Eq, Show coming for free. * How lazy evaluation reduces code length by letting you write code that looks like it would do too much, and then lazy evaluate it (in the proof function) * The ability to extend the syntax with new symbolic operators * Use of higher order functions to simplify code (the (+++) operator) The problem is that I think Gentzen systems are a bit obscure. But I think you could probably show most of the same strengths of Haskell in something similar: game search, eg alpha-beta algorithm. Another advantage of doing game search would be that you'd get to show off persistent data structures (so that when you make a move in lookahead, you don't need to make a copy of the game state, because when you update the game state the old state still persists). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: k-minima in Haskell
Does the answer change if the data source isn't a list, already in memory, but a stream? That is, will the sort end up pulling the entire stream into memory, when we only need k elements from the entire stream. Interestingly, this is almost exactly the same as one of my standard interview questions, with the main difference being looking for the k elements closest to a target value, rather than the smallest. Not that it really changes the problem, but recognizing that is one of the things I'm looking for. On 4/12/07, apfelmus [EMAIL PROTECTED] wrote: raghu vardhan [EMAIL PROTECTED]: So, any algorithm that sorts is no good (think of n as huge, and k small). With lazy evaluation, it is! http://article.gmane.org/gmane.comp.lang.haskell.general/15010 [EMAIL PROTECTED] wrote: The essence of all the answers that you've received is that it doesn't matter if k is small, sorting is still the most elegant answer in Haskell. (It's not only most elegant, it can even be put to work.) The reason is that in Haskell, a function which sort function will produce the sorted list lazily. If you don't demand the while list, you don't perform the whole sort. Some algorithms are better than others for minimising the amount of work if not all of the list is demanded, but ideally, producing the first k elements will take O(n log k + k) time. You mean O(k * log n + n) of course. Regards, apfelmus ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: N and R are categories, no?
Thanks! Somehow, the, now blindingly obvious, fact that a monad must be a mapping into (not onto, right, at least in general?) is something I had missed, although it did lead me to be puzzled about join. So, although you could have a functor from N to R, there is no way it could be a monad. In Haskell, it would be Integer instead of N, since the category we deal with for Haskell Monads are Haskell types. Does a typeclass, like Num or Eq, form a category? I know that you can't restrict an instance of Monad to be only over a particular typeclass, but could I have an EqMonad, with all of the non-sugar properties of Monad? On 3/15/07, Ulf Norell [EMAIL PROTECTED] wrote: On 3/15/07, Steve Downey [EMAIL PROTECTED] wrote: EOk, i'm trying to write down, not another monad tutorial, because I don't know that much yet, but an explication of my current understanding of monads. But before I write down something that is just flat worng, I thought I'd get a cross check. (and I can't get to #haskell) Monads are Functors. Functors are projections from one category to another such that structure is preserved. One example I have in mind is the embedding of the natural numbers into the real numbers. The mapping is so good, that we don't flinch at saying 1 == 1.0. Monads are endofunctors (functors from one category to itself). This is easy to see from the type of join: join : m (m a) - m a For Haskell monads the category is the category of Haskell types and Haskell functions. In this category N and R are objects, so you'll get the wrong idea trying to see them as categories. / Ulf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: N and R are categories, no?
Thanks. I am trying to develop some intuition / understanding of monads outside category Fun, because I suspect that once I do, they will be both simpler and more interesting. I think if I take the category N to be the natural numbers and the algebraic functions of a single variable to be the arrows, then the functor that takes n to 2n might be a monad. That is, a coordinate transform should be monadic. -smd On 3/15/07, Nicolas Frisby [EMAIL PROTECTED] wrote: That said, N and R are indeed categories; however, considering them as categories should be carefully interlaced with your intuitions about them as types. I haven't formally checked it, but I would bet that this endofunctor over N, called Sign, is a monad: Sign x = x + x Pos = injectLeft Neg = injectRight unit = Pos join (Pos (Pos n)) = Pos n join (Pos (Neg n)) = Neg n join (Neg (Pos n)) = Neg n join (Neg (Neg n)) = Pos n Pos and Neg are just labels for sign. I'm assuming N is the naturals, not the integers; thus this monad might actually be useful :). Also note that this means there is not necessarily a mapping from F x - x. Neg 3 should not necessarily map to 3. Also, this structure is probably satisfies many more laws than just the monad laws--e.g. monoids or monoidals. So while it might not always make sense to consider N and R as categories when learning about category theory and Haskell, it might be helpful to learn about monads (and other notions) in categories simpler than the Fun category of functional types and partial functions--N and R are could be good categories for such learning. Have fun! On 3/15/07, Ulf Norell [EMAIL PROTECTED] wrote: On 3/15/07, Steve Downey [EMAIL PROTECTED] wrote: EOk, i'm trying to write down, not another monad tutorial, because I don't know that much yet, but an explication of my current understanding of monads. But before I write down something that is just flat worng, I thought I'd get a cross check. (and I can't get to #haskell) Monads are Functors. Functors are projections from one category to another such that structure is preserved. One example I have in mind is the embedding of the natural numbers into the real numbers. The mapping is so good, that we don't flinch at saying 1 == 1.0. Monads are endofunctors (functors from one category to itself). This is easy to see from the type of join: join : m (m a) - m a For Haskell monads the category is the category of Haskell types and Haskell functions. In this category N and R are objects, so you'll get the wrong idea trying to see them as categories. / Ulf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: N and R are categories, no?
Picky is good, because it helps me realize things like I haven't been paying enough attention to unit and join. Other than realizing that they make the box diagram and triangle diagram commute. -smd On 3/15/07, Dominic Steinitz [EMAIL PROTECTED] wrote: I haven't formally checked it, but I would bet that this endofunctor over N, called Sign, is a monad: Just to be picky a functor isn't a monad. A monad is a triple consisting of a functor and 2 natural transformations which make certain diagrams commute. If you are looking for examples, I always think that a partially ordered set is a good because the objects don't have any elements. A functor is then an order preserving map between 2 ordered sets and monad is then a closure (http://en.wikipedia.org/wiki/Closure_operator) - I didn't know this latter fact until I just looked it up. Dominic. ___ 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] N and R are categories, no?
EOk, i'm trying to write down, not another monad tutorial, because I don't know that much yet, but an explication of my current understanding of monads. But before I write down something that is just flat worng, I thought I'd get a cross check. (and I can't get to #haskell) Monads are Functors. Functors are projections from one category to another such that structure is preserved. One example I have in mind is the embedding of the natural numbers into the real numbers. The mapping is so good, that we don't flinch at saying 1 == 1.0. The functor that takes us from N to R is probably a Monad, that is, if N and R are categories. The real hard part is tying together how unit, join and bind produce a spacesuit that can protect apples from nuclear waste. I'm still getting that clear in my head, although my recent blinding flash of obviousness that M a is a type, and that of course types can do interesting things, I think gets me further along. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Read Instance for UArray won't port to linux
It's not just type variables. Type classes looked innocent, but smuggled an entire turing complete generic meta computation system into the language. Just thank SIMON that the error messages aren't as bad as C++ and templates. This does imply that mOleg have some equivalence relation to uAlexanrescue On 3/14/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello SevenThunders, Wednesday, March 14, 2007, 10:32:23 PM, you wrote: the type variables are dark side of GHC, and you need to have at least 1 mlOleg of brain to understand them. it will be great if someone will ever write reasonable introduction into this. meanwhile, you can look into ghc docs You guys are awesome! I post this not 12 hours ago and I already have a complete treatise on the subject. Yeah to clarify things putting an ellipsis between b and c would help. But also clarify the meaning of distinct type variables. Does this mean the type variable must not be parameterized? I ran into this because I decided during my port that I would try to learn some of the better build tools on linux. So now I'm acquainted with Cmake, which is a great tool and cabal which is also very impressive. My problem boiled down to the fact that I didn't know how to set the correct compiler flags within cabal. I figured out the FFI flags and now I suppose the gch extensions can be set with Ghc-options: -fglasgow-exts in my .cabal file. Is there a type in the Extensions field that corresponds to this? Spencer Janssen-2 wrote: It looks like you forgot to pass a compiler flag, namely -fglasgow-exts. Cheers, Spencer Janssen On Tue, 13 Mar 2007 22:20:20 -0700 (PDT) SevenThunders [EMAIL PROTECTED] wrote: I have the pleasure of porting a good sized Haskell application to linux. So far the Haskell code has compiled without incident, however some code that I hacked to implement a Read instance for Unboxed Arrays does not compile on linux even though it compiles just fine on Windows XP in Haskell 6.6. The code reads as, instance Read (UArray Int Double) where readsPrec p = readParen (p 9) (\r - [(array b as :: UArray Int Double, u) | (array,s) - lex r, (b,t) - reads s, (as,u) - reads t ]) The error in linux is: Illegal instance declaration for `Read (UArray Int Double)' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Read (UArray Int Double)' Why does it want three parameters for the instance type? I am baffled by this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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] Re: small boys performance
Many years ago, I got a B- in abstract algebra, and an A+ in differential geometry. Now I know why I worry about the blue glow of an unplanned criticality excursion occuring in my brain. On 3/14/07, Dan Piponi [EMAIL PROTECTED] wrote: On 3/14/07, Andrzej Jaworski [EMAIL PROTECTED] wrote: I am glad you are interested Dan. ... I do not intend to bore anybody with differential geometry but as I was pushed that far let me add that if Haskell was made to handle Riemannian geometry it could be useful in next generation machine learning research where logic, probability and geometry meet. I believe that you can probably handle (pseudo-)Riemannian geometry in the framework sketched here: http://sigfpe.blogspot.com/2006/09/practical-synthetic-differential.html That only goes as far as playing with vector fields and Lie derivatives but I think that forms and tensors should fit just fine into that framework. There's a simple way to use types to represent tensor products, and that's sketched here: http://sigfpe.blogspot.com/2006/08/geometric-algebra-for-free_30.html (Forget that that's about geometric algebra, the thing I'm interested in is the tensor products.) So I'm guessing there's a way of combining these to give a framework for (pseudo-)Riemannian geometry. But it'd only be a good framework for answering certain types of questions - in particular for things like numerical simulation. The important thing is that you'd be able to read off accurate numerical values of quantities like curvatures without any need for symbolic algebra. -- Dan ___ 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] Maybe and partial functions
This isn't just a question about Haskell. It applies to any language with an exception mechanism, including C++ and Java. Even C (segv is an exception mechanism...) The question is really how to communicate failure to the caller, in a way the caller can not ignore, without unduely inconvienencing the caller. So there is a two pronged test. Could the caller have anticipated the failure, and should the caller anticipate failure. head of an empty list is a good example of the first prong. It is easy to check for. In many cases it can be shown to be impossible. So burdoning all callers with dealing with failure explicitly is not good. An exception is good here. Contrast that with lookup in a table. The caller has no reasonable way of telling before hand that the call will be succesful. The caller should be prepared to handle lookup failure, so a Maybe is good here. In C++ a null value of some kind is the norm. One of the questions that C++ and Java answered was whether or not a caller should be forced to deal with an exception explicitly by the called function. The answer has turned out to be no, for somewhat different reasons in both languages. But it is something that Haskell should consider. Particularly Java library integrator's discovery that strongly typed exceptions do not scale. Frameworks like Tomcat seem to have found that there isn't much middle ground between exceptions that are handled close to the library, and just barely escape the library interface, and the generic 'something went wrong somewhere', 'abort,retry,fail?' kind of error. Of course, for library reuse, this is secondary to the incipient package nameing disaster. Not tertiary, since it is at the heart of lib composability On 3/12/07, Dougal Stanton [EMAIL PROTECTED] wrote: The Maybe construction is very useful for explicitly handling circumstances where the function cannot produce a sensible answer. But how far should this notion be taken? When you're writing a function which you realise may not produce what you want, in what circumstances would you use a Maybe, and when would you just throw an error? I'm wondering both in terms of good engineering practise and also for correctness. Should elementary partial functions like 5 `div` 0 or head [] return Nothing? I guess it's a bit of a silly suggestion, but it helps to highlight why we use Maybe in the first place. So --- where's the cutoff point in your code? Cheers, D. -- Dougal Stanton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: March 12, 2007
One of my editors at somepoint, told me that he had asked his lawyers about this (i.e. don't think this is anything like real legal advice), and the answer was 'If you publish an article and advise someone that the way to do something is X, no judge will be happy if you sue them for taking your advice. ' So my editors advice was, if you want to keep it a secret, don't publish. My take, if the code isn't published, it's advertising, not research. On 3/13/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote: ithika: Quoth Conrad Parker, nevermore, Besides, tshirtIf it's not open source, it's not computer science/tshirt. Science demands repeatable results, computer science demands literate programming. The solution is not to shy away from including code, or else the IP lawyers have won, science is banned and we get plunged into another Dark Age. I'm glad some people agree. I've been reading the reddit comments for that blog post with a mixture of car-crash fascination and horror, where the prevailing opinions are a mixture of: * computer scientists can't program, duh! * computer scientists aren't in academia for the advancement of knowledge, it's all about getting their name known * you just want to ride on the coat-tails of other people's brilliance; or, you're too lazy/stupid to do the work yourself * if you can't recreate it from the description in the paper then it shouldn't have been published The final point is the only one with any merit at all, and only then in an ideal world. High level papers are not simple to translate into code, even if the resulting code is quite simple. (How long did it take for the monad to make it into programming?) It's sad that there's such a prevailing culture of anti-intellectualism even in computer science/software engineering. So I'd like to take the opportunity to thank all the exciting academic work that gets published with code that I can read (even better when they are mixed in one literate document). And also all those contributors to The Monad Reader, who help to bridge that gap for the rest of us. I too read the comments with a sense of frustration. It is encouraging, somewhat, that in the original article, the Haskell paper-writing community was actually singled out as one that does tend to operate in an open source manner, and to actually produce code. Free the lambdas! -- Don ___ 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] Re: OO Design in Haskell Example (Draft)
The composite design pattern implemented using record types,
where the named elements are the interface to the object
Overall, I think I agree with Tim that the record types are simpler to code.
I'm not sure, though, what would happen if I tried to add state to the
types. With the previous example, using existentials to create a reference
type that holds elements of a type class that matches the interface, I think
that it would be natural to hold state by having that element stored in a
mutable state variable, and replacing the held values.
In any case:
Two methods, add and draw
data Component = Component {
draw :: String,
add :: Component - Component
}
A constructor for the leaf type, which holds a string
leaf :: String - Component
leaf s =
Component draw1 add1
where draw1 = show s
add1 _ = leaf s
the draw method for the composite type
(because I was having trouble with layout and formating for 72 cols)
compositeDraw :: [Component] - String
compositeDraw [] = ()
compositeDraw leaves = ( ++ (foldr1 (++) $ map draw leaves) ++ )
A constructor for the composite type, which holds a list of components
and dispatches to the contained elements
composite :: [Component] - Component
composite cs =
Component draw1 add1
where draw1 = compositeDraw cs
add1 c = composite $ c:cs
On 2/27/07, Tim Docker [EMAIL PROTECTED] wrote:
Steve Downey wrote:
interesting. it leads to something that feels much more like an object
based, as opposed to a class based, system.
as far as haskell is concerned, everything has the same type, even
though different instances have very different behavior.
the question is, which plays nicer with the rest of haskell? that is, if
i'm not committing to a closed dsl, which style is more likely to be
reusable against other libraries.
I suspect there's no right answer - it's a case of choosing the
best approach for the problem. As an example, my charting library
(http://dockerz.net/software/chart.html) uses the record of functions
approach for composing drawings:
data Renderable = Renderable {
minsize :: (Render RectSize)
render :: (Rect - Render ())
}
Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OO Design in Haskell Example (Draft)
interesting. it leads to something that feels much more like an object
based, as opposed to a class based, system.
as far as haskell is concerned, everything has the same type, even
though different instances have very different behavior.
instance variables are captured by the closures that define the object
methods, through the instance construction functions.
i get the feeling that a model like 'self''s , based on prototypes,
would not be that hard to implement.
i should have the equivalent example with this style done soon.
the question is, which plays nicer with the rest of haskell? that is,
if i'm not committing to a closed dsl, which style is more likely to
be reusable against other libraries.
my experience so far has been with parsers and type checkers that make
extensive use of pattern matching, which is why I probably gravitated
towards the type class with existentials solution. but my experience
is limited.
On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Tim Docker wrote:
Steve Downey wrote:
So, I've been working on a Composite example. I've used
existential types to have a generic proxy to the base
type, rather than a simple algebraic type, since adding
new leaves to the algebraic type means modifying the whole
type, a violation of the Open-Closed principle (open for
extension, closed for modification)
Rather than using existential types, a simple record of
functions can be often be useful. ie:
data Component = Component {
draw :: String
add :: Component - Component
}
It might be worth comparing this approach with the (more
complex) one you have described.
The point about existential types is that every class like IComponent
that allow as useful existential like
data Component =
forall e.(IComponent e) = Component e
can be put into the record form Tim mentions. See the old wiki pages at
http://haskell.org/hawiki/ExistentialTypes
This is because every such IComponent has to look like
class IComponent e where
foo1 :: e - ... - e
...
bar1 :: e - ...
...
where the dots in - ... must not contain the type variable e.
Regards,
apfelmus
___
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] Hi can u explain me how drop works in Haskell
in addition, a good example of how to apply quickcheck would be really awesome. without using the standard drop g On 2/26/07, Thomas Hartman [EMAIL PROTECTED] wrote: Here's my, probably very obvious, contribution. What I'd like feedback on is 1) code seem ok? (hope so!) 2) What do you think of the tests I did to verify that this behaves the way I want? Is there a better / more idiomatic way to do this? ** [EMAIL PROTECTED]:~/learning/haskell/lists$ cat drop.hs mydrop :: Int - [Int] - [Int] mydrop 0 xs = xs mydrop n xs = mydrop (n-1) (tail xs) main = test test = do print test1 print test2 print test3 test1 = mydrop 3 [1,2,3] == [] test2 = mydrop 2 [1,2,3] == [3] test3 = mydrop 0 [1,2,3] == [1,2,3] [EMAIL PROTECTED]:~/learning/haskell/lists$ runghc drop.hs True True True 2007/2/26, iliali16 [EMAIL PROTECTED]: Hi I am trying to implement the function drop in haskell the thing is that I I have been trying for some time and I came up with this code where I am trying to do recursion: drop :: Integer - [Integer] - [Integer] drop 0 (x:xs) = (x:xs) drop n (x:xs) |n lList (x:xs) = dropN (n-1) xs : |otherwise = [] So I want to understand how would this work and what exacttly should I put as an answer on line 4 couse that is where I am lost. I know I might got the base case wrong as well but I don't know what to think for it. I have done the lList as a function before writing this one. Thanks to those who can help me understand this. Thanks alot in advance! Have a nice day! -- View this message in context: http://www.nabble.com/Hi-can-u-explain-me-how-drop-works-in-Haskell-tf3290490.html#a9152251 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ 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] Hi can u explain me how drop works in Haskell
ok maybe i should have read ahead. but still, i can see how to apply hunit, but not quickcheck. but quickcheck seems more powerful. On 2/26/07, Steve Downey [EMAIL PROTECTED] wrote: in addition, a good example of how to apply quickcheck would be really awesome. without using the standard drop g On 2/26/07, Thomas Hartman [EMAIL PROTECTED] wrote: Here's my, probably very obvious, contribution. What I'd like feedback on is 1) code seem ok? (hope so!) 2) What do you think of the tests I did to verify that this behaves the way I want? Is there a better / more idiomatic way to do this? ** [EMAIL PROTECTED]:~/learning/haskell/lists$ cat drop.hs mydrop :: Int - [Int] - [Int] mydrop 0 xs = xs mydrop n xs = mydrop (n-1) (tail xs) main = test test = do print test1 print test2 print test3 test1 = mydrop 3 [1,2,3] == [] test2 = mydrop 2 [1,2,3] == [3] test3 = mydrop 0 [1,2,3] == [1,2,3] [EMAIL PROTECTED]:~/learning/haskell/lists$ runghc drop.hs True True True 2007/2/26, iliali16 [EMAIL PROTECTED]: Hi I am trying to implement the function drop in haskell the thing is that I I have been trying for some time and I came up with this code where I am trying to do recursion: drop :: Integer - [Integer] - [Integer] drop 0 (x:xs) = (x:xs) drop n (x:xs) |n lList (x:xs) = dropN (n-1) xs : |otherwise = [] So I want to understand how would this work and what exacttly should I put as an answer on line 4 couse that is where I am lost. I know I might got the base case wrong as well but I don't know what to think for it. I have done the lList as a function before writing this one. Thanks to those who can help me understand this. Thanks alot in advance! Have a nice day! -- View this message in context: http://www.nabble.com/Hi-can-u-explain-me-how-drop-works-in-Haskell-tf3290490.html#a9152251 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OO Design in Haskell Example (Draft)
I just started reading Haskell's overlooked object system. http://www.cwi.nl/%7Eralf/OOHaskell/ The survey of existing object encodings looks like a good place to start, although for several, where Either is used as a union type there are some rather obvious scaling problems. g If I've understood it, the OOHaskell library is meant to be a way of exploring OO in Haskell. Is it something that should be used by someone who wants to implement an OO design today? Or is it more for someone interested in research into the best way of doing OO in a functional context? I agree that there are a number of thorny OO issues, particularly that there really isn't a single OO model, rather a number of related models, practices and principles that are all lumped into the context of OO. Not to mention the tension between a model that revolves around mutable state against a system built on referential transparency. Mostly, I'd like to see better answers to questions like 'how do I do this' than here's something that will let you build something that lets you do that. I tend towards the engineering / reduction to practice side of things. Much as I like theory. And even if the answer is, there isn't really a best answer, but here are two or three reasonably good ways that won't cause too much trouble, and here's the kind of trouble they are likely to cause. On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Steve Downey wrote: In the last OO design in Haskell thread (and probably in every one preceeding it), it was suggested that having some examples might be a good idea. Since most people with existing designs will have some familiarity with Design Patterns, and those are typical building blocks for OO designs, it occured to me that implementing some of them might be a useful excersize. Have you looked at OOHaskell? http://homepages.cwi.nl/~ralf/OOHaskell/ http://darcs.haskell.org/OOHaskell/ With the exception of pure-functional objects and binary methods, I think we have considered almost every OO pattern/idiom we could find, including nominal/structural subtyping, co- and contra-variance, self-typing, etc. The DARCS repository contains the complete code for all of the examples and patterns. To clarify, the point of OOHaskell is to use Haskell as a tool, laboratory bench, for exploring various (thorny) OO issues. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OO Design in Haskell Example (Draft)
In the last OO design in Haskell thread (and probably in every one preceeding it), it was suggested that having some examples might be a good idea. Since most people with existing designs will have some familiarity with Design Patterns, and those are typical building blocks for OO designs, it occured to me that implementing some of them might be a useful excersize. If for nothing other than learning some more Haskell. Now, some of them are probably bad ideas for implementing in Haskell. There's a better, or more natural, way than what is suggested by the design pattern. Visitor is probably not a good pattern to follow, for example. On the other hand, others may still be useful, even in a functional language. So, I've been working on a Composite example. I've used existential types to have a generic proxy to the base type, rather than a simple algebraic type, since adding new leaves to the algebraic type means modifying the whole type, a violation of the Open-Closed principle (open for extension, closed for modification) The interface of the composite. Two methods, add and draw. class IComponent e where draw ::e - String add :: (IComponent e') = e - e' - Component A proxy type which can hold any kind of component, and provides the 'virtual' dispatch implementation. That is, it forwards to the add or draw implementation of the instance it is proxying for. data Component = forall e.(IComponent e) = Component e componentDraw :: Component - String componentDraw (Component c) = draw c componentAdd :: (IComponent e) = Component - e - Component componentAdd (Component e) a = Component (add e a) instance IComponent Component where draw = componentDraw add = componentAdd The Single type, which is the leaf node in this composite, add is a no-op, except for wrapping the value in a Component. Since there isn't an implicit down cast from the 'derived' Single to the 'base' Component. data Leaf = Text String deriving(Show, Eq) leafDraw :: Leaf - String leafDraw (Text s) = show s leafAdd :: (IComponent e) = Leaf - e - Component leafAdd s _ = Component s instance IComponent Leaf where draw = leafDraw add = leafAdd The Composite type, which holds a list of Components through the composite proxy. I was tempted to make the list a state variable, so that add could modify rather than produce a new Many, but I wanted to get the basics working. data Composite = Many [Component] compositeDraw :: Composite - String compositeDraw (Many []) = () compositeDraw (Many leaves) = ( ++ (foldr1 (++) $ map draw leaves) ++ ) compositeAdd :: (IComponent e) = Composite - e - Component compositeAdd (Many leaves) c = Component $ Many ((Component c) : leaves) instance IComponent Composite where draw = compositeDraw add = compositeAdd ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] currying vs partial application
I think I finally have it. Partial application is taking a function of N parameters, binding a value to one of them, and turning it into a function of N-1 parameters. Currying is where ask is that a function that takes two ints and returns an int, or is that a function that takes one int and returns a function that takes an int and returns an int, and the answer is yes. Currying implies partial application, but not all partial application is currying. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and the Future of Languages
The 70's and early 80's were very different in terms of information propagation. I really miss some the journals available back then, because the editors really did their jobs, both in selecting and helping to convey, information. OO did get oversold. The same way that putting it on the internet did at the beginning of this century (I love saying that, now, where's my flying car) but just like many of the good principles of structured programming inform OO, it should be possible to take good OO and apply it functionally. On 1/30/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Steve, Friday, January 26, 2007, 10:03:09 PM, you wrote: Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't ... The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, i don't think so :) imho, we just don't have good _teachers_. in 70's, OOP audience was also small, but it was popularized later and now every student know about polymorphism via inheritance. but most of OOP programmers don't reinvent the wheels, they just use patterns described in OOP bestselling books i have a positive experience of making complex concepts easy and available for wide audience ([1]-[5]), [1] was even used to teach students in some college. and i guess that good Haskell books, such as yaht and printed ones, also make it easy to learn Haskell. but we need to gather much more attention to Haskell to make it as patternized as structured-programming and OOP. _nowadays_ there is no even one advanced Haskell or Haskell in Real World book and this means that anyone who want to learn Haskell in deep should study those terrible papers (well, it's very like higher education in Russia - no one really teaches you at our colleges so you should either learn yourself or die :) but this means that at least whose who still alive, are Real Machos :) the same apply to Haskell - now the only way to learn it is to learn yourself, so we all definitely are cool mans. once i even got C# job offer only because i know Haskell :) [1] http://haskell.org/haskellwiki/IO_inside http://haskell.org/haskellwiki/OOP_vs_type_classes http://haskell.org/haskellwiki/Modern_array_libraries http://haskell.org/bz/th3.htm http://haskell.org/bz/thdoc.htm -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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] State of OOP in Haskell
The primary goal of writing source code isn't to communicate to a computer, but to communicate to a human being. That implies that the communication should be at a high enough level of abstraction to be easily understood by people, while not losing the precision necessary for a computer. OO, at least when done well, maps well to how people think. Things that can be directed to perform actions. There is also a well developed practice of OO analysis and design. It's not clear (at least to me) that there is an equivalent set of practices for functional programming. It did take more than a decade for the industry to move from structured analysis and design to OO, even when it was obvious to most practioners that there was a horrible mismatch, and the models coming out of analysis didn't apply. The consensus answer to 'how do I implement my OO model in Haskell' seems to be 'you're asking the wrong question'. But what is the right question? On 1/28/07, Frederick Ross [EMAIL PROTECTED] wrote: I'm going to be offensive, bigoted, and myopic for a minute here: programming straight onto the Turing machine (and not too dissimilarly, the von Neumann machine) is the act of making your thoughts comprehensible to a little gizmo that exists to zip back and forth on an infinite ticker tape. We should therefore abstract. However, I am only marginally happier about making my thoughts comprehensible to a tinkertoy set (which is how I regard object oriented programming). Why not just stay as close to mathematics as possible? Why the deep desire to communicate your loftiest intentions to a tinkertoy set? There was the Lambada project to map between Java's object hierarchies and Haskell, however, and there was a lot of effort put into making Haskell talk properly through COM. Both of those necessitate a model of object oriented programming embedded in Haskell which would provide you with prior art. On 1/27/07, Alexy Khrabrov [EMAIL PROTECTED] wrote: ...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? -- Frederick Ross Graduate Fellow, (|Siggia + |McKinney)/sqrt(2) Lab The Rockefeller University Je ne suis pas Fred Cross! ___ 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] OOP parametric polymorphism
Well, it depends what you mean by OO. In a proper OO system, equality
means not just are these two things in the same state, but do they
refer to a single object. Invoking behavior on one will affect the
other, and the equality relation will still hold.
There are three properties that entities have in a OO model:
1 Identity
2 State
3 Behavior
objects are not values. Values don't have identity. This 7 is the same
as that 7, with no way of distinguishing them. They also don't have
state.You don't add 1 to 7 and turn it into 8 (unless you're in a very
old FORTRAN, where constants weren't). The result is a new value.
Values also don't do things. Functions map values to new values.
Of course, when most people are looking for OO, they're looking for
encapsulation, subtyping, inheritance, polymorphism, dynamic dispatch
and so on. Many of those are dead simple in Haskell. Others less so.
Unfortunately, it seems that most people trying to get these answers
are also trying to apply a design that is suboptimal for the language.
By the way, equality is a particularly nasty example given subtyping.
There is no good way to define equality that is fully polymorphic that
is also transitive and reflexive. Which is annoying no end.
On 1/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Donald Bruce Stewart wrote:
deliverable:
...In the tradition of the letters of an ignorant newbie...
What's the consensus on the OOP in Haskell *now*? There're some
libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified
type system with inheritance.
If I have GHC, which way to do anything OOP-like is considered right
today?
Using existentials and typeclasses to do some OO things wouldn't be
considered unidiomatic (particularly, using existentials to package up
interfaces to values).
In general though, using a functional approach will produce better
(simpler) Haskell code, and make it more likely others will understand it.
Personally, I run in fear from OO Haskell ;)
Instead of OOP, Haskell uses (parametric) polymorphism which is more
powerful than OOP. For instance, the function
length :: [a] - Int
or, with an explicit forall
length :: forall a . [a] - Int
counts the number of elements in a list [a], regardless of what type
a those elements have. Moreover, it is guaranteed that length does
not inspect or change the elements, because it must work for all types
a the same way (this is called parametricity). Another example is
map :: (a - b) - [a] - [b]
which maps a function over all elements in the list.
In addition, Haskell has type classes (which are similar to interfaces
in OOP). The most basic example is
class Eq a where
(==) :: a - a - Bool
Thus, you have an equality test available on all types that are
instances of this class. For example, you can test whether two Strings
are equal, because String is an instance of Eq. More generally, you say
whether two lists are equal if you know how to test elements for equality:
instance Eq a = Eq [a] where
[] == [] = True
(x:xs) == (y:ys) = (x == y) (xs == ys)
_ == _ = False
The important thing I want to point out in this post is that parametric
polymorphism is indeed more powerful than OOP: already a concept like Eq
is impossible to implement in OOP. The problem is best illustrated with
the class Ord (*), which provides an ordering relation. Let's
concentrate on the smaller than function
() :: Ord a = a - a - Bool
Can I create an interface that expresses the same thing?
public interface Comparable {
boolean smaller_than(?? y);
}
No, because there is no type I can attribute to the second argument of
smaller_than. The problem is that I can only compare to values of the
*same* type, i.e. the type which implements the interface.
Can I create a class the expresses the same thing?
public class Comparable {
boolean smaller_than(Comparable y);
}
This seems like a solution, but it is not. The problem is subtyping: if
i make integers and strings members of this class, i would be able to
compare the number 1 against the string hello, which should be
reported as a type error.
I have no formal proof, but I think that the function cannot be
expressed in a type correct way in OOP. AFAIK, only Java Generics can
express the requirement we want:
interface OrdA {
boolean smaller_than(A x, A y);
}
class String implements OrdString { ... }
But Generics are a considerable extension to OOP. In fact, there is
nothing really object oriented in here anymore, we're just on our way to
parametric polymorphism.
My final remark is about what this means for the existential quantifier
in Haskell. Because of the injection
inject :: forall a . a - (exists a . a)
the existential quantifier can be thought of as implementing some form
of subtyping, i.e. (exists a . a) is a supertype of every a. The point
now is: given
type ExistsOrd = exists a . Ord a =
[Haskell-cafe] Re: small step evaluation as an unfold?
good, it felt like something that might have occurred to someone before. On 1/23/07, Nicolas Frisby [EMAIL PROTECTED] wrote: Jeremy Gibbons thought of it; that's good company ;) http://portal.acm.org/citation.cfm?id=289457 On 1/23/07, Steve Downey [EMAIL PROTECTED] wrote: (overall context - working through TaPL on my own, reimplemnting typecheckers in haskell) the type checkers all follow the same pattern, in ocaml they throw an exception when the small step fails, which may mean taking another branch in the eval, but that that sub expression has hit bottom. it is self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. or am i insane / intoxicated ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: small step evaluation as an unfold?
I'll take a look at that, since one of the next things on my list is error propagation and reporting. In Pierce's code, source information is carried through as an explict part of the type that represents terms in the language. I think that would be more naturally expressed in a monad transformer, so that the concerns of expression and type evaluation are separated from error reporting. But best to leave the next problem for next. It was actually the discussion here about ListT being equivalent to a pair of a and a Maybe of the type. So that [] is equivalent to Nothing. Which have always seemed related, but I wasn't sure how. Seeing that, though made me realize that expressing the evaluation as an unfold, with the term I'm currently returning as the last element, might make other compositions easier to write, and to follow the chain of deductions being made. Now I just have to write it. On 1/23/07, John Meacham [EMAIL PROTECTED] wrote: On Tue, Jan 23, 2007 at 10:25:27PM -0500, Steve Downey wrote: (overall context - working through TaPL on my own, reimplemnting typecheckers in haskell) the type checkers all follow the same pattern, in ocaml they throw an exception when the small step fails, which may mean taking another branch in the eval, but that that sub expression has hit bottom. it is self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. you would probably be interested in the helium type checker, which is designed to give excellent error messages above all else. Basically, what it does (up to my understanding) is perform a standard type-inference traversal of your code, but rather than unify things as it comes to them, it collects a set of constraints of what to unify with what. then, once they are all collected, it can use a variety of constraint solving techniques, whichever produces the best messages. it even allows users to annotate their routines with specialized constraint solving strategies and type error messages. it is really quite neat. http://www.cs.uu.nl/helium/documentation.html John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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] small step evaluation as an unfold?
(overall context - working through TaPL on my own, reimplemnting typecheckers in haskell) the type checkers all follow the same pattern, in ocaml they throw an exception when the small step fails, which may mean taking another branch in the eval, but that that sub expression has hit bottom. it is self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. or am i insane / intoxicated ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
One nit and one massive praise. nit first. in 'the monad laws and their importance' you say given a monad M and then outline the laws a functor must satisfy to be a monad. I would find it clearer to say 'a functor M', and then emphasise the iff relationship between the laws and the functor M. the praise: footnote 3. the relationship between join and bind is why monads are useful and interesting for programmers. i haven't seen it stated more clearly before. i supose because people who know it assume it. suggestion: don't bury this in a footnote. On 1/16/07, David House [EMAIL PROTECTED] wrote: Hey all, I've written a chapter for the Wikibook that attempts to teach some basic Category Theory in a Haskell hacker-friendly fashion. http://en.wikibooks.org/wiki/Haskell/Category_theory From the article's introduction: This article attempts to give an overview of category theory, insofar as it applies to Haskell. To this end, Haskell code will be given alongside the mathematical definitions. Absolute rigour is not followed; in its place, we seek to give the reader an intuitive feel for what the concepts of category theory are and how they relate to Haskell. I'd love comments from newcomers and experts alike regarding my approach, the content, improvements and so on. Of course, it's on the wikibook, so if you have anything to add (that's not _too_ substantial otherwise I'd recommend discussion first) then go ahead. Thanks in advance. -- -David House, [EMAIL PROTECTED] ___ 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] State monad strictness - how?
haskell is the standard lazy functional language, so strictness ought to be called out. e.g. StateStrict rather than StateLazy. The traction that haskell is starting to get (and why I'm spending time learning it and following haskell-cafe) is not because its semantics are unsurprising to newbies. They are surprising and surprisingly powerful. A haskell that did no more than scheme would not be as interesting. I may be subject to selection bias, but I haven't seen so many references to a language in unexpected contexts since smalltalk in the mid 80's. I don't think that's because it's a language that behaves the way someone coming from another language expects. On 1/10/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Yitzchak, Wednesday, January 10, 2007, 12:02:25 PM, you wrote: Unfortunately, the current situation is that State is only available as a lazy monad, and StateT is only available as a strict monad. At the very least, the two should be consistent. I would much prefer for them both to be lazy. imho, lazy monads (as any other lazy things) is a source of beginner's confusion. therefore it may be better to provide default monads as strict and lazy ones - for one who knows what he wants - with a Lazy prefix, e.g. LazyST, LazyState... -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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] partial functions / failure, Maybe and MonadError and good style
Although terse, the subject really says it all. If i've a partial function, like a parser, what is considered good style for a library. The tradeoffs that I can see are that Maybe is a binary operation, while Error can communicate more information in the type of the error case. Is there some way to defer the error handling Monad to the calling context? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: partial functions / failure, Maybe and MonadError and good style
OK, but is msg always a string? Admidtedly, in the concrete case I have at hand (follow up posting RSN), that would be fine. I think I've also been looking at the map lookup case, where not only is lookup failure to be expected, it's almost an imposition to say something other than Nothing. On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote: On Fri, Dec 22, 2006 at 08:05:08PM -0500, Steve Downey wrote: Although terse, the subject really says it all. If i've a partial function, like a parser, what is considered good style for a library. The tradeoffs that I can see are that Maybe is a binary operation, while Error can communicate more information in the type of the error case. Is there some way to defer the error handling Monad to the calling context? Your title answers the question. :) All monads provide a fail operation, and any function that uses fail will be able to work with any monad's error handling mechanism. * Maybe - fail msg is Nothing (ignores the message) * Either str - fail msg is Left msg (stores the message) * IO - fail msg is ioError (userError msg) (throws message as exception) For instance, Data.Map.minView is Monad m = Set a - m (Set a, a); so.. minView :: Set a - Maybe (Set a, a) -- gives Nothing on empty set minView :: Set a - [(Set a, a)] -- gives [] on empty set minView :: Set a - IO (Set a, a) -- throws an ioError on empty set ... (note that the behaivor of lookup et al, which are specific to Maybe, is considered outdated style) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: partial functions / failure, Maybe and MonadError and good style
'normal execution path' is a key phrase here. If we're truely thinking functionally, there is no execution path. At most there are evaluation strategies. I suppose this is why Maybe is a monad rather than just another algebraic data type. Perhaps I'm thinking of the strategy of 'replacing failures by a list of sucesses' where an empty list is possible. This is exactly where I'm stuck. I've an eval1 function of ArithExpr - m ArithExpr, where m started out as Maybe. Now only the calling eval function mentions Maybe. And I was wondering if I could keep eval1 generic. OTOH, eval1 should really pass through information from the underlying parser... Really RSN. When me, my laptop, and my wireless connection all meet at the same time. On 12/22/06, Ross Paterson [EMAIL PROTECTED] wrote: On Fri, Dec 22, 2006 at 08:37:05PM -0500, Steve Downey wrote: On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote: All monads provide a fail operation, and any function that uses fail will be able to work with any monad's error handling mechanism. * Maybe - fail msg is Nothing (ignores the message) * Either str - fail msg is Left msg (stores the message) * IO - fail msg is ioError (userError msg) (throws message as exception) OK, but is msg always a string? You've hit the nail on the head. The fail method is a kludge that works if the error is just a string (in English, of course), but often it isn't. For instance, Data.Map.minView is Monad m = Set a - m (Set a, a); so.. minView :: Set a - Maybe (Set a, a) -- gives Nothing on empty set minView :: Set a - [(Set a, a)] -- gives [] on empty set minView :: Set a - IO (Set a, a) -- throws an ioError on empty set ... (note that the behavior of lookup et al, which are specific to Maybe, is considered outdated style) I feel a bit queasy about this. With the old Maybe type of minView, it really was a view: the empty case was an element of the data type, not an error. You could pattern match on it, and the empty case would often be perfectly normal. Of course you can still do that, because the old type is a special case that's still available, but the change of perspective gives the wrong impression, I think. It feels wrong to use failure as a normal execution path. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: partial functions / failure, Maybe and MonadError and good style
Actually, that is the version of Error I was looking at. On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote: On Sat, Dec 23, 2006 at 02:33:51AM +0100, Lennart Augustsson wrote: I would not advocate using the fail operation in a monad. It doesn't belong there, and hopefully it will go away some day. :) On Fri, Dec 22, 2006 at 08:37:05PM -0500, Steve Downey wrote: OK, but is msg always a string? Admidtedly, in the concrete case I have at hand (follow up posting RSN), that would be fine. I think I've also been looking at the map lookup case, where not only is lookup failure to be expected, it's almost an imposition to say something other than Nothing. There is a more general form of monads that support failure, Control.Monad.Error.MonadError in the extended standard libraries; throwError noMsg:: (Error e, MonadError e m) = m a throwError . strMsg :: (Error e, MonadError e m) = String - m a Error is any type that strings can be mapped into (I'm not talking about an injection, I just can't find a better word), such as String and IOError. Unfortunately there does not seem to be a standard instance for Maybe... -- This isn't in the standard library, and thus I conjecture that it -- is seriously flawed in a way I haven't noticed. instance Error () where noMsg = () ; strMsg _ = () instance MonadError () Maybe where throwError _ = Nothing Just x `catchError` f = Just x Nothing `catchError` f = f () ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskel-cafe] Re: what are the points in pointsfree?
I spent time working with cubic mappings. With two critical points, there are Julia sets that consist of infinitely many disconnected components that are still locally connected, corresponding two one critical point escaping and one falling into one of the basins of attraction. Of course that was about 15 years ago, and I haven't really kept up. Too much time keeping up with software. On 12/16/06, Jacques Carette [EMAIL PROTECTED] wrote: Steve Downey wrote: No fair. Although I've a B.S. in Mathematics, I spent most of my time in complex analytic dynamical systems, rather than hanging with the algebraists. Except for a bit where I did some graph theory. Never thought I'd run into a fellow dynamicist on haskell-cafe! I did my PhD on the links between the geometry and dynamics of Julia sets (co supervised by the (late) Adrien Douady and John Hubbard). What 'flavour' of this stuff are you interested in? Jacques PS: now I have converted to being a computer scientist, which is why I hang out on haskell-cafe! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
The front end for the comeau compiler is from Edison Design Group, and that's the one that is used by many other compilers. And the EDG compiler is regarded as being the most conformant. Besides MS and the FSF (visual c++ and gcc), both Sun and IBM have c++ compiler toolchains not based on EDG. If they were, my life would be much simpler. The late additions of the STL, and some concommitant changes to how templates worked, really caused a lot of the difficulties in implementation. That, and the installed base problem. Having version N of a language change the meaning of programs targetting version N-1 tends to upset users. The STL, however, brings a very applicative programming model into an otherwise imperative language. And, it turns out that the template language is a turing complete pure functional language, making possible some very interesting type based metaprogramming. Of course, since it wasn't really designed as such, it has to be heavily sugared to be useful. On 12/14/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Tomasz, Thursday, December 14, 2006, 11:32:33 PM, you wrote: complete compilers. Two years ago the only full compiler for C++ was Comeau, probably unknown to most C++ programmers. I am not sure about today, but I wouldn't bet that things improved. just because they don't know what sits at back of their compiler? :) someone tells me, that only 2.5 front-ends remain - comeau, gcc and probably MS. all other compilers use comeau, which is not full compiler but just front-end there is old joke that camel is a horse created by committee. Algol-68, Pl/1, Ada and now C++ becomes such large languages that no one can master them in full details -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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] Aim Of Haskell
The core of the 'Blub Paradox'. There is almost no upside for a manager to approve an 'unusual' language for a project. Most technology changes are driven by engineers, and most engineers are by nature risk averse, even though they also tend to be neophiles. So, on a given project, they'll try one, maybe two new things, but ones they think have a high chance of sucess. Smart managers let these bets be made, because a technology advantage is often a force multiplier. Now, engineers have to decide where to spend their intellectual capital and the markers they can call in from management. Haskell seems to be a good place to spend intellectual capital. There certainly seems to be some growing consensus that functional programming approaches are the next 'big thing'. Multicore and true concurrency seem to demand a new approach. The question in my mind is, is Haskell the Smalltalk of the '10s or the Java? Either way, I already believe that it's worthwhile learning. As to libraries, they seem to be the natural result of engineers learning new languages. And because of the internet and open source, you get a positive feedback cycle. The Jakarta project is the best recent example. Almost overnight, java became the defacto serverside language. A niche almost opposite where the language was being pitched. So what can Haskell do better enough that the feedback cycle can be jumpstarted? On 12/15/06, Joachim Durchholz [EMAIL PROTECTED] wrote: Tomasz Zielonka schrieb: On Thu, Dec 14, 2006 at 09:56:57PM +0100, Joachim Durchholz wrote: OK, there's the option of replacing working tools with hype. It worked for C++, and it worked for Java. Pity I don't have the slightest idea how to work up a hype for Haskell. Who would want such a hype? Why not simply start picking up fruits before the mainstream notices? ;-) Because a mainstream language has more tools, more libraries, and an easier job search. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: what are the points in pointsfree?
No fair. Although I've a B.S. in Mathematics, I spent most of my time in complex analytic dynamical systems, rather than hanging with the algebraists. Except for a bit where I did some graph theory. Rather ironic. On 12/15/06, Scott Brickner [EMAIL PROTECTED] wrote: Donald Bruce Stewart wrote: sdowney: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? The wiki knows all! :) http://haskell.org/haskellwiki/Pointfree 1 But pointfree has more points! A common misconception is that the 'points' of pointfree style are the (.) operator (function composition, as an ASCII symbol), which uses the same identifier as the decimal point. This is wrong. The term originated in topology, a branch of mathematics which works with spaces composed of points, and functions between those spaces. So a 'points-free' definition of a function is one which does not explicitly mention the points (values) of the space on which the function acts. In Haskell, our 'space' is some type, and 'points' are values. Hm. I've been lurking for a while, and this might be a bit of nit-picking as my first post, especially given I'm still a bit of a n00b in Haskell. I've been programming a long time, though - coming up on three decades now and virtually all of it really programming, no management. Anyway, as I understood it, the points were the terminal objects of the category in which you're working - in this case, pointed continuous partial orders (CPO), and the points are effectively values in the domain. The usage of point for terminal objects comes from the category of topological spaces, as you say,. and algebraic topology is where category theory found it's first big home - but that's not really what we're talking about here, is it? Category theory got the term from topology, which got it from geometry. So you could say point is position without dimension - but that's just not the point we're talking about anymore. So, the usage of point here refers a terminal object in the CPO category, which means a value of some datatype - in this particular case, a value in the domain of the function being defined. So when you give a definition that uses patterns for the parameters, the variables in the patterns get bound to the values in the domain of the function. If you write the function in a higher-order style, where you don't bind the values, your definition doesn't refer to the point at which it's being evaluated, hence point-free. -- - What part of ph'nglui bglw'nafh Cthulhu R'lyeh wagn'nagl fhtagn don't you understand? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] what are the points in pointsfree?
i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: what are the points in pointsfree?
the wiki wasn't half as clear. other tham covering the first half, that it doesn't mean the '.' function. so pointsfree is a step beyond leaving the domain unspecified. my reading knowledge of haskell at this point far exceeds my ability to write haskell. but so far, it has seemed to me that functions written in the pf style are the most reuseable. from what you just told me, it's not an artifact of the pf style, but that maximally reusable functions will be expressible in a pointsfree style. that those functions embody a pattern of computation, without concern for the details. On 12/14/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: sdowney: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? The wiki knows all! :) http://haskell.org/haskellwiki/Pointfree 1 But pointfree has more points! A common misconception is that the 'points' of pointfree style are the (.) operator (function composition, as an ASCII symbol), which uses the same identifier as the decimal point. This is wrong. The term originated in topology, a branch of mathematics which works with spaces composed of points, and functions between those spaces. So a 'points-free' definition of a function is one which does not explicitly mention the points (values) of the space on which the function acts. In Haskell, our 'space' is some type, and 'points' are values. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reversing a string of words: C# v Perl V Ruby v Haskell
ok, i'll bite. why should i prefer join rather than concat in the list monad. and, moreover, why is this a lambdabot trick? i suspect that the answer actually has a deep connection to the 'dummies' thread next door. while any program that produces the right result is correct, there are some that are more correct than others. a good introductory guide to haskell should lead you in that direction. reasoning by analogy, for c++, andy koenig's accelerated c++ had a huge impact on teaching c++ because it didn't start with C or pidgen c++, but instead required the student to accept that many mechanisms would be explained later, but that they should be used -now-. i suspect that being biased towards higher order functions, and writing new functions such that monads (although the more i learn i think that should be typeclasses) can take advantage of those functions, is the skill that needs to be learned / taught. the equivalent of the central dogma of OO, where it's all about objects having identity, state , and behavior. On 12/13/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: ulfn: On Dec 13, 2006, at 3:54 AM, Yitz Gale wrote: Nice. Here is something similar: reverseWords = concat . reverse . groupBy eqsp where eqsp x y = isSpace x == isSpace y This can be made even nicer using the 'on' function [1]: reverseWords = concat . reverse . groupBy ((==) `on` isSpace) [1] http://www.haskell.org/pipermail/libraries/2006-November/006156.html Lambdabot trick(tm), use 'join' in the [] monad, instead of 'concat' join . reverse . groupBy ((==) `on` isSpace) -- Don ___ 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] Aim Of Haskell
well, if Sun hadn't have released a version of smalltalk with a funny c like syntax, you might have seen some interesting developments in the mid 90's On 12/13/06, Claus Reinke [EMAIL PROTECTED] wrote: The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation .. shouldn't we make this used to be academic-centric? People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. .. although just beginning to notice may be accurate on a historical scale, I have the feeling that the actual development is further along than this. at least, there have been sufficiently many and active early adopters for long enough to make a substantial difference. so those practical questions are not being raised, but several of them are actually being addressed. It had to happen in a grassroots fashion, and IMO it couldn't have happened until after the rise of distributed open-source development (which, I remind you, didn't start gaining a lot of momentum until not that long ago). one of the most exciting aspects of Haskell is that pragmatic interest in the language has been growing steadily without academic interest in it declining in any way. as a result, we have a language that represents an interesting mixture of good and useful, although it is not entirely clear yet how long this nice balance will hold. we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? claus ___ 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] Reversing a string of words: C# v Perl V Ruby v Haskell
the typical good solution to this problem in c or c++ is to use a string reverse function on the entire buffer, then re-reverse each word. this leaves multiple spaces correctly embedded in the larger string. that approach, of course, won't work in haskell, since it relies on updates. but if the challenge includes transforming one two three four into four three two one, how could this be done? On 12/10/06, Neil Mitchell [EMAIL PROTECTED] wrote: Hi However, every response to this question I've seen (admittedly only three or four so far) used StringBuilder. When I ask, why not use Join? most C# programmers seem to respond that StringBuilder is faster (I haven't measured the difference in performance). I don't know, but I'd be really surprised if Join wasn't implemented in terms of StringBuilder at worst. Possibly it does a summation of the lengths of the String's in the list, and does exactly one allocation, making it much more efficient. Either way, if there is a function in the libraries, you shouldn't be able to write one which is faster! I suspect people saying use StringBuilder have read an article on a website telling them that String concat is slow - but haven't thought about the implications... Thanks Neil ___ 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] Eval of a syntax tree for reduction
I'm working through Pierce's Types and Programming Languages on my own. I'm attempting to write the typecheckers in Haskell, instead of ML. However, when it comes to his eval function, I'm a little stuck. The original is
let rec eval t = try let t' = eval1 t in eval t' with NoRuleApplies - tWhere eval1 is a single step evaluation of the abstract syntax tree, and NoRuleApplies is an exception that's raised if there are no rules that can reduce the _expression_. Now, there's a footnote that it isn't good style in ML. It seems even less natural in Haskell, at least to me, but I still don't know the language that well.
The natural equivalent to what Pierce has in ML is something along the lines ofdata ArithExpr = TmTrue | TmFalse | TmIfExpr ArithExpr ArithExpr ArithExpr | TmZero | TmSucc ArithExpr
| TmPred ArithExpr | TmIsZero ArithExpr deriving (Show, Eq)eval1 :: ArithExpr - ArithExpreval1 (TmIfExpr TmTrue t _) = teval1 (TmIfExpr TmFalse _ t) = teval1 (TmIfExpr t1 t2 t3) =
let t1' = eval1 t1 in TmIfExpr t1' t2 t3-- and so onBut, how to terminate the recursion in the full eval?I'm considering changing eval1 to be ArithExpr-Maybe ArithExprIf the _expression_ is reducible, then I return Just t, and if it's not reducible, then Nothing
It makes eval1 a bit more complicated, and not as straightforward translation from the type system being described, though.e.g reducing If looks more likeeval1 (TmIfExpr t1 t2 t3) = let t1' = eval1 t1
in case t1' of { Just t1'' - Just $ TmIfExpr t1'' t2 t3 ; Nothing - Nothing }and eval then looks likeeval t = let t' = eval1 t in case t' of
{ Just t'' - eval t'' ; Nothing - t' }I'm looking for some suggestions on the direction to proceed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
