Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
On Tue, Dec 27, 2011 at 7:23 AM, Sebastian Fischer wrote: > 2011/12/26 Eugene Kirpichov > >> Whoa. Sebastian, you're my hero — I've been struggling with defining >> Arrow for ListTransformer for a substantial time without success, and here >> you got it, dramatically simpler than I thought it could be done (I was >> using explicit queues). >> > > This stuff is tricky. I noticed that my Applicative instance did not > satisfy all required laws. I think I could fix this by changing the > implementation of pure to > > pure x = Put x $ pure x > > in analogy to the ZipList instance. At least, QuickCheck does not complain > anymore (I did not write proofs). > > The original definition of `pure` was inspired by Chris Smith's post on > the connection of Category/Applicative and Arrow: > > > http://cdsmith.wordpress.com/2011/08/13/arrow-category-applicative-part-iia/ > > However, even with the fixed Applicative instance, the Arrow instance does > not satisfy all laws. ListTransformer seems to be a type that has valid > Category and Applicative instances which do not give rise to a valid Arrow > instance as outlined by Chris. One of his additional axioms relating > Category and Applicative does not hold. > > I have extended the (corrected) code with QuickCheck tests: > > https://gist.github.com/1521467 > Thanks, I'll take a look. > > I wonder if now this datatype of yours is isomorphic to StreamSummary b >> r -> StreamSummary a r. >> > > Not sure what you mean here. StreamSummary seems to be the same as > ListConsumer but I don't see how functions from consumers to consumers are > list transformers, i.e., functions from lists to lists. > Well. They are isomorphic, if list transformers are represented as functions from lists. I'm assuming they could be with the other representation too. type ListT a b = forall r . ([b] -> r) -> ([a] -> r) there :: ([a] -> [b]) -> ListT a b there as2bs bs2r = bs2r . as2bs back :: ListT a b -> ([a] -> [b]) back f = f id > > Sebastian > -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
2011/12/24 MigMit > > > Отправлено с iPad > > 24.12.2011, в 18:50, Alexander Solla написал(а): > > In the same way, denotational semantics adds features which do not apply > to a theory of finite computation. > > > And why exactly should we limit ourselves to some theory you happen to > like? > Because the question was about MY IDEAL. I have spoken at length why my ideal is preferable to the current state of affairs. You still continue to misunderstand my point, and respond with red herrings. >> > The /defining/ feature of a bottom is that it doesn't have an >> interpretation. >> > >> What do you mean by "interpretation"? >> > > You know, the basic notion of a function which maps syntax to concrete > values. > > http://en.wikipedia.org/wiki/Model_theory > > > But (_|_) IS a concrete value. > Um, perhaps in denotational semantics. But even in that case, it is not a HASKELL value. You seem to be mixing up syntax and semantics. > > But they ARE very similar to other values. They can be members of >> otherwise meaningful structures, and you can do calculations with these >> structures. "fst (1, _|_)" is a good and meaningful calculation. > > > Mere syntax. > > > So what? > So we give meaning to syntax through our semantics. That is what this whole conversation is all about. I am proposing we give Haskell bottoms semantics that bring it in line with the bottoms from various theories including lattice theory, the theory of sets, the theory of logic, as opposed to using denotational semantics' bottom semantic, which is unrealistic for a variety of reasons. Haskell bottoms can't be compared, due to Rice's theorem. Haskell bottoms cannot be given an interpretation as a Haskell value. What happens to referential transparency when distinct things are all defined by the same equation? ... = let x = x in x undefined, seq, unsafeCoerce, and many other "primitives" are defined using that equation. (See GHC.Prim) The Haskell definition for these distinct things /does nothing/. It loops. The semantics we get for them (an error message if we use undefined, a causal side-effect if we use seq, type coercion if we use unsafeCoerce) is done /magically/ by the compiler. As far as Haskell, as a language, is concerned, all of these are bottom, and they are all /equal/, because of referential transparency/substitutionality. Oops. So Haskell, as a logic, is telling us that all of these "distinct" bottoms are not so distinct. And that any interpretation function providing semantics should map them all to the same value in the model. > Every other Haskell value /does/ have an interpretation. >> >> So, (_|_) is bad, but (1, _|_) is good? > > > I did not introduce "good" and "bad" into this discussion. I have merely > said (in more words) that I want my hypothetical perfect language to prefer > OPERATIONAL (model) SEMANTICS for a typed PARACONSISTENT LOGIC over the > DENOTATIONAL SEMANTICS which the official documentation sometimes dips into. > > > Well, that's a different story. > No, it's the same story that I've been telling. > But it seems to me that the term "Haskell-like" won't apply to that kind > of language. Also, it seems to me (though I don't have any kind of proof) > that denotational semantics is something that is much simpler. > Haskell is already a paraconsistent logic. How is giving Haskell operational and interpretive semantics not "Haskell-like"? Its denotational semantics is a platonic completion of the logical semantics. > > It is clear that denotational semantics is a Platonic model of > constructive computation. > > > Could you please stop offending abstract notions? > What? Platonic does not mean "bad". But it does mean that the theory is "too big" to be appropriate in this case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
2011/12/26 Eugene Kirpichov > Whoa. Sebastian, you're my hero — I've been struggling with defining Arrow > for ListTransformer for a substantial time without success, and here you > got it, dramatically simpler than I thought it could be done (I was using > explicit queues). > This stuff is tricky. I noticed that my Applicative instance did not satisfy all required laws. I think I could fix this by changing the implementation of pure to pure x = Put x $ pure x in analogy to the ZipList instance. At least, QuickCheck does not complain anymore (I did not write proofs). The original definition of `pure` was inspired by Chris Smith's post on the connection of Category/Applicative and Arrow: http://cdsmith.wordpress.com/2011/08/13/arrow-category-applicative-part-iia/ However, even with the fixed Applicative instance, the Arrow instance does not satisfy all laws. ListTransformer seems to be a type that has valid Category and Applicative instances which do not give rise to a valid Arrow instance as outlined by Chris. One of his additional axioms relating Category and Applicative does not hold. I have extended the (corrected) code with QuickCheck tests: https://gist.github.com/1521467 I wonder if now this datatype of yours is isomorphic to StreamSummary b r > -> StreamSummary a r. > Not sure what you mean here. StreamSummary seems to be the same as ListConsumer but I don't see how functions from consumers to consumers are list transformers, i.e., functions from lists to lists. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How hard is it to start a web startup using Haskell?
Turns out that those guys doing start-up with Haskell are already expert at Haskell. Hence choosing Haskell is more straightforward. I'm thinking of using Haskell since it looks cool and beautiful. However I have little experience and will move slowly at certain begging period. This sounds not good to a startup company. Comparing with Django in Python, Rails in Ruby, yesod and snap looks not that mature. Also, for instance, I'd like to build up a CRM application company, I could leverage some open source projects in other languages. In Haskell, we need to build from scratch basically. Appreciate your suggestions/comments. -Simon On Wed, Dec 21, 2011 at 2:30 AM, David Pollak wrote: > > > On Mon, Dec 19, 2011 at 2:36 PM, Yves Parès wrote: > >> > Haskell is a mature platform that provides lots of goodies that I might >> otherwise have to write (like the goodies I wrote in Lift including an >> Actors library) >> >> I don't get it: Actors are at the core of Scala concurrency model, > > > Actors as implemented in the Scala distribution were (and probably still > are) horrid. They have poor performance, memory retention issues, and an > overall poor design. When Lift relied on Scala's Actors, a Lift-comet site > needed to be restarted every few weeks because of pent-up memory issues. > On the other hand, with Lift Actors, http://demo.liftweb.net has been > running since July 7th. > > >> and are expanded for distributed programming through Akka for instance. >> > > Actually, no. Scala's Actors are not expanded by Akka (although Akka > Actors may replace the existing Actor implementation in the Scala library). > Akka is yet another replacement for Scala's Actor library and Akka's > distributed capabilities are weak and brittle. Also, Lift's Actor library > and Martin Odersky's flames about it paved the way for Akka because I took > the heat that might have driven Jonas out of the Scala community when Akka > was a small project. > > >> To me it'd be the other way around: you'd have to develop Actors in >> Haskell, don't you? >> > > I've come to understand that Actors are a weak concurrency/distribution > paradigm. Anything that has a type signature Any => Unit is not composable > and will lead to the same kinds of issues that we're looking for the > compiler in Haskell to help us with (put another way, if you like Smalltalk > and Ruby, then Actors seem pretty cool.) > > On the other hand, many of Haskell's libraries (STM, Iteratees, etc.) have > a much more composable set of concurrency primitives. > > >> Or maybe you don't mean the same thing by 'Actor'? >> >> >> 2011/12/19 David Pollak >> >>> On Mon, Dec 19, 2011 at 2:04 AM, Ivan Perez < >>> ivanperezdoming...@gmail.com> wrote: >>> I'm actually trying to make a list of companies and people using Haskell for for-profit real world software development. I'd like to know the names of those startups, if possible. >>> >>> I am building http://visi.pro on Haskell. I am doing it for a number >>> of reasons: >>> >>>- Haskell is a mature platform that provides lots of goodies that I >>>might otherwise have to write (like the goodies I wrote in Lift including >>>an Actors library) >>>- Haskell allows a lot of nice "things" that make building a >>>language and associated tools easier (like laziness) >>>- Haskell is a filter for team members. Just like Foursquare uses >>>Scala as a filter for candidates in recruiting, I'm using Haskell as a >>>filter... if you have some good Haskell open source code, it's a way to >>>indicate to me that you're a strong developer. >>> >>> >>> -- Ivan On 18 December 2011 18:42, Michael Snoyman wrote: > On Sun, Dec 18, 2011 at 6:57 PM, Gracjan Polak < gracjanpo...@gmail.com> wrote: >> >> Hi all, >> >> The question 'How hard is it to start a technical startup with Haskell?' >> happened a couple of times on this list. Sometimes it was in the form 'How hard >> is to find Haskell programmers?' or 'Are there any Haskell jobs?'. >> >> I'd like to provide one data point as an answer: >> >> http://www.reddit.com/r/haskell/comments/ngbbp/haskell_only_esigning_startup_closes_second_angel/ >> >> Full disclosure: I'm one of two that founded this startup. >> >> How are others doing businesses using Haskell doing these days? > > I don't run a startup myself, but I know of at least three startups > using Haskell for web development (through Yesod), and my company is > basing its new web products on Yesod as well. I think there are plenty > of highly qualified Haskell programmers out there, especially if > you're willing to let someone work remotely. > > Michael > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listi
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On 27 Dec 2011, at 01:02, Donn Cave wrote: > Quoth Hans Aberg, > ... >> For example, I set one entry so that typing x |-> a becomes x ↦ a, the >> TeX \mapsto, in Unicode ↦ RIGHTWARDS ARROW FROM BAR U+21A6. >> >> It might be tedious to make a lot of entries, though, but something to >> start with. > > Something to finish me with, too. I wouldn't be able to do much > in a programming world that used glyphs like that. The symbol I chose is the one normally used in math. You can see it here: https://en.wikipedia.org/wiki/Function_(mathematics) > My vision > isn't perfect, but I think it's within a fairly normal range, > and it isn't good enough to decode a lot of hieroglyphics at > normal font size at reading speed. Higher resolution displays might help, but larger ones are expected to come the next year. > The ASCII limit of 100 or so normal characters may be a barrier > to expression, but it's a boost to comprehension. Common combinations tend to evolve in symbols. The ASCII combinations are just makeshift. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
Sorry about the belated response, but this shouldn't be a problem since it isn't going to be very helpful anyway! I've managed to follow the process described on this page: http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project to link Haskell code to a non-Haskell main program, via Xcode. You've probably already seen this, it's mostly about a few iterations of trial and error linking, to get the list of GHC library dependencies, which is what you need whether you're using Xcode or not. If you really need a single library with your code and all those dependencies, that may be technically feasible, though awfully tedious. The only clear problem I encountered while experimenting with it is that GHC run time options need ghc -rtsopts, so they're unavailable if your program isn't built by ghc. I believe I worked around that with a special rtsmain.o, could probably recover the details if that's of interest. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
Quoth Hans Aberg, ... > For example, I set one entry so that typing x |-> a becomes x ⦠a, the > TeX \mapsto, in Unicode ⦠RIGHTWARDS ARROW FROM BAR U+21A6. > > It might be tedious to make a lot of entries, though, but something to > start with. Something to finish me with, too. I wouldn't be able to do much in a programming world that used glyphs like that. My vision isn't perfect, but I think it's within a fairly normal range, and it isn't good enough to decode a lot of hieroglyphics at normal font size at reading speed. The ASCII limit of 100 or so normal characters may be a barrier to expression, but it's a boost to comprehension. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On 26 Dec 2011, at 23:03, Brandon Allbery wrote: > > But if you are under Windows, or Mac OS, I cannot tell (as well as I > > cannot tell if you are under a POSIX system not running xorg, such as > > the tty1..ttyn consoles) > > On OS X one can make ones owns key maps, like with the program on the link > below, but it is very time consuming. > > System Preferences > Personal > Language & Text > Text > Use symbol and text > substitution Cool. I have a vague memory of seeing it, but not paying much attention to it. One can turn it on in Xcode 4.2 by Edit -> Format -> Substitutions -> Show Substitutions and click Text Replacement or selecting it directly in the Substitutions menu. This popup windows allows one to apply it a text selection. (And similar in other programs, like Mail.) For example, I set one entry so that typing x |-> a becomes x ↦ a, the TeX \mapsto, in Unicode ↦ RIGHTWARDS ARROW FROM BAR U+21A6. It might be tedious to make a lot of entries, though, but something to start with. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Mon, Dec 26, 2011 at 12:20, Hans Aberg wrote: > On 26 Dec 2011, at 16:11, AUGER Cédric wrote: > > But if you are under Windows, or Mac OS, I cannot tell (as well as I > > cannot tell if you are under a POSIX system not running xorg, such as > > the tty1..ttyn consoles) > > On OS X one can make ones owns key maps, like with the program on the link > below, but it is very time consuming. > System Preferences > Personal > Language & Text > Text > Use symbol and text substitution -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-exhaustive pattern match warning (incorrect?)
On 12/26/2011 03:17 PM, Antoine Latter wrote:
The error is warning you that the record update 'oct { b8 = bit }' can
fail at run-time if 'oct' is None.
Since it looks like you've checked for that you shouldn't have a
problem, but the compiler doesn't know that.
Thanks, that's what I thought but I wanted to make sure I wasn't missing
something obvious.
If you decompose your type into 'Octet' without the 'None' case, and
'Maybe Octet' for the times when 'None' is appropriate, the compiler
will have enough information to not give warnings like this.
I can't be the one to tell you if that is worth it or not.
I must have had a good reason to do it that way, right? =)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] HaskellNet has a new maintainer
Hi all, I recently took over maintenance duties for the HaskellNet library from its previous maintainer, Robert Wills: http://hackage.haskell.org/package/HaskellNet The codebase has been moved to GitHub: https://github.com/jtdaugherty/HaskellNet So far my focus on HaskellNet has been code cleanup and pruning. Once I'm confident I didn't introduce any silly bugs, I'll do a new release on Hackage. After that, I plan to: - Write protocol tests against scripted installations of popular implementations, such as Dovecot - Split up HaskellNet into SMTP, IMAP, and POP packages So, if you are a HaskellNet user and have an interest in these changes, speak up! In addition, if you are interested in maintaining one or more of the resulting smaller packages (especially POP), let me know! Thanks, -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-exhaustive pattern match warning (incorrect?)
On Mon, Dec 26, 2011 at 2:19 PM, Michael Orlitzky wrote:
> On 12/26/11 13:42, Antoine Latter wrote:
>>>
>>> Am I overlooking something, or did I already match Octet.None?
>>>
>>
>> What is your definition of the 'Octet' type?
>>
>
> -- An Octet consists of eight bits. For our purposes, the most
> -- significant bit will come "first." That is, b1 is in the 2^7
> -- place while b8 is in the 2^0 place.
> data Octet = None | Octet { b1 :: Bit,
> b2 :: Bit,
> b3 :: Bit,
> b4 :: Bit,
> b5 :: Bit,
> b6 :: Bit,
> b7 :: Bit,
> b8 :: Bit }
> deriving (Eq)
>
The error is warning you that the record update 'oct { b8 = bit }' can
fail at run-time if 'oct' is None.
Since it looks like you've checked for that you shouldn't have a
problem, but the compiler doesn't know that.
If you decompose your type into 'Octet' without the 'None' case, and
'Maybe Octet' for the times when 'None' is appropriate, the compiler
will have enough information to not give warnings like this.
I can't be the one to tell you if that is worth it or not.
Antoine
>
> ___
> 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] If you'd design a Haskell-like language, what would you do different?
On 26 Dec 2011, at 19:29, AUGER Cédric wrote: > Le Mon, 26 Dec 2011 18:20:55 +0100, > Hans Aberg a écrit : > >> On 26 Dec 2011, at 16:11, AUGER Cédric wrote: >> >>> Under Xorg, "XCompose" might be your friend! I have a whole bunch of >>> them for Coq programing. >>> >>> Having something like: >>> >>> -8<- >>> # ~/.XCompose contents: >>> >>> # the Compose file of the xorg distribution to have a lot >>> # of useful symbols such as "☭" ^^ >>> include "/usr/local/lib/X11/locale/en_US.UTF-8/Compose" >>> # the Compose file that could be included in Haskell distributions >>> include "/usr/local/share/haskell/Compose" >>> # other personnal notations >>> --->8--- >>> # /usr/local/share/haskell/Compose contents: >>> >>> # maybe to be downloaded via a Hackage cabal package? >>> # of course " " should be replaced by a >>> # user specified combo >>> : "∷" >>> : "⋙" >>> : "⋘" >>> : "↢" U2919 >>> : "↣" U291A >>> : U291B >>> : U291C >>> : "∀" >>> : "∃" >>> : "∧" >>> : "∨" >>> : "λ" >>> : "∘" >>> : "→" >>> 8<-- >>> >>> But if you are under Windows, or Mac OS, I cannot tell (as well as I >>> cannot tell if you are under a POSIX system not running xorg, such >>> as the tty1..ttyn consoles) >> >> On OS X one can make ones owns key maps, like with the program on the >> link below, but it is very time consuming. >> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ukelele >> > I have heard of ukelele (but I didn't remembered the name as I am not > a Mac OS user); I have heard it was a rather dirty solution, but that > should work. I think so, too. > I guess that having a Haskell (or any script language by > the way) patching the xml file (and able to "unpatch" if we want to > uninstall) and make possible to get that patch via Hackage could be a > solution (it would be time consuming for the patch writer, but then > any Mac OS user would benefit it). > > Of course it would only work for the basic Haskell notations, for > custom ones, I guess it would be interesting to have a program which > reads a "XCompose like" file (which is quite easy to edit) and generate > the xml file for ukelele. > > Note that the rest of the Haskell cafe mailing list won't be able to > read my response since it seems that I cannot post on the list (I > subscribed 2 years ago and never posted; waiting to learn and Haskell > and then read the mailing list, but I learnt Haskell only about one > month ago). If one had a way to replace ASCII multicharacter symbols, that might be easier. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-exhaustive pattern match warning (incorrect?)
On 12/26/11 13:42, Antoine Latter wrote:
>>
>> Am I overlooking something, or did I already match Octet.None?
>>
>
> What is your definition of the 'Octet' type?
>
-- An Octet consists of eight bits. For our purposes, the most
-- significant bit will come "first." That is, b1 is in the 2^7
-- place while b8 is in the 2^0 place.
data Octet = None | Octet { b1 :: Bit,
b2 :: Bit,
b3 :: Bit,
b4 :: Bit,
b5 :: Bit,
b6 :: Bit,
b7 :: Bit,
b8 :: Bit }
deriving (Eq)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-exhaustive pattern match warning (incorrect?)
On Mon, Dec 26, 2011 at 1:21 PM, Michael Orlitzky wrote:
> I'm cleaning up some old projects, and hit this:
>
> src/Octet.hs:47:27:
> Warning: Pattern match(es) are non-exhaustive
> In a record-update construct: Patterns not matched: Octet.None
>
> But in the source, I've checked for that case:
>
> class Maskable a where
> apply_mask :: a -> Maskbits -> Bit -> a
>
> instance Maskable Octet where
> apply_mask _ Maskbits.None _ = Octet.None
> apply_mask Octet.None _ _ = Octet.None
> apply_mask oct mask bit
> | mask == Eight = oct
> | mask == Seven = oct { b8 = bit } -- Line 47
> ...
> | otherwise = Octet.None
>
>
> Am I overlooking something, or did I already match Octet.None?
>
What is your definition of the 'Octet' type?
> ___
> 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] Non-exhaustive pattern match warning (incorrect?)
I'm cleaning up some old projects, and hit this:
src/Octet.hs:47:27:
Warning: Pattern match(es) are non-exhaustive
In a record-update construct: Patterns not matched: Octet.None
But in the source, I've checked for that case:
class Maskable a where
apply_mask :: a -> Maskbits -> Bit -> a
instance Maskable Octet where
apply_mask _ Maskbits.None _ = Octet.None
apply_mask Octet.None _ _= Octet.None
apply_mask oct mask bit
| mask == Eight = oct
| mask == Seven = oct { b8 = bit } -- Line 47
...
| otherwise = Octet.None
Am I overlooking something, or did I already match Octet.None?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On 26 Dec 2011, at 16:11, AUGER Cédric wrote: >> There is >> http://www.stixfonts.org/ >> For typesetting with Xe[La]TeX or Lua[La]TeX, use XITS (in the >> TeXLive package). >> >>> (And then we'll have to deal with folks trying to use the letter, >>> because everyone knows the Roman alphabet is the only one that >>> matters and of *course* Greek letters are symbol characters >>> Pfeh.) >> >> This is the big problem right now: how to enter these symbols >> efficiently. > > Under Xorg, "XCompose" might be your friend! I have a whole bunch of > them for Coq programing. > > Having something like: > > -8<- > # ~/.XCompose contents: > > # the Compose file of the xorg distribution to have a lot > # of useful symbols such as "☭" ^^ > include "/usr/local/lib/X11/locale/en_US.UTF-8/Compose" > # the Compose file that could be included in Haskell distributions > include "/usr/local/share/haskell/Compose" > # other personnal notations > --->8--- > # /usr/local/share/haskell/Compose contents: > > # maybe to be downloaded via a Hackage cabal package? > # of course " " should be replaced by a > # user specified combo > : "∷" > : "⋙" > : "⋘" > : "↢" U2919 > : "↣" U291A > : U291B > : U291C > : "∀" > : "∃" > : "∧" > : "∨" > : "λ" > : "∘" > : "→" > 8<-- > > But if you are under Windows, or Mac OS, I cannot tell (as well as I > cannot tell if you are under a POSIX system not running xorg, such as > the tty1..ttyn consoles) On OS X one can make ones owns key maps, like with the program on the link below, but it is very time consuming. Hans http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ukelele ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
Whoa. Sebastian, you're my hero — I've been struggling with defining Arrow for ListTransformer for a substantial time without success, and here you got it, dramatically simpler than I thought it could be done (I was using explicit queues). I wonder if now this datatype of yours is isomorphic to StreamSummary b r -> StreamSummary a r. 26.12.2011, в 19:56, Sebastian Fischer написал(а): > On Sun, Dec 25, 2011 at 11:25 AM, Heinrich Apfelmus > wrote: > Your StreamSummary type has a really nice interpretation: it's a > reification of case expressions [on lists]. > > nice observation! > > For instance, consider the following simple function from lists to integers > >length :: [a] -> Int >length xs = case xs of >[] -> 0 >(y:ys) -> 1 + length ys > > We want to reify the case expression as constructor of a data type. [...] > >data ListTo a r = CaseOf r (a -> ListTo a r) > >interpret :: ListTo a r -> ([a] -> r) >interpret (CaseOf nil cons) xs = >case xs of >[] -> nil >(y:ys) -> interpret (cons y) ys > > [...] > > Likewise, each function from lists can be represented in terms of our new > data type [...] > >length' :: ListTo a Int >length' = CaseOf >(0) >(\x -> fmap (1+) length') > >length = interpret length' > > This version of `length` is tail recursive while the previous version is not. > In general, all functions defined in terms of `ListTo` and `interpret` are > spine strict - they return a result only after consuming all input list > constructors. > > This is what Eugene observed when defining the identity function as > > idC = CaseOf [] (\x -> (x:) <$> idC) > > This version does not work for infinite lists. Similarly, `head` and `take` > cannot be defined as lazily as in the standard libraries. > > We can support lazier list consumers by adding a case to the ListTo type that > allows to stop consuming the list. To avoid confusion, I chose new names for > my new types. > > data ListConsumer a b > = Done !b > | Continue !b (a -> ListConsumer a b) > > The interpretation function just ignores the remaining input in the case of > `Done`: > > consumeList :: ListConsumer a b -> [a] -> b > consumeList (Done b) _ = b > consumeList (Continue b _) [] = b > consumeList (Continue _ f) (x:xs) = consumeList (f x) xs > > We can define lazier versions of `head` and `take` as follows: > > headC :: ListConsumer a a > headC = Continue (error "head of empty list") Done > > takeC :: Int -> ListConsumer a [a] > takeC 0 = Done [] > takeC n = Continue [] (\x -> (x:) <$> takeC (n-1)) > > However, we still cannot define a lazy version of the identity funtion with > list consumers. > > The identity function and `takeC` belong to a special case of a list > consumers because they also *produce* lists. We can define a specialized type > for list transformers that consume and produce lists. One advantage of this > specialization will be that we can define a lazy version of the identity > function. The transformer type can have functor and applicative instances > similar to the consumer type to compose transformers in parallel. > Additionally, it can have category and arrow instances to compose > transformers sequentially. > > Here is a type for lazy list transformers: > > data ListTransformer a b > = Cut > | Put b (ListTransformer a b) > | Get (a -> ListTransformer a b) > > A transformer can either cut off the input list and return the empty list, > output a new element before transforming the input, or consume one element > from the input list and transform the remaining elements. The interpretation > function should make this clearer: > > transformList :: ListTransformer a b -> [a] -> [b] > transformList Cut _ = [] > transformList (Put b t) xs = b : transformList t xs > transformList (Get _) [] = [] > transformList (Get f) (x:xs) = transformList (f x) xs > > Note that, if the transformer wants to read another element that is not > there, it simply returns the empty list. > > Now we can define a lazy identity function and another version of `take`: > > idT :: ListTransformer a a > idT = Get (\x -> Put x idT) > > takeT :: Int -> ListTransformer a a > takeT 0 = Cut > takeT n = Get (\x -> Put x (takeT (n-1))) > > Here is another translation of a common list function: > > filterT :: (a -> Bool) -> ListTransformer a a > filterT p = Get (\x -> if p x then Put x (filterT p) else filterT p) > > `filterT` is an example for a function that can consume several input > elements before producing an output element. Other examples for functions of > this kind are chunking functions: > > pairsT :: ListTransformer a (a,a) > pairsT = Get (\x -> Get (\y -> Put (x,y) pairsT)) > > chunks :: Int -> ListTra
Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
On Sun, Dec 25, 2011 at 11:25 AM, Heinrich Apfelmus < apfel...@quantentunnel.de> wrote: > > Your StreamSummary type has a really nice interpretation: it's a > reification of case expressions [on lists]. > nice observation! > For instance, consider the following simple function from lists to integers > >length :: [a] -> Int >length xs = case xs of >[] -> 0 >(y:ys) -> 1 + length ys > > We want to reify the case expression as constructor of a data type. [...] > >data ListTo a r = CaseOf r (a -> ListTo a r) > >interpret :: ListTo a r -> ([a] -> r) >interpret (CaseOf nil cons) xs = >case xs of >[] -> nil >(y:ys) -> interpret (cons y) ys > > [...] > > Likewise, each function from lists can be represented in terms of our new > data type [...] > >length' :: ListTo a Int >length' = CaseOf >(0) >(\x -> fmap (1+) length') > >length = interpret length' > This version of `length` is tail recursive while the previous version is not. In general, all functions defined in terms of `ListTo` and `interpret` are spine strict - they return a result only after consuming all input list constructors. This is what Eugene observed when defining the identity function as idC = CaseOf [] (\x -> (x:) <$> idC) This version does not work for infinite lists. Similarly, `head` and `take` cannot be defined as lazily as in the standard libraries. We can support lazier list consumers by adding a case to the ListTo type that allows to stop consuming the list. To avoid confusion, I chose new names for my new types. data ListConsumer a b = Done !b | Continue !b (a -> ListConsumer a b) The interpretation function just ignores the remaining input in the case of `Done`: consumeList :: ListConsumer a b -> [a] -> b consumeList (Done b) _ = b consumeList (Continue b _) [] = b consumeList (Continue _ f) (x:xs) = consumeList (f x) xs We can define lazier versions of `head` and `take` as follows: headC :: ListConsumer a a headC = Continue (error "head of empty list") Done takeC :: Int -> ListConsumer a [a] takeC 0 = Done [] takeC n = Continue [] (\x -> (x:) <$> takeC (n-1)) However, we still cannot define a lazy version of the identity funtion with list consumers. The identity function and `takeC` belong to a special case of a list consumers because they also *produce* lists. We can define a specialized type for list transformers that consume and produce lists. One advantage of this specialization will be that we can define a lazy version of the identity function. The transformer type can have functor and applicative instances similar to the consumer type to compose transformers in parallel. Additionally, it can have category and arrow instances to compose transformers sequentially. Here is a type for lazy list transformers: data ListTransformer a b = Cut | Put b (ListTransformer a b) | Get (a -> ListTransformer a b) A transformer can either cut off the input list and return the empty list, output a new element before transforming the input, or consume one element from the input list and transform the remaining elements. The interpretation function should make this clearer: transformList :: ListTransformer a b -> [a] -> [b] transformList Cut _ = [] transformList (Put b t) xs = b : transformList t xs transformList (Get _) [] = [] transformList (Get f) (x:xs) = transformList (f x) xs Note that, if the transformer wants to read another element that is not there, it simply returns the empty list. Now we can define a lazy identity function and another version of `take`: idT :: ListTransformer a a idT = Get (\x -> Put x idT) takeT :: Int -> ListTransformer a a takeT 0 = Cut takeT n = Get (\x -> Put x (takeT (n-1))) Here is another translation of a common list function: filterT :: (a -> Bool) -> ListTransformer a a filterT p = Get (\x -> if p x then Put x (filterT p) else filterT p) `filterT` is an example for a function that can consume several input elements before producing an output element. Other examples for functions of this kind are chunking functions: pairsT :: ListTransformer a (a,a) pairsT = Get (\x -> Get (\y -> Put (x,y) pairsT)) chunks :: Int -> ListTransformer a [a] chunks n = collect n where collect 0 = Put [] (chunks n) collect m = Get (\x -> collect (m-1) >>> Get (\xs -> Put (x:xs) id)) Here are some example calls in GHCi that demonstrate the category and applicative instances for sequential and parallel composition (see below for a link to the complete source code): ghci> transformList pairsT [1..5] [(1,2),(3,4)]-- 5 is ignored ghci> transformList pairsT [1..6] [(1,2),(3,4),(5,6)] ghci> transformList (chunks 2) [1..5] [[1,2],[3,4]]
[Haskell-cafe] Convert Double to Data.Fixed
Hi cafe, How do I most efficiently convert a Double to a Data.Fixed? I'm asking because I want to convert fractional seconds to the seconds field of Data.Time.TimeOfDay, which is Pico = Data.Fixed.Fixed E12. For now the fastest thing I came up with was fromIntegral (round (sec*100)) / fromIntegral 100, but this frankly sucks and is rather slow, there must be a better way. -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parListChunk problem
Hi there, I was not able to parallelize the below code by "parListChunk" strategy. Actually, code works fine without ant mistake in the result but no improvement in the performance handled. Threadscope demonstrates that parallelization happens after the sequential run of the program which is meaningless. In short, parListChunk is not working as intended. As far as I know, it should divide an arbitrarily given list into its chunks and then apply the given function to each sub-list (chunk) in parallel with reducing the evaluation of each element of each chunk into head normal form, if you use "rdeepseq" as the input strategy. In the below code, I want to divide the given list into 2000 chunks and then apply "ersa" function to each chunk in parallel with evaluating each element into its head normal form in serial internally. However, as I wrote, it first runs in serial after than the parallel scenario I admire to happen at the beginning happens. How can I solve this problem? Thanks in advance, Burak. ersa :: RSAPublicKey -> [Integer] -> [Integer] ersa (PUB n e) (x:xs) = ersa (PUB n e) (xs) ++ [expm n x e] ersa (PUB n e) [] = [] splitToEnc :: RSAPublicKey -> [Integer] -> [Integer] splitToEnc (PUB n e) [] = [] splitToEnc (PUB n e) (x:xs) = (ersa (PUB n e) (x:xs)) `using` parListChunk 2000 rdeepseq ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
2011/12/26 Gábor Lehel > On Sun, Dec 25, 2011 at 9:19 PM, Eugene Kirpichov > wrote: > > Hello Heinrich, > > > > Thanks, that's sure some food for thought! > > > > A few notes: > > * This is indeed analogous to Iteratees. I tried doing the same with > > Iteratees but failed, so I decided to put together something simple of my > > own. > > * The Applicative structure over this stuff is very nice. I was thinking, > > what structure to put on - and Applicative seems the perfect fit. It's > also > > possible to implement Arrows - but I once tried and failed; however, I > was > > trying that for a more complex stream transformer datatype (a hybrid of > > Iteratee and Enumerator). > > * StreamSummary is trivially a bifunctor. I actually wanted to make it an > > instance of Bifunctor, but it was in the category-extras package and I > > hesitated to reference this giant just for this purpose :) Probably > > bifunctors should be in prelude. > > Edward Kmett has been splitting that up into a variety of smaller > packages, for instance: > > http://hackage.haskell.org/package/bifunctors Actually it's not a bifunctor - it's a functor in one argument and contrafunctor in the other. Is there a name for such a structure? > > > > * Whereas StreamSummary a r abstracts deconstruction of lists, the dual > > datatype (StreamSummary a r ->) abstracts construction; however I just > now > > (after looking at your first definition of length) understood that it is > > trivially isomorphic to the regular list datatype - you just need to be > > non-strict in the state - listify :: ListTo a [a] = CaseOf [] (\x -> fmap > > (x:) listify). So you don't need functions of the form (forall r . > ListTo a > > r -> ListTo b r) - you just need (ListTo b [a]). This is a revelation for > > me. > > > > On Sun, Dec 25, 2011 at 2:25 PM, Heinrich Apfelmus > > wrote: > >> > >> Eugene Kirpichov wrote: > >>> > >>> In the last couple of days I completed my quest of making my graphing > >>> utility timeplot ( http://jkff.info/software/timeplotters ) not load > the > >>> whole input dataset into memory and consequently be able to deal with > >>> datasets of any size, provided however that the amount of data to > *draw* > >>> is > >>> not so large. On the go it also got a huge speedup - previously > >>> visualizing > >>> a cluster activity dataset with a million events took around 15 minutes > >>> and > >>> a gig of memory, now it takes 20 seconds and 6 Mb max residence. > >>> (I haven't yet uploaded to hackage as I have to give it a bit more > >>> testing) > >>> > >>> The refactoring involved a number of interesting programming patterns > >>> that > >>> I'd like to share with you and ask for feedback - perhaps something can > >>> be > >>> simplified. > >>> > >>> The source is at http://github.com/jkff/timeplot > >>> > >>> The datatype of incremental computations is at > >>> > >>> > https://github.com/jkff/timeplot/blob/master/Tools/TimePlot/Incremental.hs. > >>> Strictness is extremely important here - the last memory leak I > >>> eliminated > >>> was lack of bang patterns in teeSummary. > >> > >> > >> Your StreamSummary type has a really nice interpretation: it's a > >> reification of case expressions. > >> > >> For instance, consider the following simple function from lists to > >> integers > >> > >>length :: [a] -> Int > >>length xs = case xs of > >>[] -> 0 > >>(y:ys) -> 1 + length ys > >> > >> We want to reify the case expression as constructor of a data type. What > >> type should it have? Well, a case expression maps a list xs to a > result, > >> here of type Int, via two cases: the first case gives a result and the > other > >> maps a value of type a to a function from lists to results again. This > >> explanation was probably confusing, so I'll just go ahead and define a > data > >> type that represents functions from lists [a] to some result of type r > >> > >>data ListTo a r = CaseOf r (a -> ListTo a r) > >> > >>interpret :: ListTo a r -> ([a] -> r) > >>interpret (CaseOf nil cons) xs = > >>case xs of > >>[] -> nil > >>(y:ys) -> interpret (cons y) ys > >> > >> As you can see, we are just mapping each CaseOf constructor back to a > >> built-in case expression. > >> > >> Likewise, each function from lists can be represented in terms of our > new > >> data type: simply replace all built-in case expressions with the new > >> constructor > >> > >>length' :: ListTo a Int > >>length' = CaseOf > >>(0) > >>(\x -> fmap (1+) length') > >> > >>length = interpret length' > >> > >> The CaseOf may look a bit weird, but it's really just a straightforward > >> translation of the case expression you would use to define the function > go > >> instead. > >> > >> Ok, this length function is really inefficient because it builds a huge > >> expression of the form (1+(1+...)). Let's implement a strict variant > >> instead > >> > >>lengthL :: L
