Yes, that's a fair explanation.
On Tue, Apr 9, 2013 at 7:48 AM, Magicloud Magiclouds <
magicloud.magiclo...@gmail.com> wrote:
> Thank you for the reply. I've learnt the code of "lines". So it is because
> how ByteString works, that the conduit is not a stream of bytes, but
> chunks, right?
>
>
>
It supports ```language blocks, but not autolink detection. I have not
fully documented which features are supported. I also haven't done any
performance analysis versus other tools, simply because my goal is in no
way high efficiency. It is fast enough for my use cases, and I don't intend
to spend
Thank you for the reply. I've learnt the code of "lines". So it is because
how ByteString works, that the conduit is not a stream of bytes, but
chunks, right?
On Tue, Apr 9, 2013 at 12:12 PM, Michael Snoyman wrote:
> It's a bug in your implementation of takeLine I believe. It doesn't take
> into
It's a bug in your implementation of takeLine I believe. It doesn't take
into account that lines can span multiple chunks. When you call takeLine
the first time, you get "L1\n". leftover puts a chunk with exactly those
contents back. When you call takeLine the second time, it gets the chunk
"L1\n",
There is no fundamental problem with non-linear patterns
using ==. (The functional logic programming world long
ago generalised the idea of unification to 'narrowing'.)
There _is_ a technical problem in Haskell about whether
the == here is necessarily the one from the Prelude or
whether it might
Hi,
On Mon, 2013-04-08 at 07:06 -0700, Conal Elliott wrote:
> What you're suggesting is called "non-linear patterns", and it's a
> perfectly sensible, well-defined feature in a language with
> pattern-matching. As you point out, non-linearity allows for more direct &
> succinct programming. I've
On Mon, Apr 8, 2013 at 3:49 PM, Ivan Lazar Miljenovic
wrote:
> On 9 April 2013 05:08, MigMit wrote:
>>
>>
>> Отправлено с iPad
>>
>> 08.04.2013, в 21:44, Evan Laforge написал(а):
>>
>>> Can't we just add some features to haddock?
>>
>> No, we can't. At the very least we should FIX haddock before
On 9 April 2013 05:08, MigMit wrote:
>
>
> Отправлено с iPad
>
> 08.04.2013, в 21:44, Evan Laforge написал(а):
>
>> Can't we just add some features to haddock?
>
> No, we can't. At the very least we should FIX haddock before adding features.
How specifically does haddock need to be fixed?
>
>
>
Thanks for working on this again this year!
On Mon, Apr 8, 2013 at 12:50 PM, Edward Kmett wrote:
> We (haskell.org) have been officially accepted into the Google Summer of
> Code for 2013. We should show up in the mentoring organization list as soon
> as I get some information we need to finalize
* Conal Elliott [2013-04-08 07:06:17-0700]
> What you're suggesting is called "non-linear patterns", and it's a
> perfectly sensible, well-defined feature in a language with
> pattern-matching.
One issue with it in Haskell is that it'd lead to inconsistent
semantics:
myEq x x = True
is not th
… and this works just fine. \o/
At least cabal now installs/builds the llvm 3.0.1.0 package successfully. So,
normality has been restored… any remaining problems are therefore my own :-)
That last reference has to be changed with the install_name_tool -id option
(rather than -change) as indee
On Mon, Apr 8, 2013 at 9:59 PM, Richard Eisenberg wrote:
>
>
> On Apr 8, 2013, at 3:12 PM, Paul Brauner wrote:
>
> > from the output of -ddump-splices I dont think it is the case but I'm
> asking anyway: is there any way to deduce a ~ b from a :==: b?
>
> Not easily. You would have to write a (p
On Apr 8, 2013, at 3:12 PM, Paul Brauner wrote:
> from the output of -ddump-splices I dont think it is the case but I'm asking
> anyway: is there any way to deduce a ~ b from a :==: b?
Not easily. You would have to write a (potentially recursive) function that
explicitly matches singleton c
We (haskell.org) have been officially accepted into the Google Summer of
Code for 2013. We should show up in the mentoring organization list as soon
as I get some information we need to finalize the listing.
Shachaf Ben-Kiki has volunteered to help out as our backup org
administrator this year.
I
Hello,
from the output of -ddump-splices I dont think it is the case but I'm
asking anyway: is there any way to deduce a ~ b from a :==: b?
Given
data T = C1 | ... | Cn
I can easily derive
data EqT :: T -> T -> * where
EqT :: a ~ b => EqT a b
eqT :: ST a -> ST b -> Maybe (EqT a b)
Отправлено с iPad
08.04.2013, в 21:44, Evan Laforge написал(а):
> Can't we just add some features to haddock?
No, we can't. At the very least we should FIX haddock before adding features.
> There are a lot of ways
> to improve haddock a lot, and no one is doing them, so my impression
> is
On 8 Apr 2013, at 14:52, Roman Cheplyaka wrote:
>> In my opinion, it is perfectly valid to have intentional preprocessor
>> directives inside Haskell comments.
>
> Could you give an example where this is useful?
> ... macro expansions inside the comments are rather exotic.
{- | Some module docu
Can't we just add some features to haddock? There are a lot of ways
to improve haddock a lot, and no one is doing them, so my impression
is that haddock doesn't really have active maintainers. Adding a
whole new backend seems risky, unless it results in new maintainers
joining.
For my personal b
OK, thanks again. I'll give that a whirl.
On 2013-04-08, at 7:48 AM, Brandon Allbery wrote:
> On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans wrote:
> Unfortunately, it looks like
> /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib
>
> is pointing to the dodg
+++ John MacFarlane [Apr 05 13 16:04 ]:
> I like markdown and use it all the time. While I acknowledge the
> problems that have been pointed out, markdown has the advantage of being
> easily readable "as it is" in the source document, and not looking like
> markup.
>
> But I do want to point out
This is a recurring theme, see also here:
http://www.haskell.org/pipermail/haskell-cafe/2009-May/061498.html
On 8 April 2013 16:53, Tom Murphy wrote:
>
> Also, for some history, this was discussed a while back:
> http://www.mail-archive.com/haskell@haskell.org/msg03721.html
>
_
On Mon, Apr 8, 2013 at 7:59 AM, Joachim Breitner
wrote:
> Hi,
>
> I believe one problem with non-linear patterns would be that the
> compiler has to figure out what notion of equality you want here. An
> obvious choice is (==), but the Eq instances might not do what you want.
> Using pattern guard
Hi,
I believe one problem with non-linear patterns would be that the
compiler has to figure out what notion of equality you want here. An
obvious choice is (==), but the Eq instances might not do what you want.
Using pattern guards or view patterns explicates this choice.
Also, without an explici
On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans wrote:
> Unfortunately, it looks like
>
> /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib
> is pointing to the dodgy library too, e.g.:
>
> > otool
> -L
> /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr
Hi Jan,
What you're suggesting is called "non-linear patterns", and it's a
perfectly sensible, well-defined feature in a language with
pattern-matching. As you point out, non-linearity allows for more direct &
succinct programming. I've often wished for this feature when writing
optimizations on d
* Ivan Lazar Miljenovic [2013-04-08 10:18:32+1000]
> On 8 April 2013 07:12, Roman Cheplyaka wrote:
> > Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
> > comments. E.g. GNU cpp strips C comments.
>
> Not quite: http://hackage.haskell.org/trac/ghc/ticket/4836
This seems to b
* Malcolm Wallace [2013-04-08 10:00:11+0100]
> And cpphs strips C comments too. :-)
>
> But seriously, John's use-case is the exact opposite of what you
> suggest. John wants to keep the # inside the comment block. You
> suggest to remove the comment-block altogether?
No, my point was that the
Hi Jan,
On one hand, I've never really needed this.
On the other hand, it looks like a nice syntaxic sugar addition, so if you
implemented this I would probably give it a try.
David.
2013/4/8 Jan Stolarek
> > You can achieve something similar with the ViewPatterns language
> > extension.
> >
Hi John,
I am not saying it's wrong, but something you could consider trying is
using the RVars to generate the random numbers inside MonadRandom and using
lift to lift the random number generation into the state Monad and use
runStateT. The IO Monad is an instance of MonadRandom so any State +
Mo
> You can achieve something similar with the ViewPatterns language
> extension.
>
> member _ [] = False
> member x (((x ==) -> True) : _) = True
> member x (_ : xs) = member x xs
Hi Tillmann,
there are a couple of ways to achieve this in Haskell, for example using guards:
member :: Eq a => a -> [
Hi,
Jan Stolarek wrote:
If Haskell allowed to write pattern matching similar to Prolog then we could
write this function
like this:
member :: Eq a => a -> [a] -> Bool
member _ [] = False
member x (x:_) = True
member x (_:xs) = member x xs
The meaning of pattern in the second equation is
On 8 April 2013 21:11, Jan Stolarek wrote:
> Hi all,
>
> consider this simple reimplementation of 'elem' function:
>
> member :: Eq a => a -> [a] -> Bool
> member _ [] = False
> member y (x:xs) | x == y= True
> | otherwise = member y xs
>
> If Haskell allowed to write pattern m
Hi all,
consider this simple reimplementation of 'elem' function:
member :: Eq a => a -> [a] -> Bool
member _ [] = False
member y (x:xs) | x == y= True
| otherwise = member y xs
If Haskell allowed to write pattern matching similar to Prolog then we could
write this function
Could you elaborate a bit on which markdown features you support (or
even better: write it into your module haddocks)?
Thinks like
- autolink detection
- ```language blocks?
Also, you build on performance-oriented libraries - it would be cool if
you could make a small benchmark comparing with the
On Mon 08 Apr 2013 17:19:08 SGT, Oliver Charles wrote:
>> * Your friends and colleagues describe you as a "rockstar" programmer;
>>your programming ability is way above average;
> Good luck hiring smart people.
I get a high score in http://areyouabrogrammer.com - does that qualify
me for the
On 04/08/2013 06:30 AM, Stefan Holdermans wrote:
* Your friends and colleagues describe you as a "rockstar" programmer;
your programming ability is way above average;
Good luck hiring smart people.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskel
And cpphs strips C comments too. :-)
But seriously, John's use-case is the exact opposite of what you suggest. John
wants to keep the # inside the comment block. You suggest to remove the
comment-block altogether?
When I checked the example with cpphs, it turns out that the # line is
retaine
On 6 April 2013 01:57, John Wiegley wrote:
> > Johan Tibell writes:
>
> > I suggest that we implement an alternative haddock syntax that's a
> superset
> > of Markdown.
>
> Definite +1 from me too.
>
+1
Conrad.
___
Haskell-Cafe mailing list
Haske
38 matches
Mail list logo
