Re: [Haskell-cafe] ANN: th-desugar simplifies Template Haskell processing
For expanding/inlining type synonyms, there is also th-expand-syns ( http://hackage.haskell.org/package/th-expand-syns). /Anders On Mon, Sep 2, 2013 at 3:25 AM, Richard Eisenberg e...@cis.upenn.edu wrote: No, but I agree that this behavior is useful and in the spirit of th-desugar. I can add this to the next version, which should come out in a few days (tomorrow?), because I've noticed a bug with the scoping of as-patterns in let statements. Thanks for the suggestion! Richard On Aug 31, 2013, at 12:06 PM, Sjoerd Visscher wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Ajhc Haskell Compiler 0.8.0.8 Release
We are happy to announce Ajhc 0.8.0.8. This version is a point release to fix some BUGs, and support new platforms. You can get Ajhc using cabal install ajhc command. The usage is found at Ajhc's project web site http://ajhc.metasepi.org/. The source code at https://github.com/ajhc/ajhc/tags. Welcome sending any bugs or your ideas to https://github.com/ajhc/ajhc/issues. ## Support new platforms ### mbed http://mbed.org/ The mbed platform is a single-board microcontroller using ARM Cortex-M3 CPU. It has only 32kB RAM for application. From this release, Ajhc support mbed and Text LCD device driver. You can find the demo source code at https://github.com/ajhc/demo-cortex-m3, and watch the demo movie at http://www.youtube.com/watch?v=fOsjEfNmTkY. ### ChibiOS/RT http://www.chibios.org/ The ChibiOS/RT is embedded real time OS. From this release, Ajhc can compile Haskell application running on ChibiOS/RT. The application is able to use forkOS API with ChibiOS/RT's thread. You will find the demo source code at https://github.com/metasepi/chibios-arafura. ## Other changes * Use cpphs command for C preprocessor. * Don't insert (void) cast for function call. * Add --targetsini option to specify the targets.ini file. * Data.Bits support CInt. * Retry download when some error occured on getting tar ball from Hackage DB. * Fix BUGs * Don't increment megablock count, when re-use the megablock in free list. * Fix IORef compile BUG. Enjoy! :) - - - Metasepi team ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Traversals of monomorphic containers (was: Re: mapM_ for bytestring)
# Redirected to haskell-cafe On Sun, 2013-09-01 at 14:58 +0400, Artyom Kazak wrote: Would this be an appropriate place to propose adding mapM_ (and then possibly mapM) to bytestring library? Was it suggested before? If yes, why was it rejected? This got me wondering: there are several type-classes useful for polymorphic container types, e.g. Functor, Foldable Traversable which all apply to some type of kind (* - *). Are there related things for monomorphic containers, like ByteString, Text or some newtype'd Vector with fixed element type, e.g. class MFunctor f a where mfmap :: (a - a) - f - f instance MFunctor ByteString Word8 where mfmap = ByteString.map or (maybe even better) class MFunctor f where type Elem mfmap :: (Elem - Elem) - f - f instance MFunctor ByteString where type Elem = Word8 mfmap = ByteString.map and similar for other classes. Nicolas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Generic conditions for 'if' and 'case'
On Sun, 2013-09-01 at 15:51 -0700, Wvv wrote:
I think it is an old idea, but nevertheless.
Now we have next functions:
if (a :: Bool) then x else y
case b of
a1 :: Bool - x1
a2 :: Bool - x2
...
Let we have generic conditions for 'if' and 'case':
class Boolean a where
toBool :: a - Bool
instance Boolean Bool where
toBool = id
instance Boolean [a] where
toBool [] = False
toBool _ = True
instance Boolean (Maybe a) where
toBool Nothing = False
toBool _ = True
instance Boolean Int where
toBool 0 = False
toBool _ = True
if' (a :: Boolean b) then x else y
case' d of
a1 :: Boolean b1 - x1
a2 :: Boolean b2 - x2
...
It is very easy to implement to desugar:
if' a then ... == if toBool ( a ) then ...
I wasn't at my computer when I sent my previous reply, so here's a more
full-fledged answer:
This is possible using the RebindableSyntax extension. Make sure to read
the documentation of the extension before using it, it might have some
unexpected implications.
Be careful when using this scheme as well... I'd think lots of
Haskell'ers would frown upon this kind of implicit conversions (they
remind me of Python and its __nonzero__ stuff).
Here's an example implementing your proposal:
{-# LANGUAGE RebindableSyntax #-}
import Prelude
class Boolean a where
toBool :: a - Bool
instance Boolean Bool where
toBool = id
instance Boolean [a] where
toBool = not . null
instance Boolean (Maybe a) where
toBool = maybe False (const True)
instance Boolean Int where
toBool = (/= 0)
ifThenElse :: Boolean a = a - b - b - b
ifThenElse i t e = case toBool i of
True - t
False - e
main :: IO ()
main = do
test False
test ([] :: [Int])
test [1]
test (Nothing :: Maybe Int)
test (Just 1 :: Maybe Int)
test (0 :: Int)
test (1 :: Int)
{- test 'c' fails to type-check: no instance Boolean Char defined!
-}
where
test v = putStrLn $ show v ++ is ++ (if v then true else
false)
which outputs
False is false
[] is false
[1] is true
Nothing is false
Just 1 is true
0 is false
1 is true
Using RebindableSyntax, 'if I then T else E' is rewritten into
'ifThenElse I T E' by the compiler, for whatever 'ifThenElse' is in
scope.
Nicolas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: MVar problem in acid-state?
Hi the list, I have compiled my application on my PC, it works fine, but when I copy it on my server (same architecture), I get: Nomyx: thread blocked indefinitely in an MVar operation I don't use MVars in my application, is it possible that it's coming from acid-state? Thanks, Corentin ___ 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
When the proposal was first being discussed, I suggested that instead of adding markdown support to haddock, one might enhance the existing haddock markup, making it more expressive, so that it could encode the same range of structural features as markdown. If I'm not mistaken, currently haddock doesn't allow list items with multiple paragraphs or other block elements, or nested lists, or images, or blockquotes. This makes it impossible to create a pandoc writer for haddock markup (we already have a haddock reader, soon to be released). With a pandoc writer for haddock, one could write longer documentation sections (e.g. tutorials) in markdown and convert them to haddock for inclusion in source code. This should help people who don't like haddock markup or don't want to learn it. With the reader, haddock comments can already be converted into other formats. I haven't been following your work, but do I understand correctly that you've been making haddock markup more expressive and rational? Has this gotten to the point where a pandoc writer would be feasible? John +++ Mateusz Kowalczyk [Aug 30 13 02:30 ]: 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 -- Mateusz K. ___ 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] Proposal: Generic conditions for 'if' and 'case'
Thanks! It is a good toy for testing!
Nicolas Trangez wrote
Here's an example implementing your proposal:
{-# LANGUAGE RebindableSyntax #-}
import Prelude
class Boolean a where
toBool :: a - Bool
instance Boolean Bool where
toBool = id
instance Boolean [a] where
toBool = not . null
instance Boolean (Maybe a) where
toBool = maybe False (const True)
instance Boolean Int where
toBool = (/= 0)
ifThenElse :: Boolean a = a - b - b - b
ifThenElse i t e = case toBool i of
True - t
False - e
main :: IO ()
main = do
test False
test ([] :: [Int])
test [1]
test (Nothing :: Maybe Int)
test (Just 1 :: Maybe Int)
test (0 :: Int)
test (1 :: Int)
{- test 'c' fails to type-check: no instance Boolean Char defined!
-}
where
test v = putStrLn $ show v ++ is ++ (if v then true else
false)
which outputs
False is false
[] is false
[1] is true
Nothing is false
Just 1 is true
0 is false
1 is true
Using RebindableSyntax, 'if I then T else E' is rewritten into
'ifThenElse I T E' by the compiler, for whatever 'ifThenElse' is in
scope.
Nicolas
___
Haskell-Cafe mailing list
Haskell-Cafe@
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Proposal-Generic-conditions-for-if-and-case-tp5735366p5735424.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 02/09/13 19:43, John MacFarlane wrote: When the proposal was first being discussed, I suggested that instead of adding markdown support to haddock, one might enhance the existing haddock markup, making it more expressive, so that it could encode the same range of structural features as markdown. If I'm not mistaken, currently haddock doesn't allow list items with multiple paragraphs or other block elements, or nested lists, or images, or blockquotes. Paragraph level elements are indeed not allowed in lists. The list contents are currently (that is, on my working branch) allowed to be: monospace (delimited by @), anchors, identifiers, module names, pictures, URLs, bold, emphasis, HTML escape codes, regular strings. Note that if a monospaced string is the only element of the list content, it gets turned into a code block. I'm not sure what you mean by block elements. Do you mean bird tracks and code blocks? There's a ticket about nested lists at http://trac.haskell.org/haddock/ticket/27 . While I say that nested paragraphs are not planned, I'm still playing with the thought. The issue is having to balance adding new features with not breaking a significant amount of existing documentation: we do not want to force everyone to go through all their libraries and change their markup. While I say on the ticket that it's hard to implement, I think it could be done with indentation. I would have to experiment. If you would like to see paragraph nesting, please make a ticket describing the behaviour! If list nesting is all you would be after then the ticket already exists. If you're looking for allowing more elements in lists, please make a ticket. This makes it impossible to create a pandoc writer for haddock markup (we already have a haddock reader, soon to be released). Yes, indeed you might remember that my original proposal was to take care of this: improving Haddock to the point where a writer would be possible and providing the writer. I even mentioned somewhere that my proposal and the proposal I'm currently working on would eventually end up with the same result, just in a different order of events. With a pandoc writer for haddock, one could write longer documentation sections (e.g. tutorials) in markdown and convert them to haddock for inclusion in source code. This should help people who don't like haddock markup or don't want to learn it. With the reader, haddock comments can already be converted into other formats. I haven't been following your work, but do I understand correctly that you've been making haddock markup more expressive and rational? Has this gotten to the point where a pandoc writer would be feasible? I will enumerate some changes. Probably the most important part is the new parser which makes new markup additions and changes far easier and testable than working with two separate grammars fed into Alex and Happy. I also added a fair amount of tests and set up LaTeX backend testing (I still need to populate it with tests though). I hope to do the same with Hoogle. * Long missing bold was added, with double underscore as delimiter. __foo bar baz__. You don't have to escape single underscores as you would have to in the past: __fo_o__ is fine. Even __foo bar\__baz__ is fine. * Nested markup is now possible and allowed where sensible. __/foo/__ * Escaping of delimiters mid-markup is now possible. /fo\/o/ will produce emphasised fo\o. The old behaviour would only emphasise fo\. URLs, anchors and images follow the old rules (terminate on first delimiter, even if escaped. I'll probably allow escaping in URL and image syntax though. * The parser should no longer fail on any strings. This means that a line like This is / a line. will parse as a simple string. In the past this would fail because there's no closing slash and you'd be forced to escape it. If you happen to see the old ‘parsing failed’ message with new release, please file as a major bug! * Image ‘title’ text is now possible. imagePath titleText * You no longer need a line break between lists of the same type. * foo * bar is fine. * foo 2. bar is not fine if two lists are what you're after. * Headers are now allowed in function documentation: = @Monospaced Header 1@ == __Bold Header 2__ === /Emphasised Header 3/ […] == Header 6 Header levers 3-6 all get rendered at the same size in LaTeX. Also put it into the Hoogle back-end but of course, it's out of our hands to decide how that will be rendered. I e-mailed Neil Mitchel and he said that this should be no problem however. Note that you do NOT need a line break between a header and a paragraph-level markup. That is things like = Header birdtracks can only be on their own paragraphs are completely fine. I'm still thinking about this behaviour but I don't see any real problems with it. Currently implementing per-module enabled extension listing, enabled for rendering with a Haddock pragma but I
[Haskell-cafe] Fw: Re: On Markdown in Haddock and why it's not going to happen
+++ Mateusz Kowalczyk [Sep 02 13 21:34 ]: On 02/09/13 19:43, John MacFarlane wrote: When the proposal was first being discussed, I suggested that instead of adding markdown support to haddock, one might enhance the existing haddock markup, making it more expressive, so that it could encode the same range of structural features as markdown. If I'm not mistaken, currently haddock doesn't allow list items with multiple paragraphs or other block elements, or nested lists, or images, or blockquotes. Paragraph level elements are indeed not allowed in lists. The list contents are currently (that is, on my working branch) allowed to be: monospace (delimited by @), anchors, identifiers, module names, pictures, URLs, bold, emphasis, HTML escape codes, regular strings. Note that if a monospaced string is the only element of the list content, it gets turned into a code block. I'm not sure what you mean by block elements. I mean things like paragraphs, blockquotes, code blocks, other lists. In markdown you can have a list item that contains these things: 1. This is my first list item. Second paragraph of first list item. Some code: foo = bar $ baz * 2.0 2. This is my second list item. * Sublist item one * Sublist item two 3. This is my third list item. Someone said: We want markdown support in haddock! In Haddock, last I looked, you couldn't do any of this... In your original message, you emphasized features of Haddock that don't exist in standard markdown and would require extensions (definition lists, automatic links to Haskell identifiers, etc.). But in many other ways, markdown is much more expressive than Haddock markup, as the example above illustrates. The changes that would be needed to Haddock to allow it to express what can be expressed in markdown are much bigger, I think, than the changes that would be needed to markdown to allow it to express what can be expressed in Haddock. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] stream interface vs string interface: references
In a reply to the question on the thread titled Can I use String without in ghci?, Richard A. O'Keefe has noted that, It's also the what-Smalltalk-got-right-and-Java-got-wrong lesson: the right way to convert objects to text is via a *stream* interface, not a *string* interface. I didn't want to clutter that thread so I am asking a question here. Where do I find foundational and/or other good references on the topic of stream interface vs string interface to convert objects to text? I tried google but failed. I am looking for pointers that explain the rational behind the above claim made by O'Keefe. and what is the take of Haskell on this topic? Thanks and regards, -Damodar Kulkarni ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
