Re: [Haskell-cafe] Performance of delete-and-return-last-element
One solution would be to fold over a specific semigroup instead of a
recursive function:
|import Data.Semigroup
import Data.Foldable(foldMap)
import Data.Maybe(maybeToList)
data Darle a =Darle {getInit :: [a],getLast ::a }
deriving Show
instance Semigroup (Darle a)where
~(Darle xs1 l1) ~(Darle xs2 l2) =Darle (xs1 ++ [l1] ++ xs2) l2
darle :: [a] -Darle a
darle = foldr1 () . map (Darle [])|
It's somewhat more verbose, but the core idea is clearly expressed in
the one line that defines ||, and IMHO it better shows /what/ are we
doing rather than /how/. It's sufficiently lazy so that you can do
something like |head . getInit $ darle [1..]|.
Best regards,
Petr
Dne 08/30/2013 08:18 PM, Lucas Paul napsal(a):
Suppose I need to get an element from a data structure, and also
modify the data structure. For example, I might need to get and delete
the last element of a list:
darle xs = ((last xs), (rmlast xs)) where
rmlast [_] = []
rmlast (y:ys) = y:(rmlast ys)
There are probably other and better ways to write rmlast, but I want
to focus on the fact that darle here, for lack of a better name off
the top of my head, appears to traverse the list twice. Once to get
the element, and once to remove it to produce a new list. This seems
bad. Especially for large data structures, I don't want to be
traversing twice to do what ought to be one operation. To fix it, I
might be tempted to write something like:
darle' [a] = (a, [])
darle' (x:xs) = let (a, ys) = darle' xs in (a, (x:ys))
But this version has lost its elegance. It was also kind of harder to
come up with, and for more complex data structures (like the binary
search tree) the simpler expression is really desirable. Can a really
smart compiler transform/optimize the first definition into something
that traverses the data structure only once? Can GHC?
- Lucas
___
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] On Markdown in Haddock and why it's not going to happen
On Thu, Aug 29, 2013 at 9:30 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. This is a little off-topic, but the Haddock website apparently is years out of date. http://www.haskell.org/haddock/ says the latest version is 2.8.0 released in September 2010, but apparently I have 2.13.2 on my machine. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
Is there an up todate copy of the haddock manual online anywhere?
On Saturday, August 31, 2013, Omari Norman wrote:
On Thu, Aug 29, 2013 at 9:30 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk javascript:_e({}, 'cvml',
'fuuze...@fuuzetsu.co.uk'); wrote:
Greetings café,
Perhaps some saddening news for Markdown fans out there. As you might
remember, there was a fair amount of push for having Markdown as an
alternate syntax for Haddock.
This is a little off-topic, but the Haddock website apparently is years
out of date.
http://www.haskell.org/haddock/
says the latest version is 2.8.0 released in September 2010, but
apparently I have 2.13.2 on my machine.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: th-desugar simplifies Template Haskell processing
Great package! One question: Do you remove/inline type synonyms? I ask because I just ran into this with some TH code. I'm looking for types that end with - a, but that fails when type synonyms are involved. Sjoerd On Aug 30, 2013, at 2:08 AM, Richard Eisenberg e...@cis.upenn.edu wrote: I've just uploaded my new th-desugar package, which enables easier processing of Template Haskell source syntax by desugaring it into a much simpler core language. The meaning of the code after desugaring is identical to before desugaring, but the syntax is much simpler. To wit, th-desugar simplifies out all of the following constructs: - guarded expressions in both functions and case statements - where declarations - do syntax - list/monad comprehensions - record creation / updates - as patterns - non-trivial patterns in a lambda expression - lambda-case - multi-way if - several more If you are writing a library that manipulates Template Haskell syntax, you may wish to consider if th-desugar will make your job easier by forcing you to consider fewer cases. The one source Haskell construct supported by Template Haskell but not supported by th-desguar is view patterns, mostly because these interact quite non-trivially with pattern binders. It's possible this hole will be closed in a future version. Enjoy! Richard ___ 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] On Markdown in Haddock and why it's not going to happen
On 31/08/13 16:20, Carter Schonwald wrote: Is there an up todate copy of the haddock manual online anywhere? No. You can build your own documentation. In Haddock directory, go into ‘doc’ and read the README on how to build it. That is also outdated however: for example, it doesn't provide information about the image syntax (image). New documentation will be written soon as the stuff I have been doing added and changed quite a bit. This will most likely come out before any actual release is made because I'd like to include a small guideline on migrating your docs to the new version. Nothing big should break and in huge majority of cases you shouldn't need to do anything but there are a few quirks that are gone that might change how your things look under some cases (mostly in cases of ill-formed docs). On Saturday, August 31, 2013, Omari Norman wrote: On Thu, Aug 29, 2013 at 9:30 PM, Mateusz Kowalczyk wrote: Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. This is a little off-topic, but the Haddock website apparently is years out of date. http://www.haskell.org/haddock/ says the latest version is 2.8.0 released in September 2010, but apparently I have 2.13.2 on my machine. The latest stable is indeed 2.13.2. Hopefully this will be updated fairly soon, AFAIK there was some miscommunication on who got the write permissions or something but I might just be misremembering. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
Hello, I disagree. While none of your detail points are wrong, they mainly focus on the fact that there is no 1-to-1 mapping between the existing haddock markup and Markdown. I don't think there needs to be. If Markdown can do something new, that something can be added; if something doesn't make sense in Haddock (like horizontal rules), we ignore them. I don't think original and markdown syntax should be mixed in the same file. That would make everything impossible to parse and difficult to write. As for which markdown implementation to use: I think it really doesn't matter that much in practice. Github and pandoc can both render documentation to my pleasing; I have yet to find a difference between them that would be a practical problem for my documentation efforts. Regarding module and type links: They are links, so probably just representing them as Markdown links would be cleanest. [SomeThing]() with an empty reference could make haddock automatically figure out what is wanted or default to a type, and you could be explicit with [SomeThing](module), [SomeThing](type) and [SomeThing](class). For headings, why is CPP a problem? CPP ignores haddock comments, haddock should ignore CPP. There is no reason to put CPP macros into comments. Regarding emphasis, **foo** would simply not be a heading in an export list. Using markdown haddock, we will have markdown headings for that. Markdown being claimed to be for editing documents for the Web doesn't make our efforts impossible. Pandoc can easily create latex output from it, and Github can use it as a documentation language for programming perfectly fine. So can we. Did I address all your points? Niklas On Fri 30 Aug 2013 10:30:51 JST, Mateusz Kowalczyk wrote: Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. Unfortunately, this is probably not going to happen for reasons listed on the post I just published at [1]. This thread is meant to be for discussion about the post as many people, myself included, felt that Markdown would be a nice thing to have. I feel like I covered the topic fairly well on the post but feel free to give suggestions or ask questions. I would also like to remind you that if there's something that you'd like to see in Haddock or something that you feel is broken, a good way express this is to make a ticket on the Haddock Trac[2]. I will close the relevant Markdown ticket on the Trac[3] in about 3 days, unless someone can come up with a reasonable solution that meets the initial intent of this part of the project: a widely known markup format that could be used as an alternate syntax for Haddock so that it's possible to write the documentation without learning the vanilla syntax itself. [1]: http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html [2]: http://trac.haskell.org/haddock [3]: http://trac.haskell.org/haddock/ticket/244 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 31/08/13 19:14, Niklas Hambüchen wrote: Hello, I disagree. That's fine, that's why the thread is here. While none of your detail points are wrong, they mainly focus on the fact that there is no 1-to-1 mapping between the existing haddock markup and Markdown. I don't think there needs to be. It doesn't have to be 1-to-1 but the features have to be expressible in both: it's useless if we have different features with one syntax but not the other. If Markdown can do something new, that something can be added; if something doesn't make sense in Haddock (like horizontal rules), we ignore them. This is precisely what I have been doing and why my post went over every point from the original Markdown documentation, talking about why each of these does or doesn't make sense. In the end, Markdown offers us nothing new feature wise and either forces us to make up new syntax for things it doesn't know about (definition lists) or makes us remove existing features all together. Once any not-HTML-specific (tags, rules) features that might be missing are implemented, we're left with something that looks very much like Markdown already. Alternate syntax would also look very much like Markdown but in a different, less known way. Not very nice. Basically, Markdown brings nothing new to the table that we can actually use and we're in fact making it less familiar by having to strip and add syntax. I don't think original and markdown syntax should be mixed in the same file. That would make everything impossible to parse and difficult to write. Agreed. See point above why this isn't practical anyway. We'd be piling features on top of Markdown, defeating the point of having familiar-to-others syntax. As for which markdown implementation to use: I think it really doesn't matter that much in practice. Github and pandoc can both render documentation to my pleasing; I have yet to find a difference between them that would be a practical problem for my documentation efforts. Unfortunately it _does_ matter in practice because each flavour solves Markdown quirks differently. On top of this, we have to accomodate for Haddock specific features. We're effectively creating our own flavour of Markdown + extra syntax. This sounds like… Haddock markup! Regarding module and type links: They are links, so probably just representing them as Markdown links would be cleanest. [SomeThing]() with an empty reference could make haddock automatically figure out what is wanted or default to a type, and you could be explicit with [SomeThing](module), [SomeThing](type) and [SomeThing](class). For headings, why is CPP a problem? CPP ignores haddock comments, haddock should ignore CPP. There is no reason to put CPP macros into comments. I have to admit that I did not explore this very carefully but you we can't simply guarantee that no one every will run CPP on their files by hand. Better safe than sorry. I actually implemented headings for function docs using the ‘ Heading 4’ syntax, avoiding this problem all together. Regarding emphasis, **foo** would simply not be a heading in an export list. Using markdown haddock, we will have markdown headings for that. But what if I want it to be a heading? Are we picking rules arbitrarily now? Markdown being claimed to be for editing documents for the Web doesn't make our efforts impossible. Pandoc can easily create latex output from it, and Github can use it as a documentation language for programming perfectly fine. So can we. That's because you can use LaTeX to render everything that HTML can (but not the other way around!). GitHub can use it because they don't have the burden of having to accommodate for an existing feature set of a different markup language. Note how GitHub Markdown doesn't have all the features of Haddock, therefore it is _not_ compatible with it. We can't just use their Markdown because it doesn't cover our use cases. Did I address all your points? You addressed some of them, but I hope I reasoned for them well above. What you haven't provided is how such Markdown could possibly look, noting the original goal of this: be an alternate syntax that's familiar to people already. If you can come up with such thing without losing any features and being distinct enough from Haddock markup to warrant it, I would love to hear it. Niklas -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] function arithmetic?
Hi. I was just curious about something. In one of my math textbooks I see expressions like this f + g or (f + g)(a) where f and g are functions. What is meant is f(a) + g(a) Is there a way in Haskell you can make use of syntax like that (i.e., expressions like f + g and f * g to create a new function), perhaps by loading a module or something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
