Hi, all,
I am happy to announce a utility hoodle-publish for publishing hoodle
files on the web as a form of pdf files. I am planning to support html
publishing later.
For those who do not know what hoodle is, hoodle
(http://ianwookim.org/hoodle) is a pen notetaking program written
entirely in ha
How could I use Data.Bits to implement the below C code in Haskell?
http://www-graphics.stanford.edu/~seander/bithacks.html#NextBitPermutation
Compute the lexicographically next bit permutation
Suppose we have a pattern of N bits set to 1 in an integer and we want the
next permutation of N 1 bit
Johan Tibell wrote:
> I suggest that we implement an alternative haddock syntax that's a
> superset of Markdown.
Here is a previous thread on this exact topic, from five years ago:
http://www.haskell.org/pipermail/haskell-cafe/2008-February/039846.html
It mentions a few additional shades of bike
hmatrix and ad don't (currently) mix.
The problem is that hmatrix uses a packed structure that can't hold any of
the AD mode variants we have as an Element. =(
I've been working with Alex Lang to explore in ad 4.0 ways that we can
support monomorphic AD modes and still present largely the same AP
On Tue, Apr 9, 2013 at 12:40 PM, Joe Nash wrote:
> I would be interested in discussing this project with a potential mentor if
> one happens to be reading. I'm a second year Computer Science student at the
> University of Nottingham, very interested in doing a haskell.org SoC
> project.
Normally
I would be interested in discussing this project with a potential mentor if
one happens to be reading. I'm a second year Computer Science student at
the University of Nottingham, very interested in doing a haskell.org SoC
project.
On Tue, Apr 9, 2013 at 8:17 PM, David Waern wrote:
>
>
>
> 2013/
2013/4/8 Evan Laforge
> 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 maintai
Yuras Shumovich gmail.com> writes:
> Will not it be a nightmare to implement and maintain checker for
> overlapping/unused clauses for non-linear patterns?
For sure it does not look straightforward.
Note that there are some results and algorithms
for non-linear patterns, cf. this short survey
Hi Cafe,
Suppose I want to find the grad of a function then it's easy I just
use http://hackage.haskell.org/package/ad-3.4:
import Numeric.AD
import Data.Foldable (Foldable)
import Data.Traversable (Traversable)
data MyMatrix a = MyMatrix (a, a)
deriving (Show, Functor, Foldable, Traversable)
* Malcolm Wallace [2013-04-09 15:34:01+0100]
>
> On 9 Apr 2013, at 14:46, Sturdy, Ian wrote:
>
> > As far as the use of Eq goes, Eq is already enshrined in pattern matching
> > by pattern matching against literals.
>
> Not true. Pattern-matching literals explicitly avoids any use of Eq.
> D
On 9 Apr 2013, at 14:46, Sturdy, Ian wrote:
> As far as the use of Eq goes, Eq is already enshrined in pattern matching by
> pattern matching against literals.
Not true. Pattern-matching literals explicitly avoids any use of Eq.
Demonstration:
data Foo = Foo | Bar
instance Eq Foo where
I want to enable a Haskell benchmarking bot that would upload its data to a
Google Fusion Table each time it runs. That seems to require the
"service-to-service" mode for Google's OAuth2:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
There are a bunch of libraries on Hackag
I am somewhat skeptical of this extension; guards seem to work, and while I use
syntax extensions somewhat liberally I am not certain this provides enough
benefit to restrict code to GHC. I used it extensively in Erlang, but I find
myself doing much less pattern matching in Haskell.
That said,
Hi Jan,
On Tue, Apr 09, 2013 at 01:32:33PM +0200, Jan Stolarek wrote:
> Thanks for pointing me to earlier discussions on this subject - they are
> enlightening :) One
> particular argument "against" seems to be very convincing to me:
>
> "From a language design point of view, it should be note
* Daniel Trstenjak [2013-04-09 13:01:07+0200]
>
> Hi Roman,
>
> > In fact, lots of Haskell newcomers are surprised that
> >
> > f 10 = 42
> >
> > is not the same as
> >
> > n = 10
> > f n = 42
>
> Well, yes, at the beginning I've been also surprised about this.
>
> But allowing this s
> Also, for some history, this was discussed a while back:
> http://www.mail-archive.com/haskell@haskell.org/msg03721.html
Thanks for pointing me to earlier discussions on this subject - they are
enlightening :) One
particular argument "against" seems to be very convincing to me:
"From a languag
Hi Roman,
> In fact, lots of Haskell newcomers are surprised that
>
> f 10 = 42
>
> is not the same as
>
> n = 10
> f n = 42
Well, yes, at the beginning I've been also surprised about this.
But allowing this seems to be even more error prone, because now you
could "bind" function argum
* Daniel Trstenjak [2013-04-09 09:37:46+0200]
>
> Hi Roman,
>
> > One issue with it in Haskell is that it'd lead to inconsistent
> > semantics:
> >
> > myEq x x = True
> >
> > is not the same as
> >
> > myEq x y =
> > case y of
> > x -> True
>
> I don't think that it's inconsis
Hi Phil,
I am posting this on behalf of Martijn Rutten.
Cheers,
Alexey
8-<---
Fair point. When we started the company in 2007, the experts in
Silicon Valley told us that our ambition to develop tools to create an
efficient, parallel embedded system from sequential C and C++ code is
Hello.
I have next problem: I have a network client that connects to server,
listens for messages and generate responces. So the control flow can be
represended as:
server -- input -> {generate output} -> output
Output can be generated using default implementation or can overriden by
user.
The
Jan Stolarek writes:
> 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 Pr
Hi Roman,
> One issue with it in Haskell is that it'd lead to inconsistent
> semantics:
>
> myEq x x = True
>
> is not the same as
>
> myEq x y =
> case y of
> x -> True
I don't think that it's inconsistent, because the 'case' defines a new name
scope, like the function does for
22 matches
Mail list logo
