Re: [Haskell-cafe] Control.Monad provisional?
I might be wrong, but the impression I always had is that that field is something that most developer struggle to keep in sync. Maybe it was provisional ages ago, but they simply forgot to upgrade to stable or they are simply too humble and think How am I to judge if a package is stable or not? :) My 2 cents :P A. On 10 February 2013 20:38, Petr Pudlák petr@gmail.com wrote: Dear Haskellers, Looking at Control.Monad: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-Monad.html I see: Stability provisional. I checked some older versions and it's the same. This feel somewhat unsettling - if Control.Monad is provisional, do we have any stable packages at all? Best regards, Petr Pudlak ___ 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] [Announcement] hArduino: Control your Arduino board from Haskell
Sounds cool! Thanks for your effort! :) A. On 10 February 2013 22:54, Levent Erkok erk...@gmail.com wrote: I'm happy to announce hArduino: a library that allows Arduino boards to be controlled directly from Haskell. hArduino uses the Firmata protocol ( http://firmata.org), to communicate with and control Arduino boards, making it possible to implement many controller projects directly in Haskell. Home page: http://leventerkok.github.com/hArduino/ Hackage: http://hackage.haskell.org/package/hArduino Some example programs: Blink the led: http://hackage.haskell.org/packages/archive/hArduino/latest/doc/html/System-Hardware-Arduino-SamplePrograms-Blink.html Digital counter: http://hackage.haskell.org/packages/archive/hArduino/latest/doc/html/System-Hardware-Arduino-SamplePrograms-Counter.html Control an LCD: http://hackage.haskell.org/packages/archive/hArduino/latest/doc/html/System-Hardware-Arduino-SamplePrograms-LCD.html Short (4.5 mins) youtube video of the blink example: http://www.youtube.com/watch?v=PPa3im44t2g hArduino is work-in-progress: Patches, bug-reports, and feedback is most welcome. -Levent. ___ 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] arrow notation
2013/2/11 Ertugrul Söylemez e...@ertes.de ... ## Applicative One of the main bottlenecks of arrows is the heavy tuple handling, but most (if not all) arrows form a family of applicative functors. I noticed a huge speedup by moving from arrow style to applicative style where possible: liftA2 (+) (lmap f c) (fmap g d) is often much faster than: arr (uncurry (+)) . (c . arr f arr g . d) Besides being more readable it sometimes improved the performance of my code by an order of magnitude. So perhaps check to see if the category forms an applicative functor. If it does, you can get along without Arrow entirely. I've been reading *Idioms are oblivious, arrows are meticulous, monads are promiscuous* recently, and if I understand it correctly, an arrow forms an applicative functor if it's possible to define a delaying operation on it, which separates the arrow's effect from its computation: class Arrow a = ArrowDelay a where delay :: a b c - a () (b - c) -- Definable for any arrow: force :: Arrow a = a () (b - c) - a b c force af = (,) () ^ first af ^ uncurry ($) and satisfying `force . delay = id = delay . force`. While the implementation of Applicative can be defined without actually using `delay`: newtype ArrowApp a b c = ArrowApp (a b c) instance Arrow a = Functor (ArrowApp a b) where fmap f (ArrowApp a) = ArrowApp (a ^ f) instance ArrowDelay a = Applicative (ArrowApp a b) where pure x = ArrowApp $ arr (const x) (ArrowApp af) * (ArrowApp ax) = ArrowApp $ (af ax) ^ uncurry ($) I believe it only satisfies the laws only if the arrow satisfies delay/force laws. Perhaps it would be convenient to have ArrowDelay and the corresponding conversions included in the library so that defining and using Applicative instances for arrows would become more straightforward. Best regards, Petr Pudlak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Announcement] HsLlvm v0.1: Using Hoopl to optimize LLVM Code
Hi all, It is my dream for years to be able to manipulate LLVM in type safe language. I has explored the possibility of reimplementing LLVM in Haskell with Hoopl and made a small step to realize this dream. I am writing to announce the release of HsLlvm v0.1, which is a pure Haskell implementation (Not LLVM C++ binding) of LLVM. It is available through the link below. https://github.com/mlite/HsLlvm Hightlight of this release: - Support LLVM 3.1 syntax - LLVM normalization - Dominator, mem2reg, DCE passes Project goals: - port all LLVM optimizations - provide functionalities to generate and manipulate LLVM code. Since LLVM is a complex IR and there are many sophisticated optimizations, this job won't be easy. Your contribution would be of value to eventually achieve this goal. Cheers, Ning ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Control.Monad provisional?
Alfredo is right. Most users don't pay much attention to it, and developers have preferred to be conservative and mark the modules as experimental (and provisional at best), because there's no incentive to commit to keeping the modules stable. And there's no policy about stable modules. The Haskell Platform is a much more successful experiment in the same direction, because there actually is an incentive (and clear need) to keep the packages stable. Portability is another obsolete field. The same information nowadays can be robustly inferred from the LANGUAGE pragmas in the modules and the .cabal file. For my packages, I stopped putting these fields quite some time ago, and I'm looking forward to their removal. Roman * Alfredo Di Napoli alfredo.dinap...@gmail.com [2013-02-11 08:03:30+] I might be wrong, but the impression I always had is that that field is something that most developer struggle to keep in sync. Maybe it was provisional ages ago, but they simply forgot to upgrade to stable or they are simply too humble and think How am I to judge if a package is stable or not? :) My 2 cents :P A. On 10 February 2013 20:38, Petr Pudlák petr@gmail.com wrote: Dear Haskellers, Looking at Control.Monad: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-Monad.html I see: Stability provisional. I checked some older versions and it's the same. This feel somewhat unsettling - if Control.Monad is provisional, do we have any stable packages at all? Best regards, Petr Pudlak ___ 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] arrow notation
Ross Paterson r...@soi.city.ac.uk wrote: Many computations ignore their input value. You can recognize them by their type: [...] Inspection of types is not allowed with GHC's constraint-based type checker, which rules out things like this. Too bad. Would it be possible to get rid of - ()? ## returnA We don't need it anymore, and it has quite a stupid definition. Get rid of it in favor of 'id'. It would be reasonable to redefine returnA = id Yes, that would be a good start. For many applications using 'id' instead of 'arr id' gives a huge performance boost. In my particular case (I'm doing wire-based FRP (WFRP)) I often start with a complex sum network of categorical computations: c1 . c2 | c3 . c4 . (c5 | c6) | c7 The distinguishing feature of WFRP, what makes it so fast, is that you can get rid of complexity by recognizing 'id' and 'empty' when they pop up. The component computations can morph into them over time, for example for 3 is identity-like for three seconds and then switches to 'empty'. You can recognize and discard entire subnetworks quickly. ## Operators I often need to mix regular arguments with computation arguments in banana notation: let f c = f' x y c z (| f (comp - v) |) This wouldn't be legal if f was defined inside the proc. If the arguments come from outside the proc, you could write (permuting the arguments) (| (f x y z) (comp - v) |) If they're defined inside the proc, you'd have something like (| f (comp - v) |) x y z Of course, and that's the inconvenient part. You have to write wrapper functions. It would be nice, if the bananas would consider unparenthesized expressions as regular arguments. ## PreArrow All sensible arrows form a family of functors: instance (Arrow a) = Functor (a b) where fmap f = (arr f .) But they do more: Every arrow is a profunctor as defined in the 'profunctors' package: instance (Arrow a) = Profunctor a where lmap f = (. arr f) rmap = fmap That's just what you called PreArrow, Not so: every arrow has lmap and rmap, but not everything that has an lmap also has an rmap. I see. You want to get rid of 'arr' altogether. On one hand that is desirable. On the other hand for arrows lmap and rmap are equivalent. You can define 'arr' given 'lmap': arr f = lmap f id From that you can define fmap. This leads to the conclusion that as soon as the arrow notation does more than simple composition you need a functor anyway. ## Applicative One of the main bottlenecks of arrows is the heavy tuple handling, but most (if not all) arrows form a family of applicative functors. I noticed a huge speedup by moving from arrow style to applicative style where possible: liftA2 (+) (lmap f c) (fmap g d) is often much faster than: arr (uncurry (+)) . (c . arr f arr g . d) Besides being more readable it sometimes improved the performance of my code by an order of magnitude. So perhaps check to see if the category forms an applicative functor. If it does, you can get along without Arrow entirely. In fact I propose to generalize all the Arrow* classes to Category* classes. That sounds reasonable. It's convenient to use simpler classes instead of Arrow where possible, but it's not always possible. The idea is this: If there are both Arrow and Applicative instances (can you check this?), the arrow notation could use applicative combinators instead of arrowic ones where possible: proc x' - do f - comp1 - x' x - comp2 - x' comp3 - f x If this is possible, arrow notation would likely rewrite it to comp3 . ((\f x - f x) $ comp1 * comp2) and, as a nice bonus, recognize that \f x - f x is really just id and optimize the fmap away: comp3 . (comp1 * comp2) The pattern is: A computation composed of subcomputations where each of them takes the same arrow variable as input. The corresponding arrow version is unnecessarily expensive because of the tuple wrapping and unwrapping, comp3 . arr (\(f, x) - f x) . comp1 comp2 whereas the applicative version is really straightforward and fast. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Announcement] HsLlvm v0.1: Using Hoopl to optimize LLVM Code
Hi, This seems a fantastic job! Do you have any plan to support LLVM - target phase, or do you know any project doing something similar? Thanks in advance. 2013/2/11 Ning Wang em...@ningwang.org Hi all, It is my dream for years to be able to manipulate LLVM in type safe language. I has explored the possibility of reimplementing LLVM in Haskell with Hoopl and made a small step to realize this dream. I am writing to announce the release of HsLlvm v0.1, which is a pure Haskell implementation (Not LLVM C++ binding) of LLVM. It is available through the link below. https://github.com/mlite/**HsLlvm https://github.com/mlite/HsLlvm Hightlight of this release: - Support LLVM 3.1 syntax - LLVM normalization - Dominator, mem2reg, DCE passes Project goals: - port all LLVM optimizations - provide functionalities to generate and manipulate LLVM code. Since LLVM is a complex IR and there are many sophisticated optimizations, this job won't be easy. Your contribution would be of value to eventually achieve this goal. Cheers, Ning __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Text.JSON and utf8
hi,
tl;dr: i propose this patch to Text/JSON/String.hs and would like to
know why it is needed:
@@ -375,7 +375,7 @@
where
go s1 =
case s1 of
- (x :xs) | x '\x20' || x '\x7e' - '\\' : encControl x (go xs)
+ (x :xs) | x '\x20' - '\\' : encControl x (go xs)
('' :xs) - '\\' : '' : go xs
('\\':xs) - '\\' : '\\' : go xs
(x :xs) - x: go xs
i recently stumbled upon CouchDB telling me i'm sending invalid json.
i basically read lines from a utf8 file with german umlauts and send
them to CouchDB using Text.JSON and Database.CouchDB.
$ file lines.txt
lines.txt: UTF-8 Unicode text
lets take 'ö' as an example. i use LANG=de_DE.utf8
ghci tells
'ö'
'\246'
putChar '\246'
ö
putChar 'ö'
ö
:m + Text.JSON Database.CouchDB
runCouchDB' $ newNamedDoc (db foo) (doc bar) (showJSON $
toJSObject [(test,ö)])
*** Exception: HTTP/1.1 400 Bad Request
Server: CouchDB/1.2.1 (Erlang OTP/R15B03)
Date: Mon, 11 Feb 2013 13:24:49 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 48
Cache-Control: must-revalidate
couchdb log says:
Invalid JSON: {{error,{10,lexical error: invalid bytes in UTF8
string.\n}},{\test\:\F6\}}
this is indeed hex ö:
:m + Numeric
putChar $ toEnum $ fst $ head $ readHex f6
ö
if i apply the above patch and reinstall JSON and CouchDB the doc
creation works:
runCouchDB' $ newNamedDoc (db db) (doc foo) (showJSON $
toJSObject [(test, ö)])
Right someRev
but i dont get back the ö i expected:
Just (_,_,x) -runCouchDB' $ getDoc (db foo) (doc bar) :: IO
(Maybe (Doc,Rev,JSObject String))
let Ok y = valFromObj test = readJSON x :: Result String
y
\195\188
putStrLn y
ü
apperently with curl everything works fine:
$ curl localhost:5984/db/foo -XPUT -d '{test: ö}'
{ok:true,id:foo,rev:someOtherRev}
$ curl localhost:5984/db/foo
{_id:bars,_rev:someOtherRev,test:ö}
so how can i get my precious ö back? what am i doing wrong or does
Text.JSON need another patch?
another question: why does encControl in Text/JSON/String.hs handle the
cases x '\x100' and x '\x1000' even though they can never be
reached with the old predicate in encJSString (x '\x20')
finally: is '\x7e' the right literal for the job?
thanks for reading
have fun
martin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.JSON and utf8
Don't use the json package, use aeson instead. (It's much faster and
handles encoding issues correctly).
G
On Mon, Feb 11, 2013 at 2:56 PM, Martin Hilbig li...@mhilbig.de wrote:
hi,
tl;dr: i propose this patch to Text/JSON/String.hs and would like to
know why it is needed:
@@ -375,7 +375,7 @@
where
go s1 =
case s1 of
- (x :xs) | x '\x20' || x '\x7e' - '\\' : encControl x (go xs)
+ (x :xs) | x '\x20' - '\\' : encControl x (go xs)
('' :xs) - '\\' : '' : go xs
('\\':xs) - '\\' : '\\' : go xs
(x :xs) - x: go xs
i recently stumbled upon CouchDB telling me i'm sending invalid json.
i basically read lines from a utf8 file with german umlauts and send
them to CouchDB using Text.JSON and Database.CouchDB.
$ file lines.txt
lines.txt: UTF-8 Unicode text
lets take 'ö' as an example. i use LANG=de_DE.utf8
ghci tells
'ö'
'\246'
putChar '\246'
ö
putChar 'ö'
ö
:m + Text.JSON Database.CouchDB
runCouchDB' $ newNamedDoc (db foo) (doc bar) (showJSON $ toJSObject
[(test,ö)])
*** Exception: HTTP/1.1 400 Bad Request
Server: CouchDB/1.2.1 (Erlang OTP/R15B03)
Date: Mon, 11 Feb 2013 13:24:49 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 48
Cache-Control: must-revalidate
couchdb log says:
Invalid JSON: {{error,{10,lexical error: invalid bytes in UTF8
string.\n}},{\test\:\**F6\}}
this is indeed hex ö:
:m + Numeric
putChar $ toEnum $ fst $ head $ readHex f6
ö
if i apply the above patch and reinstall JSON and CouchDB the doc
creation works:
runCouchDB' $ newNamedDoc (db db) (doc foo) (showJSON $ toJSObject
[(test, ö)])
Right someRev
but i dont get back the ö i expected:
Just (_,_,x) -runCouchDB' $ getDoc (db foo) (doc bar) :: IO (Maybe
(Doc,Rev,JSObject String))
let Ok y = valFromObj test = readJSON x :: Result String
y
\195\188
putStrLn y
ü
apperently with curl everything works fine:
$ curl localhost:5984/db/foo -XPUT -d '{test: ö}'
{ok:true,id:foo,rev:**someOtherRev}
$ curl localhost:5984/db/foo
{_id:bars,_rev:**someOtherRev,test:ö}
so how can i get my precious ö back? what am i doing wrong or does
Text.JSON need another patch?
another question: why does encControl in Text/JSON/String.hs handle the
cases x '\x100' and x '\x1000' even though they can never be
reached with the old predicate in encJSString (x '\x20')
finally: is '\x7e' the right literal for the job?
thanks for reading
have fun
martin
__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arrow notation
On Mon, Feb 11, 2013 at 11:30 AM, Ertugrul Söylemez e...@ertes.de wrote: The idea is this: If there are both Arrow and Applicative instances (can you check this?), the arrow notation could use applicative combinators instead of arrowic ones where possible: I wonder if maybe this could be done with rewrite rules rather than on the syntax level? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arrow notation
On Sun, Feb 10, 2013 at 09:28:12PM +0100, Petr Pudlák wrote: 2013/2/9 Conal Elliott co...@conal.net wrote: What I have in mind is a small collection of methods including fst snd (and similarly for sums) that could be defined via arr but could instead form the basis of translating restricted arrow notation for (pseudo-)arrows that don't support arr. I also support this idea, I'd appreciate such a generalization. As an example, where it would be useful: One of my students was working on a (very nice) project where he used Haskell as a DSL for generating a FRP-like javascript code. The arrow notation without arr would be ideal for this situation. He couldn't implement arr as it would require to translate an arbitrary Haskell function to JS. So having a more general variant of Arrow without arr and with a collection of methods sufficient for the arrow notation would be quite helpful. (I wonder what methods would have to be included in the collection.) Let's try to break this down. Suppose we split arr :: forall b c. (b - c) - a b c into two primitives (^) :: forall b c d. (b - c) - a c d - a b d id :: forall b. a b b The contravariant functor (^) is essential to arrow notation, but I suspect the issue is the universally quantified b in the type of id (or equivalently returnA). One might instead use a variant of id constrained to an ADT with just the operations you want. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arrow notation
Petr Pudlák petr@gmail.com wrote: class Arrow a = ArrowDelay a where delay :: a b c - a () (b - c) force :: Arrow a = a () (b - c) - a b c Perhaps it would be convenient to have ArrowDelay and the corresponding conversions included in the library so that defining and using Applicative instances for arrows would become more straightforward. I appreciate the idea from a theoretical standpoint, but you don't actually have to define an ArrowDelay instance for the notation to work. The compiler can't check the laws anyway. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How far compilers are allowed to go with optimizations?
I was about to leave this topic not to swamp the list with something that appears to go nowere. But now I feel that I must answer the comments, so here it goes. By agressive optimisation I mean an optimisation that drastically reduces run-time performance of (some part of) the program. So I guess automatic vectorisation could fall into this term. In my scenario the original programmer did not have any reason for the strange code -- it just happened. I'm sure we all write bad/suboptimal code sometimes. Hence there would be no comment describing this in the code. And compiling without optimisations would not prevent the above -- only if the original programmer(s) had compiled without optimisations but this was obviously not the case. We seem to agree that the only way to know what a change will do to the performance of a program is testing (using whatever tools are available). That is what makes me a bit uncomfortable because then we don't really understand it. Disabling all optimisations would definitely be a step backwards and not where we want to go. Then again, maybe this problem is mostly of theoretical concern and not at all common in practice. I guess it **is** far more likely that clean code will trigger optimisations. But we cannot really know for sure... Regards Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] xml conduit
OK, after some experimentation, I've decided that this would be something really cool, but I don't have the experience with lens to do it myself. Here's what I came up with so far: https://gist.github.com/snoyberg/4755679 (Also available on School of Haskell[1], but our version of lens is too old for this snippet.) So if someone wants to pursue this, I'd be really interested to see the results. Michael [1] https://haskell.fpcomplete.com/user/snoyberg/random-code-snippets/xml-conduit-lens On Mon, Feb 11, 2013 at 8:09 AM, Michael Sloan mgsl...@gmail.com wrote: I realized that the term payload wouldn't make much sense in the context of XML. What I meant was elementName with elementAttributes (but not elementNodes - that's the point). So, such navigations could yield a datatype containing those. -Michael On Sun, Feb 10, 2013 at 9:41 PM, Michael Sloan mgsl...@gmail.com wrote: Err: That first link into Zipper.hs should instead be: https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L66 On Sun, Feb 10, 2013 at 9:40 PM, Michael Sloan mgsl...@gmail.com wrote: I'm no lens authority by any means, but indeed, it looks like something like Cursor / Axis could be done with the lens zipper. https://github.com/snoyberg/xml/blob/0367af336e86d723bd9c9fbb49db0f86d1f989e6/xml-enumerator/Text/XML/Cursor/Generic.hs#L38 This cursor datatype is very much like the (:) zipper type (I'm linking to old code, because that's when I understood it - the newer stuff is semantically the same, but more efficient, more confusing, and less directly relatable): https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L317 Which is built out of the following two datatypes: 1) parent (and the way to rebuild the tree on the way back up) is provided by this datatype: https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L74 2) precedingSibling / followingSibling / node is provided by this datatype (which is pretty much the familiar list zipper!): https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L317 One way that this would be powerful is that some of the Axis constructors could return a zipper. In particular, all of the axis yielding functions except the following would be supported: parent, precedingSibling, followingSibling, ancestor, descendent, orSelf, check This is because zippers can be used for modification, which doesn't work out very well when you can navigate to something outside of your focii's children. If we have a new datatype, that represents a node's payload, then we could conceivably represent all of the axis yielding operations except for parent / ancestor. However, those operations would be navigations to payloads - further xml-hierarchy level navigation would be impossible because you'd no longer have references to children. (further navigation into payloads on the other hand, would still be possible) So, that's just my thoughts after looking at it a bit - I hope it's comprehensible / helpful! An XML zipper would be pretty awesome. -Michael On Sun, Feb 10, 2013 at 8:34 PM, Michael Snoyman mich...@snoyman.comwrote: On Sun, Feb 10, 2013 at 8:51 PM, grant the...@hotmail.com wrote: Michael Snoyman michael at snoyman.com writes: Hi Michael, Just one last thought. Does it make any sense that xml-conduit could be rewritten as a lens instead of a cursor? Or leverage the lens package somehow? That's a really interesting idea, I'd never thought about it before. It's definitely something worth playing around with. However, I think in this case the Cursor is providing a totally different piece of functionality than what lenses would do. The Cursor is really working as a Zipper, allowing you to walk the node tree and do queries about preceding and following siblings and ancestors. Now given that every time I'm on #haskell someone mentions zippers in the context of lens, maybe lens *would* solve this use case as well, but I'm still a lens novice (if that), so I can't really speak on the matter. Maybe someone with more lens experience could provide some insight. Either way, some kind of lens add-on sounds really useful. Michael ___ 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] Error: junk while building GHC
Hi all, I'm trying to build GHC HEAD snapshot 7.7.20130210, I have the following error: inplace/bin/ghc-stage1 -optc-Ilibraries/ghc-prim/. -optc-I'/home/cdupont/Haskell/ghc-7.7.20130210/rts/dist/build' -optc-I'/home/cdupont/Haskell/ghc-7.7.20130210/includes' -optc-I'/home/cdupont/Haskell/ghc-7.7.20130210/includes/dist-derivedconstants/header' -fPIC -dynamic -H32m -O-package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts -c libraries/ghc-prim/cbits/debug.c -o libraries/ghc-prim/dist-install/build/cbits/debug.dyn_o debug.c: Assembler messages: debug.c:12:0: Error: junk `.get_pc_thunk.bx' after expression debug.c:41:0: Error: junk `.get_pc_thunk.bx' after expression debug.c:63:0: Error: junk at end of line, first unrecognized character is `1' debug.c:64:0: Error: junk at end of line, first unrecognized character is `1' debug.c:65:0: Error: Missing symbol name in directive debug.c:65:0: Error: junk at end of line, first unrecognized character is `1' debug.c:66:0: Error: Missing symbol name in directive debug.c:66:0: Error: junk at end of line, first unrecognized character is `.' debug.c:67:0: Error: junk at end of line, first unrecognized character is `1' The file debug.c is not even 12 lines long (and it looks correct)... Any ideas? Thanks, Corentin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Google Summer of Code 2013
Hi all, Summer of code has always been a good way for us to get some important work, that no one has time to do, done. I encourage everyone to come up with good summer of code projects so we have a good number when the time for students to apply comes around. Empirically projects that focus on existing infrastructure (e.g. Cabal) work well. They limit the scope enough for students to 1) make something that's impacts lots of people and 2) doesn't give them too much rope*. * Building something good from scratch requires lots of experience, something most students don't have, almost per definition. -- Johan -- Forwarded message -- From: Carol Smith car...@google.com Date: Mon, Feb 11, 2013 at 11:02 AM Subject: Google Summer of Code 2013 To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its ninth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. [1] - http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page [3] - http://www.google-melange.com/gsoc/events/google/gsoc2013 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-announce+unsubscr...@googlegroups.com. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. Visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. For more options, visit https://groups.google.com/groups/opt_out. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Announcement] HsLlvm v0.1: Using Hoopl to optimize LLVM Code
My focus is on - Providing util to support developing LLVM-LLVM transformation - Providing EDSL to generate LLVM code (I'm thinking of something like alphaHeavy's LLVM combinators) I'm not aware of other effort to do native code generation from LLVM in Haskell. You can build them with HsLlvm, if there is a need to support your work, please let me know. I believe the new GHC code generator is based on Hoopl, you might get inspiration from it. Cheers, Ning On 02/11/2013 03:13 AM, Alejandro Serrano Mena wrote: Hi, This seems a fantastic job! Do you have any plan to support LLVM - target phase, or do you know any project doing something similar? Thanks in advance. 2013/2/11 Ning Wang em...@ningwang.org mailto:em...@ningwang.org Hi all, It is my dream for years to be able to manipulate LLVM in type safe language. I has explored the possibility of reimplementing LLVM in Haskell with Hoopl and made a small step to realize this dream. I am writing to announce the release of HsLlvm v0.1, which is a pure Haskell implementation (Not LLVM C++ binding) of LLVM. It is available through the link below. https://github.com/mlite/HsLlvm Hightlight of this release: - Support LLVM 3.1 syntax - LLVM normalization - Dominator, mem2reg, DCE passes Project goals: - port all LLVM optimizations - provide functionalities to generate and manipulate LLVM code. Since LLVM is a complex IR and there are many sophisticated optimizations, this job won't be easy. Your contribution would be of value to eventually achieve this goal. Cheers, Ning ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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] [Announcement] HsLlvm v0.1: Using Hoopl to optimize LLVM Code
Hey Ning, impressive start and I look forward to seeing how this evolves! best -Carter On Tue, Feb 12, 2013 at 12:37 AM, Ning Wang em...@ningwang.org wrote: My focus is on - Providing util to support developing LLVM-LLVM transformation - Providing EDSL to generate LLVM code (I'm thinking of something like alphaHeavy's LLVM combinators) I'm not aware of other effort to do native code generation from LLVM in Haskell. You can build them with HsLlvm, if there is a need to support your work, please let me know. I believe the new GHC code generator is based on Hoopl, you might get inspiration from it. Cheers, Ning On 02/11/2013 03:13 AM, Alejandro Serrano Mena wrote: Hi, This seems a fantastic job! Do you have any plan to support LLVM - target phase, or do you know any project doing something similar? Thanks in advance. 2013/2/11 Ning Wang em...@ningwang.org Hi all, It is my dream for years to be able to manipulate LLVM in type safe language. I has explored the possibility of reimplementing LLVM in Haskell with Hoopl and made a small step to realize this dream. I am writing to announce the release of HsLlvm v0.1, which is a pure Haskell implementation (Not LLVM C++ binding) of LLVM. It is available through the link below. https://github.com/mlite/HsLlvm Hightlight of this release: - Support LLVM 3.1 syntax - LLVM normalization - Dominator, mem2reg, DCE passes Project goals: - port all LLVM optimizations - provide functionalities to generate and manipulate LLVM code. Since LLVM is a complex IR and there are many sophisticated optimizations, this job won't be easy. Your contribution would be of value to eventually achieve this goal. Cheers, Ning ___ 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
