[Haskell-cafe] Re: What do _you_ want to see in FGL?
Ivan Miljenovic wrote:
Heinrich Apfelmus wrote:
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly; but if the integers are actually indexes, then
it's conceptually cleaner to make them abstract, i.e.
data Node -- constructors are not exported
and provide combinators to operate on these abstract indexes, including
a corresponding Data.Graph.Inductive.NodeMap module.
I'd like to see such an abstract Node type, because then the library
will provide all operations I need. It took me some time to figure out
how to best use Int as indexes in my example code; an abstract Node
type and a good NodeMap module would have made my life much easier.
I'm not sure I understand what you're saying here: first you said you
wanted to be able to specify a vertex type, now you're saying that you
don't want to know what the vertex type even is (except that it's some
abstract Node type)? Whilst this would make graph usage safer/more
robust, this seems to contradict your earlier arguments...
I'd be happy with either one. :) In both cases, I want to specify a
custom vertex type.
I can either do that directly if the library permits, though I think the
solution with associated types is too cumbersome to be useful for my
make example.
Or I get an abstract Node type and the library provides just the right
functions that make it easy to manage a custom vertex type myself. I had
hoped that the Data.Graph.Inductive.NodeMap module provides this,
which it doesn't.
In other words, the abstractness of Node forces the library to provide
a well-designed set of functions to work with them, and that's what I'm
after. In my make example, I spent the most time thinking about how to
manage the Int nodes, finally settling with Data.Map.findIndex , and
I prefer the library to think about that for me.
Darn, I meant
data Graph node a b =
Graph { internal :: Graph Int a b, nodes :: Map Int a }
The idea is to use Ints internally and only store a loose association
to the custom vertex type. In particular, no Map a Int is required,
only from Int to a . Now, I realize that the other way round is
required as well for querying the context of a node in a graph.
What's the point of that useless node type parameter then? And how
does the nodes map differ from just getting the graph label?
You're right, I now realize that this design doesn't work. But you asked
for wishes, so I wished for something. ;)
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Good US Grad schools for functional languages?
I'd also think of Harvard (Morrisset), Tufts (Ramsey), Portland State (Jones, Sheard), Yale (Hudak), North Eastern (Wand, Felleisen, Shivers), Utah (Flatt), Chicago (Reppy, MacQueen), North Western (Findler). Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Job Vranish Sent: 13 May 2010 18:41 To: Haskell Cafe mailing list Subject: [Haskell-cafe] Good US Grad schools for functional languages? Anybody know of a good grad school in the US for functional languages? (good = has Ph.D. program that covers functional languages, type systems, correctness proofs, etc...) So far Indiana University is the only one I've found that has a strong showing in this area. A way to get into one of the awesome UK schools for free would work too :D - Job ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
Heinrich Apfelmus apfel...@quantentunnel.de writes: I'd be happy with either one. :) In both cases, I want to specify a custom vertex type. Except an abstract type isn't a custom vertex type... I can either do that directly if the library permits, though I think the solution with associated types is too cumbersome to be useful for my make example. Why? Or I get an abstract Node type and the library provides just the right functions that make it easy to manage a custom vertex type myself. I had hoped that the Data.Graph.Inductive.NodeMap module provides this, which it doesn't. Not sure I follow what you're saying here; then again, my graph stuff has typically been to create the graph and then do stuff to it _as_ a graph (and not wanting/needing to get a specific node based upon its label, etc.). You're right, I now realize that this design doesn't work. But you asked for wishes, so I wished for something. ;) Heh, fair enough, except I didn't ask for wishes, just what people would like to see ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
Heinrich Apfelmus schrieb: Ivan Miljenovic wrote: I'm not sure I understand what you're saying here: first you said you wanted to be able to specify a vertex type, now you're saying that you don't want to know what the vertex type even is (except that it's some abstract Node type)? Whilst this would make graph usage safer/more robust, this seems to contradict your earlier arguments... I'd be happy with either one. :) In both cases, I want to specify a custom vertex type. I can either do that directly if the library permits, though I think the solution with associated types is too cumbersome to be useful for my make example. Or I get an abstract Node type and the library provides just the right functions that make it easy to manage a custom vertex type myself. I had hoped that the Data.Graph.Inductive.NodeMap module provides this, which it doesn't. In other words, the abstractness of Node forces the library to provide a well-designed set of functions to work with them, and that's what I'm after. In my make example, I spent the most time thinking about how to manage the Int nodes, finally settling with Data.Map.findIndex , and I prefer the library to think about that for me. Full acknowledge! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
Henning Thielemann schlepp...@henning-thielemann.de writes: Heinrich Apfelmus schrieb: Ivan Miljenovic wrote: I'm not sure I understand what you're saying here: first you said you wanted to be able to specify a vertex type, now you're saying that you don't want to know what the vertex type even is (except that it's some abstract Node type)? Whilst this would make graph usage safer/more robust, this seems to contradict your earlier arguments... I'd be happy with either one. :) In both cases, I want to specify a custom vertex type. I can either do that directly if the library permits, though I think the solution with associated types is too cumbersome to be useful for my make example. Or I get an abstract Node type and the library provides just the right functions that make it easy to manage a custom vertex type myself. I had hoped that the Data.Graph.Inductive.NodeMap module provides this, which it doesn't. In other words, the abstractness of Node forces the library to provide a well-designed set of functions to work with them, and that's what I'm after. In my make example, I spent the most time thinking about how to manage the Int nodes, finally settling with Data.Map.findIndex , and I prefer the library to think about that for me. Full acknowledge! I have no idea what this is meant to mean... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is TChan GHC specific?
On 14 May 2010 00:10, Derek Elkins derek.a.elk...@gmail.com wrote: On Thu, May 13, 2010 at 10:49 AM, Edward Amsden eca7...@cs.rit.edu wrote: On Wed, May 12, 2010 at 3:29 PM, Peter Robinson thaldy...@gmail.com wrote: As far as I know, TChan needs the 'retry' combinator which requires GHC's RTS. Same is true for TMVar, I think. (sorry for the doubling peter, I forgot reply-all) OK. I'm new to this and probably didn't know where to look, but I didn't know that 'retry' was GHC specific. All of STM (Software Transactional Memory) is GHC-specific. That's technically true for the real STM implementation, but the stm package also contains the module 'Control.Sequential.STM' that provides a sequential implementation which will work even without GHC's runtime. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Mon, 10 May 2010, Max Cantor wrote: Based on some discussions in #haskell, it seemed to be a consensus that using a modified continuation monad for Error handling instead of Eithers would be a significant optimization since it would eliminate a lot of conditional branching (everytime = is called in the Either monad, there is a conditional. I assumed that GHC also has optimizations for conditional branching. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: tweak vacuum-* output
Ozgur Akgun wrote: In this case I think you should either make it a separate package, or don't hide it in this module. It looks like an easy way to call Ubigraph from Hhaskell, and there is no apparent alternative (in hackage) so why hide it? I've contacted Kohei Ozaki, the author of Hubigraph, about the latter being uploaded to Hackage, and got the positive response. I'm updating vacuum-hubigraph package now, hope to upload the new version soon. Regards, Gleb. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: tweak vacuum-* output
The new version (0.2.0.1) is on Hackage.
vacuum-ubigraph now depends on Hubigraph, basic customization is now
possible, e.g.:
import System.Vacuum.Ubigraph
import Graphics.Ubigraph
myNodeStyle n = map (setColor #ff) $ defaultNodeStyle n
where
setColor color (VColor _) = VColor color
setColor _ s = s
myview = customView (defaultOptions { nodeStyle = myNodeStyle })
defaultServer
main = myview $ cycle [1..5]
Any feedback appreciated.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] No copy XML parser (rough idea only)
Hi, an idea recently crossed my mind that describes a (possibly?) useful way of accessing XML data from Haskell that is very memory efficient – at least as long as you only read the XML; for XML processing and generation, other existing libraries are probably well suited. Given a (possibly very large) XML file as a ByteString, a „normal“ XML parser would have an algebraic data type for node etc., parsing the ByteString into a tree of haskell values. Simplified a bit, the data structure could look like this: data Node = Node String [Attrib] [Node] | CData String The in-memory representation of such a a data structure is presumably very large, compared to the XML ByteString. Additionally, all the content is copied in memory and I evaluated a part of the Node (e.g. the tag name), this is retained by the constructor as long as the Node, and thus the whole document tree, is retained. My idea is to copy as little as possible, and refer to the existing ByteString as much as possible. Remember that a substring of a ByteString points at the same memory region, just with a different offset and length. So, in my case, the datatype looks like newtype Node = Node ByteString newtype CData = CData ByteString newtype Attrib = Attrib ByteString where the constructors would not be exported. Instead, accessor methods would be provided: tagName :: Node - String tagAttribs :: Node - [Attrib] tagContent :: Node - [Either Node CData] cDataContent :: CData - ByteString So when searching for a certain tag, the library would only have to generate (and retain) pointers to the ByteString, but the tag name themselves do not have to be retained after the comparision. If it turns out to be too expensive to parse the fragment that is referenced by Node on every invocation of tagContent, this could be made a field of the constructor. Due to lazy evaluation, it will only be evaluated when needed, but then kept in memory: data Node = Node ByteString [Either Node CData] About cDataContent: This method cannot just return the fragment of the document unaltered, unfortunately, as XML entities will have to be replaced. But if it returns a lazy ByteString, everything between the entities can be a chunk refering to the original data, again avoiding the creation of a copy. Now this is just a quick idea I wanted to share. I have not tried it yet, so I might be overlooking something which prevents the whole thing from working. It might also be the case that, due to lazy evaluation, the “usual” approach is actually well enough (at least if it uses ByteString instead of String). I’m curious what you think, Joachim Breitner -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
Hello,
i'm playin' around with GHCs Haskell and some extensions. I'm already aware of
that functional dependencies are very very tricky, but there is something I
don't understand about there implementation in GHC. I've constructed my own
TypeClass Num providing a signature for (+), having multiple params a, b and
c. I'm than declaring a (flexible) Instance for Prelude.Num, simply using
(Prelude.+) for the definition of my (+) - and it does not work as I expect it
to.
First, this is the code:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
TypeSynonymInstances, FlexibleInstances #-}
import qualified Prelude
class Num a b c | a b - c where
(+) :: a - b - c
instance (Prelude.Num x) = Num x x x where
(+) = (Prelude.+)
now if I load it into GHCi and type 3 + 4 i get a whole bunch of
error-messages.
I do understand that
(3::Prelude.Int) + (4::Prelude.Int)
works, since I've explicitly declared 3 and 4 to be Prelude.Int and there is a
functional dependency stating that (+) :: a b determines the results type c, by
the Instance declaration cleary c will be the same as a and b.
Now, if I type
3 + 4
it does not work, and i really don't understand why. If i ask GHCi for 3's type
($ :t 3) it will answer 3 :: (Prelude.Num t) = t. But, if 3 and 4 are
Prelude.Nums and there is an instanfe Num x x x for x of Prelude.Num - than why
can't GHC deduce from the definitions that 3 and 4, both Prelude.Nums, can be
used with (+) since there is an instance for Prelude.Num and my class Num - and
the result will of course be something of Prelude.Num?
best regards,
Julian
smime.p7s
Description: S/MIME cryptographic signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Modular type inference
Friends Many of you will know that I've been muttering about re-engineering GHC's type inference engine for some time now. Dimitrios, Tom, Martin and I have just completed an epic paper describing the Glorious New Framework that forms the substance of the above mutterings: http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn We'd love comments and feedback. Dimitrios and I plan to roll up our sleeves and implement it in June. Simon Modular type inference with local assumptions: OutsideIn(X) Abstract. Advanced type system features, such as GADTs, type classes, and type families have have proven to be invaluable language extensions for ensuring data invariants and program correctness among others. Unfortunately, they pose a tough problem for type inference, because they introduce local type assumptions. In this article we present a novel constraint-based type inference approach for local type assumptions. Our system, called OutsideIn(X), is parameterised over the particular underlying constraint domain X, in the same way as HM(X). This stratification allows us to use a common metatheory and inference algorithm. Going beyond the general framework, we also give a particular constraint solver for X = type classes + GADTs + type families, a non-trivial challenge in its own right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote: On 13 May 2010 04:12, Brent Yorgey byor...@seas.upenn.edu wrote: * Demand More of Your Automata by Aran Donohue Great, because of Aran I now can't change some of the bits of API in graphviz without making the code examples in his article break... If/when you change the API, just send me a darcs patch fixing Aran's code examples, and no one will ever be the wiser. This is the advantage of an electronic-only publication. ;) -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
Brent Yorgey byor...@seas.upenn.edu writes: On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote: On 13 May 2010 04:12, Brent Yorgey byor...@seas.upenn.edu wrote: * Demand More of Your Automata by Aran Donohue Great, because of Aran I now can't change some of the bits of API in graphviz without making the code examples in his article break... If/when you change the API, just send me a darcs patch fixing Aran's code examples, and no one will ever be the wiser. This is the advantage of an electronic-only publication. ;) Works for me! So, I take it TMR now has minor versions as well? ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
Julian Fleischer wrote:
Hello,
i'm playin' around with GHCs Haskell and some extensions. I'm already aware of that functional
dependencies are very very tricky, but there is something I don't understand about
there implementation in GHC. I've constructed my own TypeClass Num providing a
signature for (+), having multiple params a, b and c. I'm than declaring a (flexible) Instance for
Prelude.Num, simply using (Prelude.+) for the definition of my (+) - and it does not work as I
expect it to.
First, this is the code:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
TypeSynonymInstances, FlexibleInstances #-}
import qualified Prelude
class Num a b c | a b - c where
(+) :: a - b - c
instance (Prelude.Num x) = Num x x x where
(+) = (Prelude.+)
now if I load it into GHCi and type 3 + 4 i get a whole bunch of
error-messages.
I do understand that
(3::Prelude.Int) + (4::Prelude.Int)
works, since I've explicitly declared 3 and 4 to be Prelude.Int and there is a
functional dependency stating that (+) :: a b determines the results type c, by
the Instance declaration cleary c will be the same as a and b.
Now, if I type
3 + 4
it does not work, and i really don't understand why. If i ask GHCi for 3's type ($ :t 3) it
will answer 3 :: (Prelude.Num t) = t. But, if 3 and 4 are Prelude.Nums and
there is an instanfe Num x x x for x of Prelude.Num - than why can't GHC deduce from the
definitions that 3 and 4, both Prelude.Nums, can be used with (+) since there is an instance
for Prelude.Num and my class Num - and the result will of course be something of Prelude.Num?
My guess would be, that while 3 and 4 are both of a type instantiating
Prelude.Num (your terminology are Prelude.Nums is quite confusing --
Prelude.Num is not a type but a type class), they need not be of the
same type (e.g., 3 could be of type Integer, and 4 of type Double).
Jochem
--
Jochem Berndsen | joc...@functor.nl
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
Hello Julian, Friday, May 14, 2010, 4:18:42 PM, you wrote: Now, if I type 3 + 4 it does not work, and i really don't understand why. If i ask GHCi for 3's type ($ :t 3) it will answer 3 :: (Prelude.Num t) = t. But, if 3 and 4 are Prelude.Nums and there is an instanfe Num x x x for x of Prelude.Num - than why can't GHC deduce from the definitions that 3 and 4, both Prelude.Nums, can be used with (+) since there is an instance for Prelude.Num and my class Num - and the result will of course be something of Prelude.Num? because 3 and 4 may have different types. Num is a class, Int is a concrete type. 3 without additional type signature is polymorphic value. usually type inference deduce types of numeric constants (that all are polymorphic) from context but in your case it's impossible your functional dependency allows to fix result type once parameter types are known, but not other way you appeal to *instance* definition but haskell/ghc type inference can't use instance heads to deduce types since classes are open and anyone can add later code that breaks your assumption (imagine that ghc generates code for your module and later this module is imported by someone else and additional instances are provided) btw, quite popular problem, it arrives here each month or so :) there are some ghc pragmas that somewhat break this rule, you may try allow-indecidable-insances or so. but it's dangerous way -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
Hi Julian Variations of this one come up quite often, in a nutshell the typechecker doesn't use the instance context in the way you are expecting: instance (Prelude.Num x) = Num x x x where ^^^ instance context GHC takes less notice of the context than you might expect. Quite how much notice it takes I'm finding had to establish from section 7.6 of the user guide (Section 7.6.3.4. - Overlapping instances - appears to indicate it might even take none, though maybe my reading is missing something). Hopefully someone else will provide a definitive answer soon. http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is TChan GHC specific?
All of STM (Software Transactional Memory) is GHC-specific. Hm, it's odd that only TChan mentions it... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
On Friday 14 May 2010 15:32:10, Bulat Ziganshin wrote: Hello Julian, Friday, May 14, 2010, 4:18:42 PM, you wrote: Now, if I type 3 + 4 it does not work, and i really don't understand why. If i ask GHCi for 3's type ($ :t 3) it will answer 3 :: (Prelude.Num t) = t. But, if 3 and 4 are Prelude.Nums and there is an instanfe Num x x x for x of Prelude.Num - than why can't GHC deduce from the definitions that 3 and 4, both Prelude.Nums, can be used with (+) since there is an instance for Prelude.Num and my class Num - and the result will of course be something of Prelude.Num? because 3 and 4 may have different types. Num is a class, Int is a concrete type. 3 without additional type signature is polymorphic value. usually type inference deduce types of numeric constants (that all are polymorphic) from context but in your case it's impossible your functional dependency allows to fix result type once parameter types are known, but not other way you appeal to *instance* definition but haskell/ghc type inference can't use instance heads to deduce types since classes are open and anyone can add later code that breaks your assumption (imagine that ghc generates code for your module and later this module is imported by someone else and additional instances are provided) Exactly. instance (Prelude.Num x) = Num x Prelude.Integer x where a + b = a Prelude.* Prelude.fromInteger b *Main 3 + (4 :: Prelude.Integer) :: Prelude.Double 12.0 *Main 3 + (4 :: Prelude.Integer) :: Prelude.Integer interactive:1:0: Overlapping instances for Num Prelude.Integer Prelude.Integer Prelude.Integer arising from a use of `+' at interactive:1:0-25 Matching instances: instance (Prelude.Num x) = Num x x x -- Defined at NClass.hs:7:9-36 instance (Prelude.Num x) = Num x Prelude.Integer x -- Defined at NClass.hs:10:9-50 In the expression: 3 + (4 :: Prelude.Integer) :: Prelude.Integer In the definition of `it': it = 3 + (4 :: Prelude.Integer) :: Prelude.Integer btw, quite popular problem, it arrives here each month or so :) there are some ghc pragmas that somewhat break this rule, you may try allow-indecidable-insances or so. but it's dangerous way ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
If I notice a new library version I'll be happy to make the requisite changes myself, too :) Aran On Fri, May 14, 2010 at 9:30 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Brent Yorgey byor...@seas.upenn.edu writes: On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote: On 13 May 2010 04:12, Brent Yorgey byor...@seas.upenn.edu wrote: * Demand More of Your Automata by Aran Donohue Great, because of Aran I now can't change some of the bits of API in graphviz without making the code examples in his article break... If/when you change the API, just send me a darcs patch fixing Aran's code examples, and no one will ever be the wiser. This is the advantage of an electronic-only publication. ;) Works for me! So, I take it TMR now has minor versions as well? ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
On Fri, May 14, 2010 at 11:30:40PM +1000, Ivan Lazar Miljenovic wrote: Brent Yorgey byor...@seas.upenn.edu writes: On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote: On 13 May 2010 04:12, Brent Yorgey byor...@seas.upenn.edu wrote: * Demand More of Your Automata by Aran Donohue Great, because of Aran I now can't change some of the bits of API in graphviz without making the code examples in his article break... If/when you change the API, just send me a darcs patch fixing Aran's code examples, and no one will ever be the wiser. This is the advantage of an electronic-only publication. ;) Works for me! So, I take it TMR now has minor versions as well? ;-) No, just a very lax versioning policy. =) -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Modular type inference
I'm not knowledgeable enough in type systems to understand the paper, therefore I do not know if this email answers anything about your request for comments. For what I understand of the current possibilities of GHC, being able to use types for ensuring the axioms of algebra (groups, rings and fields) would be a great extension. The vector space package on hackage looks like a proof-of-concept of the possibilities of GHC's type system, which is obviously not suitable for production code. Such a typeclass (or whatever you call it) replacing Num, Real, etc. would be a good thing, in particular for eliminating fortan and matlab from the math laboratories ;-) As a former OCaml programmer, *the* thing that I miss is the exception system. I know about the challenge of keeping purity, but a type system redesign could be an opportunity to change this (or I did not understand anything, in this case please excuse me !). Cheers, Pierre-Etienne El 14/05/2010, a las 08:59, Simon Peyton-Jones escribió: Friends Many of you will know that I've been muttering about re-engineering GHC's type inference engine for some time now. Dimitrios, Tom, Martin and I have just completed an epic paper describing the Glorious New Framework that forms the substance of the above mutterings: http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn We'd love comments and feedback. Dimitrios and I plan to roll up our sleeves and implement it in June. Simon Modular type inference with local assumptions: OutsideIn(X) Abstract. Advanced type system features, such as GADTs, type classes, and type families have have proven to be invaluable language extensions for ensuring data invariants and program correctness among others. Unfortunately, they pose a tough problem for type inference, because they introduce local type assumptions. In this article we present a novel constraint-based type inference approach for local type assumptions. Our system, called OutsideIn(X), is parameterised over the particular underlying constraint domain X, in the same way as HM(X). This stratification allows us to use a common metatheory and inference algorithm. Going beyond the general framework, we also give a particular constraint solver for X = type classes + GADTs + type families, a non-trivial challenge in its own right. ___ 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] MultiParamTypeClasses, FunctionalDependencies and FlexibleInstances using GHCi
On Fri, May 14, 2010 at 02:18:42PM +0200, Julian Fleischer wrote:
Hello,
i'm playin' around with GHCs Haskell and some extensions. I'm already aware
of that functional dependencies are very very tricky, but there is
something I don't understand about there implementation in GHC. I've
constructed my own TypeClass Num providing a signature for (+), having
multiple params a, b and c. I'm than declaring a (flexible) Instance for
Prelude.Num, simply using (Prelude.+) for the definition of my (+) - and it
does not work as I expect it to.
First, this is the code:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
TypeSynonymInstances, FlexibleInstances #-}
import qualified Prelude
class Num a b c | a b - c where
(+) :: a - b - c
instance (Prelude.Num x) = Num x x x where
(+) = (Prelude.+)
now if I load it into GHCi and type 3 + 4 i get a whole bunch of
error-messages.
I do understand that
(3::Prelude.Int) + (4::Prelude.Int)
works, since I've explicitly declared 3 and 4 to be Prelude.Int and there is
a functional dependency stating that (+) :: a b determines the results type
c, by the Instance declaration cleary c will be the same as a and b.
Now, if I type
3 + 4
it does not work, and i really don't understand why. If i ask GHCi for 3's
type ($ :t 3) it will answer 3 :: (Prelude.Num t) = t. But, if 3 and 4 are
Prelude.Nums and there is an instanfe Num x x x for x of Prelude.Num - than
why can't GHC deduce from the definitions that 3 and 4, both Prelude.Nums,
can be used with (+) since there is an instance for Prelude.Num and my class
Num - and the result will of course be something of Prelude.Num?
The reason 3 + 4 works in GHCi ordinarily but not with your
redefined (+) has to do with the rules for type-defaulting. In the
ordinary case, GHCi is really evaluating show (3 + 4), which has a
type like (Num a, Show a) = String. We still have a free type
variable a, and the resulting value depends on our choice for this
type (consider Integer vs. Double). In this situation, there are
rules (Haskell '98 Report section 4.3.4) for making this choice, but
they only apply in very specific situations: in particular all of the
relevant classes (here Num and Show) must be among those defined in
the standard library. You can demonstrate that type-defaulting is at
work by trying to load the following into GHCi:
default ()
x = show (3 + 4)-- error: Ambiguous type variable
(GHCi actually has slighly relaxed defaulting rules, see [1], and it
seems to be impossible to turn off defaulting within GHCi, which is
why the expression show (3 + 4) must be in a module for this
demonstration.)
There is no provision for extending the defaulting mechanism to your
own type classes. Arguably this is a good thing, since defaulting can
sometimes behave surprisingly already under GHCi's rules, as anyone
who's run QuickCheck on a test with a type variable instantiated to ()
can attest to.
[1]:
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/interactive-evaluation.html#extended-default-rules
Regards,
Reid Barton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No copy XML parser (rough idea only)
The primary problem I see with this is that XML content is fundamentally text, not bytes. Using your types, two XML documents with identical content but different encodings will have different Haskell values (and thus be incorrect regarding Eq, Ord, etc). Additionally, since the original bytestring is shared in your types, potentially very large buffers could be locked in memory due to references held by only a small portion of the document. Chopping a document up into events or nodes creates some overhead due to the extra pointers, but allows unneeded portions to be freed. If you'd like memory-efficient text storage, using Bryan O'Sullivan's text package[1] is probably the best option. It uses packed Word16 buffers to store text as UTF-16. Probably not as efficient as a type backed by UTF-8, but it's much much better than String. I know the data types you specified are just examples, but they're leaving out some important XML features -- namespaces, entity references, etc. Consider either reading the XML spec, or perhaps use my package xml-types[2] as a starting point for designing your type hierarchy. [1] http://hackage.haskell.org/package/text [2] http://hackage.haskell.org/package/xml-types ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What makes Haskell difficult as .NET?
In this presentation http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=907 the speaker talks about F# on .Net platform. Early on in the talk he says that they did F# because haskell would be hard to make as a .Net language.Does anyone know what features of Haskell make it difficult as .Net language? Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What makes Haskell difficult as .NET?
dmehrtash: In this presentation http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id= 907 the speaker talks about F# on .Net platform. Early on in the talk he says that they did F# because haskell would be hard to make as a .Net language. Does anyone know what features of Haskell make it difficult as .Net language? The issue here I believe is primarily the desire to interoperate with any .NET library, with zero effort by the developer. Most .NET libraries are imperative, use mutable state -- so binding to those is less fun, and a bit more labor intensive, in Haskell -- though the FFI can certainly do it pretty easily. It also moves most of the .NET libraries into the IO monad, making them less useful. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No copy XML parser (rough idea only)
On Fri, May 14, 2010 at 08:57:42AM -0700, John Millikin wrote: Additionally, since the original bytestring is shared in your types, potentially very large buffers could be locked in memory due to references held by only a small portion of the document. Chopping a document up into events or nodes creates some overhead due to the extra pointers, but allows unneeded portions to be freed. However, if your bytestring comes from mmap'ed memory this drawback wouldn't apply :D. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] What makes Haskell difficult as .NET?
Hello Don, Friday, May 14, 2010, 9:43:38 PM, you wrote: Most .NET libraries are imperative, use mutable state -- so binding to they are also OOP. ocaml supports OOP while haskell doesn't -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What makes Haskell difficult as .NET?
Would there be issues (lazy evaluation, type system...) with other languages calling a Haskell code in a hypothetical Haskell in .NET? Daryoush On Fri, May 14, 2010 at 10:43 AM, Don Stewart d...@galois.com wrote: dmehrtash: In this presentation http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id= 907 the speaker talks about F# on .Net platform. Early on in the talk he says that they did F# because haskell would be hard to make as a .Net language. Does anyone know what features of Haskell make it difficult as .Net language? The issue here I believe is primarily the desire to interoperate with any .NET library, with zero effort by the developer. Most .NET libraries are imperative, use mutable state -- so binding to those is less fun, and a bit more labor intensive, in Haskell -- though the FFI can certainly do it pretty easily. It also moves most of the .NET libraries into the IO monad, making them less useful. -- Don -- Daryoush Weblog: http://perlustration.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No copy XML parser (rough idea only)
Hi, Am Freitag, den 14.05.2010, 15:31 -0300 schrieb Felipe Lessa: On Fri, May 14, 2010 at 08:57:42AM -0700, John Millikin wrote: Additionally, since the original bytestring is shared in your types, potentially very large buffers could be locked in memory due to references held by only a small portion of the document. Chopping a document up into events or nodes creates some overhead due to the extra pointers, but allows unneeded portions to be freed. However, if your bytestring comes from mmap'ed memory this drawback wouldn't apply :D. exactly. Of course such a library would not be a general-purpose tool, but in cases where you know that you need most of the document for most of the time, e.g. when doing statistics on it, this would be acceptable. Also note that even after chopping into nodes, if you don’t make sure you drop the reference to root in a timely manner, the same thing would happen. Am Freitag, den 14.05.2010, 08:57 -0700 schrieb John Millikin: The primary problem I see with this is that XML content is fundamentally text, not bytes. Using your types, two XML documents with identical content but different encodings will have different Haskell values (and thus be incorrect regarding Eq, Ord, etc). The instances could be adapted... but this will be expensive, of course. One could also convert documents that are not utf-8 encoded as a whole and then work on that. If you'd like memory-efficient text storage, using Bryan O'Sullivan's text package[1] is probably the best option. It uses packed Word16 buffers to store text as UTF-16. Probably not as efficient as a type backed by UTF-8, but it's much much better than String. Right. For arbtt, I tried to switch from String to text, and it actually got slower. The reason (I think) was that besides passing strings around, it mainly runs pcre-light on them – which wants utf8-encoded bytestrings. I ended up creating a newtype¹ around utf8-encoded ByteStrings and the result was quite satisfying, both memory- and runtime-wise. I wish we had a package providing a standard type for this type that would become similarly popular. There is at least one more packages on hackage that defines this type: http://hackage.haskell.org/packages/archive/regex-tdfa-utf8/1.0/doc/html/Text-Regex-TDFA-UTF8.html Greetings, Joachim ¹ http://darcs.nomeata.de/arbtt/src/Data/MyText.hs -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What makes Haskell difficult as .NET?
dmehrtash: Would there be issues (lazy evaluation, type system...) with other languages calling a Haskell code in a hypothetical Haskell in .NET? There are always issues, but conceptually it is no harder than calling Haskell from C, which is relatively straight forward. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent of the underlying monad. It doesn't even require the m in
ContT r m to be a functor, let alone a monad. Therefore the ContT
bind doesn't do any case-analysis because it doesn't know anything
about the underlying monad. One way to look at what is happening is
to compare it to Andrzej Filiniski's work in Representing Monads and
Representing Layered Monads.
On Mon, May 10, 2010 at 4:38 AM, Max Cantor mxcan...@gmail.com wrote:
Based on some discussions in #haskell, it seemed to be a consensus that using
a modified continuation monad for Error handling instead of Eithers would be
a significant optimization since it would eliminate a lot of conditional
branching (everytime = is called in the Either monad, there is a
conditional.
I implemented a ErrCPS monad which does exactly that, but the speed has been
disappointing. It runs almost exactly 3x slower than a drop in replacement
using the MonadError instance of Either from mtl.
mkEMA and midError are basically toy functions but I dont know why Either is
so much faster. I've experimented with putting some seq's in the bindErrCPS
and even {-# INLINE (=) #-} in the Monad instance, but to no avail.
I've copy/pasted the code below, any suggestions on optimization, or if this
is simply a bad idea would be much appreciated. Strangely, compiling with
-O2 seems to have no effect on the speed:
-Max
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE Rank2Types #-}
module Main where
import Control.Applicative
import Control.Monad.Error -- hiding (foldM)
import Control.Monad.Trans
import Control.Monad hiding (foldM)
import System.Random
import Control.Monad.Identity (runIdentity, Identity)
import Control.Monad.Reader.Class
import Data.Time.LocalTime as Time -- for benchmarking
import Data.Time.Calendar (Day)
import Data.Time.LocalTime (getZonedTime)
midError :: MonadError String m = Double - Double - m Double
midError a b = if (b 1) then throwError check val
else let r = (a + b) / 2 in r `seq` (return r)
mkEMA l = foldM midError 1 l
newtype ErrCPS e m a = ErrCPS { runErrCPS :: forall r . (e - m r) -- error
handler
- (a - m r) -- success handler
- m r }
{-# INLINE retErrCPS #-}
retErrCPS :: a - ErrCPS e m a
retErrCPS x = ErrCPS $ \_ good - good x
{-# INLINE bindErrCPS #-}
bindErrCPS :: ErrCPS e m b - (b - ErrCPS e m a) - ErrCPS e m a
bindErrCPS m f = ErrCPS $ \err good - runErrCPS m err $ \x - runErrCPS (f
x) err good
instance Monad m = Monad (ErrCPS e m) where
return = retErrCPS
(=) = bindErrCPS
main :: IO ()
main = do
let n = 50
runEither e b g = either b g e
runTest f s = do
sg - newStdGen
let l = take n $ randomRs (2, 5) sg
mapM_ (\e - e `seq` return ()) l
stopwatch $ f (mkEMA l)
(putStr . show)
(putStr . (s ++) . show)
forever $ do runTest runEither either:
runTest runErrCPS errCPS:
ErrCPS based code seems to run almost exactly 3x slower than the
Either based code:
errCPS: 37453.226 Action ran in: 30 msec
either: 26803.055 Action ran in: 11 msec
errCPS: 15840.626 Action ran in: 34 msec
either: 32556.881 Action ran in: 10 msec
errCPS: 38933.121 Action ran in: 30 msec
either: 35370.820 Action ran in: 11 msec
...
instance (Error e, Monad m) = MonadError e (ErrCPS e m) where
throwError = errCPS
catchError m f = ErrCPS $ \err good - runErrCPS m (\e - runErrCPS (f e)
err good) good
-- * MTL stuff
instance MonadTrans (ErrCPS e ) where lift m = ErrCPS $ \_ good - m = good
instance (MonadIO m) = MonadIO (ErrCPS e m ) where liftIO = lift . liftIO
Random utility stuff
stopwatch :: IO () - IO ()
stopwatch act = do
t1 - getFastTimeOfDay
act
t2 - getFastTimeOfDay
putStrLn $ Action ran in: ++ show (t2 - t1) ++ msec
type FastTimeOfDay = Int
-- | Return the current trading day. This should respect the
-- fact that the Trading Day ranges from
-- SingTime 6am (UTC -02:00) to SST 5:59 am (UTC -1:59).
getTradingDay :: IO Day
getTradingDay = error getTradingDay undefined
getFastTimeOfDay :: IO FastTimeOfDay
getFastTimeOfDay = getZonedTime =
(return . fastFromTimeOfDay . Time.localTimeOfDay .
Time.zonedTimeToLocalTime)
timeOfDayFromFast :: FastTimeOfDay - Time.TimeOfDay
timeOfDayFromFast fast = Time.TimeOfDay
{ Time.todHour = fromIntegral (fast `div` (3600 * 1000))
, Time.todMin = fromIntegral (fast `div` (60 * 1000)) `mod` 60
, Time.todSec =
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com wrote: You did it wrong. All you did was Church encode the Either type. Your bind is still doing a case-analysis. All you have to do is use ContT r (Either e). The bind implementation for ContT is completely independent of the underlying monad. It doesn't even require the m in ContT r m to be a functor, let alone a monad. Therefore the ContT bind doesn't do any case-analysis because it doesn't know anything about the underlying monad. One way to look at what is happening is to compare it to Andrzej Filiniski's work in Representing Monads and Representing Layered Monads. Would you then use callCC to get the required short-circuit-on-error behavior? A church encoding of Either coded as a monad transformer still wouldn't hit the inner monad on bind, even if it is weaving the left and right continuations together. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Fri, May 14, 2010 at 4:53 PM, Antoine Latter aslat...@gmail.com wrote: On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com wrote: You did it wrong. All you did was Church encode the Either type. Your bind is still doing a case-analysis. All you have to do is use ContT r (Either e). The bind implementation for ContT is completely independent of the underlying monad. It doesn't even require the m in ContT r m to be a functor, let alone a monad. Therefore the ContT bind doesn't do any case-analysis because it doesn't know anything about the underlying monad. One way to look at what is happening is to compare it to Andrzej Filiniski's work in Representing Monads and Representing Layered Monads. Would you then use callCC to get the required short-circuit-on-error behavior? A church encoding of Either coded as a monad transformer still wouldn't hit the inner monad on bind, even if it is weaving the left and right continuations together. callCC wouldn't work well here. What would work better is another control operator commonly called 'control' which does not resume if the passed in continuation isn't invoked. However, it's usually even clearer (or at least more concise) in these situations to work with the continuation passing style directly. -- fail directly using CPS fail :: String - ContT r (Either String) a fail s = ContT $ \k - Left s ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
Aran Donohue aran.dono...@gmail.com writes: If I notice a new library version I'll be happy to make the requisite changes myself, too :) One thing I think I should mention: it might also be helpful to say which packages your article uses rather than the modules (as that involves more work finding which packages are needed to follow along). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What makes Haskell difficult as .NET?
On Fri, 2010-05-14 at 10:40 -0700, Daryoush Mehrtash wrote: In this presentation http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=907 the speaker talks about F# on .Net platform. Early on in the talk he says that they did F# because haskell would be hard to make as a .Net language.Does anyone know what features of Haskell make it difficult as .Net language? Daryoush 1. Haskell Class/Type famillies/... are conceptually different then classes and interfaces. 2. As .Net does not differentiate between IO a and a Haskell cannot feel completely native (hand-made FFI or everything in IO) 3. .Net does differentiate between variables and functions with 0 arguments. 4. .Net types are not lazy. String is not [Char]. Arrays are used in many places. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help debugging code broken after upgrading debian to GHC 6.12: invalid argument
On May 14, 2010, at 20:24 , Brandon Simmons wrote: The other baffling thing is this: if the debugging line 426 is uncommented, then even running: $ runghc Befunge.hs --quiet mycology.b98 ...will fail. But all we're doing is a call to `putStr`! Why would that trigger an error?! Maybe there was a bug in my code that was GHC 6.12's runtime handles input and output encoding, instead of simply truncating Chars; my guess is it's locale-related. And sure enough, I see several non-ASCII characters in mycology.b98 which are likely to do the wrong thing if the runtime doesn't know which character set to use. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help debugging code broken after upgrading debian to GHC 6.12: invalid argument
On Saturday 15 May 2010 02:53:43, Brandon S. Allbery KF8NH wrote: On May 14, 2010, at 20:24 , Brandon Simmons wrote: The other baffling thing is this: if the debugging line 426 is uncommented, then even running: $ runghc Befunge.hs --quiet mycology.b98 ...will fail. But all we're doing is a call to `putStr`! Why would that trigger an error?! Maybe there was a bug in my code that was GHC 6.12's runtime handles input and output encoding, instead of simply truncating Chars; my guess is it's locale-related. And sure enough, I see several non-ASCII characters in mycology.b98 which are likely to do the wrong thing if the runtime doesn't know which character set to use. Yup. Converting mycology.b98 to utf-8 makes it run. However, why does it run with --quiet on the original file?? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What makes Haskell difficult as .NET?
On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka uzytkown...@gmail.com wrote: 1. Haskell Class/Type famillies/... are conceptually different then classes and interfaces. I believe interfaces would be roughly equivalent to the subset of single-parameter type classes such that: - All type class methods are functions - The first argument of each function is the class's type parameter, fully applied to any type parameters it needs - The class's type parameter appears nowhere else Painfully limited, but better than nothing. This would mostly make it problematic to export Haskell functions with type class constraints to other .NET languages, though. I suspect large sections of the .NET libraries could be expressed in Haskell without too much trouble (well, besides everything being in IO), except that getting Haskell to interact nicely with the concept of subtyping in inheritance hierarchies might be awkward. Also potentially problematic is that (if memory serves me) .NET can only handle type parameters with kind *, which excludes types parameterized by type constructors, such as monad transformers. Irritatingly, a lot of stuff in the .NET framework is almost, but not quite, equivalent to some really key bits of Haskell. For instance, Enumerable.SelectA,B(IEnumerableA, FuncA,B) is almost fmap, but returns an existential type instead. I guess IEnumerableT is something akin to Foldable, with cheap kludgy imitations of fmap and (=) bolted on after the fact. Explicit type checks might be necessary in places as well, to deal with .NET's feeble and unreliable type system. Some boilerplate involving Data.Typeable/Data.Dynamic ought to suffice. 2. As .Net does not differentiate between IO a and a Haskell cannot feel completely native (hand-made FFI or everything in IO) Wouldn't be any worse than using most C bindings in Haskell as is. Or using a lot of .NET libraries in F#, to be honest, if you try to write functional-idiomatic instead of quasi-imperative code. Though, considering the near-omnipresent possibility of null references, most .NET functions would actually need to return something of the form IO (Maybe a). 3. .Net does differentiate between variables and functions with 0 arguments. Yes, though the latter are easy enough to use. Property getters are nullary functions, likewise the FuncTResult delegate type. You can even write nullary lambda expressions as () = ..., though nullary lambda abstraction is kind of a contradiction in terms. A combination of a nullary pure function and a mutable static variable to cache the result of evaluating it would provide something similar to lazy terms in Haskell. 4. .Net types are not lazy. String is not [Char]. Arrays are used in many places. On the other hand, many of the hot new features on the .NET platform are built around lazy collections with IEnumerableT, which is primarily used as if it were the list monad (e.g., LINQ syntax being sort of a monad comprehension). In summary: So close, yet so far. It'd probably work just well enough to be viable, but be too painful to be enjoyable. I use C# at the day job, so I notice these things often... - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What makes Haskell difficult as .NET?
On Fri, 2010-05-14 at 22:54 -0400, C. McCann wrote:
On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka uzytkown...@gmail.com
wrote:
1. Haskell Class/Type famillies/... are conceptually different then
classes and interfaces.
I believe interfaces would be roughly equivalent to the subset of
single-parameter type classes such that:
- All type class methods are functions
- The first argument of each function is the class's type parameter,
fully applied to any type parameters it needs
- The class's type parameter appears nowhere else
I'm not sure but also:
- you can write always a new class in Haskell:
class Abc x where
abc :: x - Int
instance Abc Int where abc = id
IIRC .Net interfaces cannot be added outside assembly (I may be wrong).
On the other hand Haskell does not have inheritance.
Generally
Haskell: newtype/data specify data (and type) while classes provides
basic abstract operations on it.
C#/Java/...: Classes specify data AND how to operate on it (including
non-basic operators) and interfaces abstract operations.
- It is not that it can occur once:
class Abc x where
abc :: x - [x]
is roughly:
interface Abcin T {
public IListT abc();
}
- It seems that it is not possible to have default implementations in
interfaces.
2. As .Net does not differentiate between IO a and a Haskell cannot feel
completely native (hand-made FFI or everything in IO)
Wouldn't be any worse than using most C bindings in Haskell as is. Or
using a lot of .NET libraries in F#, to be honest, if you try to write
functional-idiomatic instead of quasi-imperative code.
Though, considering the near-omnipresent possibility of null
references, most .NET functions would actually need to return
something of the form IO (Maybe a).
However the problem is that the .Net is suppose to be a single platform
with different syntaxes attacked to it. It does not stop to use F#
operations (without syntax sugar) in C# or VB.
Haskell on .Net would be a foreigner as it is on C.
Regards
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
