Robert Greayer wrote:
> Isn't tying the knot (in the way 'fib' does) straightforward with closures
> a la Python/Ruby/Smalltalk (without mutation)?
> Even in a syntactically clumsy language like Java, a
> tying-the-knot implementation equivalent to the canonical Haskell one is
> not difficult, e.g.
On Wed, Jul 15, 2009 at 2:18 PM, Max Rabkin wrote:
> On Wed, Jul 15, 2009 at 7:33 PM, Cristiano
> Paris wrote:
>> fib = 1:1:fib `plus` (tail fib) where plus = zipWith (+)
> ...
> ...
> This indicates that you think tying the knot should be impossible in
> Python. In my opinion this is not the case.
On Jul 15, 2009, at 9:57 PM, Magicloud Magiclouds wrote:
Hi,
I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
could not be compiled, parse error.
I apologise to everyone for my previous message in this
thread. There was a Haskell message in amongst some Erlang
messages, and
On Jul 15, 2009, at 9:59 PM, minh thu wrote:
2009/7/15 Magicloud Magiclouds :
Hi,
I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
could not be compiled, parse error.
++ is a function; you can't pattern-match on that.
Doesn't matter, it's not trying to.
Part of Erlang synt
On Jul 15, 2009, at 5:25 PM, Benjamin L.Russell wrote:
it interesting that you should use the biological term "disease";
according to a post [1] entitled "Re: Re: Smalltalk Data Structures
and Algorithms," by K. K. Subramaniam, dated "Mon, 29 Jun 2009
11:25:34 +0530," on the squeak-beginners mai
#def inline int signof(int x) {return x<0?-1:x>0?1:0;}
foreign import ccall safe ""
signof :: CInt -> CInt
Is it possible to get that #def as a result of
a macro? Say, something like this:
---
(WARNING: invalid code)
#define ret(name,value,type) \
#def inline type name (void) {return valu
If M is a monad transformer (e.g. StateT) and able to be parameterised
over an arbitrary monad, you can do something related, which may
actually be more useful to you.
Given the definition of StateT from mtl:
newtype StateT s m a = StateT {
runStateT :: s -> m (a, s)
}
you could define this join
Fernan Bolando wrote:
Program error: Prelude.!!: index too large
This is not very informative. It did not give me a hint which function
was causing this.
In addition to the debugging methods that have been mentioned, the
"Safe" library provides a way to write the code more robustly and/or
i
I think there may be a problem here.
"Homomorphic encryption is a form of encryption where one can perform a
specific algebraic operation on the plaintext by performing a (possibly
different) algebraic operation on the ciphertext. "
The word "specific" means that the functor is discrete, not
Of course !! is only one cause for this kind of errror. Another is
ghci> head []
*** Exception: Prelude.head: empty list
Unfortunately this kind of bug is very hard to debug due to the lazy
nature of haskell. You don't have a stack trace as in Java, PHP, ..
Example:
data D = D String
a,b :: [Str
A new "generator" package has been uploaded to Hackage.
It implements an alternative list monad transformer, a list class, and
related functions.
The difference from mtl/transformers's ListT is that
mtl is a monadic action that returns a list:
newtype ListT m a = ListT { runListT :: m [a] }
g
On Wed, Jul 15, 2009 at 11:54 PM, Jason Dagit wrote:
> Hello,
>
> I have just a very vague understanding of what homomorphic encryption is,
> but I was wondering if homomorphic encryption behaves as a one-way monad
> (like IO).
An interesting idea. Let's see where this leads.
> I could be mistake
fernanbolando:
> Hi all
>
> I recently used 2 hours of work looking for a bug that was causing
>
> Program error: Prelude.!!: index too large
>
> This is not very informative. It did not give me a hint which function
> was causing this. In C adding a few printf would have helped me, but
> in has
Hi all
I recently used 2 hours of work looking for a bug that was causing
Program error: Prelude.!!: index too large
This is not very informative. It did not give me a hint which function
was causing this. In C adding a few printf would have helped me, but
in haskell I was not sure how to do tha
Hello,
I have just a very vague understanding of what homomorphic encryption is,
but I was wondering if homomorphic encryption behaves as a one-way monad
(like IO).
So for example, suppose you wrote a function that worked on encrypted email
to determine if it spam, maybe it looks like this:
isSpa
On Wed, Jul 15, 2009 at 7:33 PM, Cristiano
Paris wrote:
> fib = 1:1:fib `plus` (tail fib) where plus = zipWith (+)
>
> Of course, this was something I already encountered when exploring the
> Y-combinator. Anyhow, I tried to translate this implementation to
> Python using Iterators and this is what
Matthias Görgens writes:
>> doesn't make much sense to me yet, although I suspect I can read the mu as a
>> lambda on types?
>
> Not really. The mu has more to do with recursion.
I'd say it's entirely to do with recursion. It's like the Y combinator
(or fix) for types, though it is combined wit
(and, the original which I didn't cc to -cafe.)
I'm pleased to announce the first release of shelltestrunner: a small
tool for testing any command-line program by running it through
"shell" tests defined with a simple file format. Each test can specify
the command-line arguments, input, exp
And the urls:
home - http://hackage.haskell.org/package/shelltestrunner
darcs repo - http://joyful.com/repos/shelltestrunner
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
> doesn't make much sense to me yet, although I suspect I can read the mu as a
> lambda on types?
Not really. The mu has more to do with recursion.
Matthias.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
Hi,
as pointed out in this list, it seems that a "tying the knot" example
would be the one better explaining the power of Haskell's
lazy-by-default approach against Python+Iterator's approach to
laziness.
So, in these days I'm trying to grasp the meaning of this "tying the
knot" concept which see
On Tue, Jul 14, 2009 at 6:02 PM, Thomas Hartman wrote:
> myiterate f x =
> let nxt = f x
> in nxt `seq` x : myiterate f nxt
iterate' f x = x `seq` x : iterate' f (f x)
seems better; it doesn't evaluate list elements you don't visit.
> let test = 1 : 2 : 3 : undefined in last $ take 4 $ myiterat
After my colleague explained me about zippers and how one could derive the
datatype using differential rules, I had to read about it.
So I started reading
http://en.wikibooks.org/wiki/Haskell/Zippers#Mechanical_Differentiation
This page contains the sentence: *"For a systematic construction, we
I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
could not be compiled, parse error.
Maybe a small abstract can help, as I once also got
confused by that.
* First, syntax without operators
You can only match on constructors. So, if
you have
data Test = Test1 Str
Actually, you can make a joinInner for the State monad. However, it
does not allow the inner function (h) to change the state, because how
state is threaded through a monad N is different for each N.
i :: (Monad n) => (a -> State s b) -> (b -> n c) -> (c -> State s d) -
> (a -> State s (n d)
On Wed, Jul 15, 2009 at 08:09:37AM -0400, Andrew Wagner wrote:
> Err, technically, aren't functions and constructors mutually exclusive? So
> if something is a function, it's, by definition, not a constructor?
I guess what Eugene Kirpichov meant was that not being a function
(and being a construct
On 15 Jul 2009, at 13:22, Luke Palmer wrote:
If ++ could be pattern matched, what should have been the result of
"let (x++y)=[1,2,3] in (x,y)"?
It will branch. In terms of unification, you get a list of
substitutions.
f :: [a] -> ([a],[a])
f (x ++ y) = (x,y)
For an argument s, any pair (x
No. Most constructors are functions, e.g. Just :: a -> Maybe a - a function.
On the other hand, Nothing :: Maybe a is a constructor, but not a function.
Andrew Wagner wrote:
Err, technically, aren't functions and constructors mutually exclusive?
So if something is a function, it's, by definitio
Err, technically, aren't functions and constructors mutually exclusive? So
if something is a function, it's, by definition, not a constructor?
On Wed, Jul 15, 2009 at 6:25 AM, Eugene Kirpichov wrote:
> Technically, the reason is not that (++) is a function, but that it is
> not a constructor of t
On Wed, Jul 15, 2009 at 3:08 AM, Hans Aberg wrote:
> On 15 Jul 2009, at 12:25, Eugene Kirpichov wrote:
>
> If ++ could be pattern matched, what should have been the result of
>> "let (x++y)=[1,2,3] in (x,y)"?
>>
>
> It will branch. In terms of unification, you get a list of substitutions.
f ::
Hi again!
We have decided to delay the release cycle slightly for 2.3 and release another
beta. The primary reason for this is our Windows support -- I would like to
invite all Windows users to install darcs-beta and give it a ride. If you have
a working cabal-install, all you need to do is run:
On 15 Jul 2009, at 12:25, Eugene Kirpichov wrote:
If ++ could be pattern matched, what should have been the result of
"let (x++y)=[1,2,3] in (x,y)"?
It will branch. In terms of unification, you get a list of
substitutions.
Hans
___
Haskell-Ca
Technically, the reason is not that (++) is a function, but that it is
not a constructor of the [] type.
And, not only is it not a constructor, but it also *can't* be one,
because the main characteristic of pattern matching in Haskell is that
it is (contrary to Prolog's unification) unambiguous (u
2009/7/15 minh thu :
> 2009/7/15 Magicloud Magiclouds :
>> Hi,
>> I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
>> could not be compiled, parse error.
>
> ++ is a function; you can't pattern-match on that.
But here you can match against (0:1:xs).
__
2009/7/15 Magicloud Magiclouds :
> Hi,
> I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
> could not be compiled, parse error.
++ is a function; you can't pattern-match on that.
Cheers,
Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@h
Hi,
I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
could not be compiled, parse error.
--
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tue, Jul 14, 2009 at 11:27 PM, Lyle Kopnicky wrote:
> If I am running GHC on 64-bit Windows, do I have a choice of building a
> 32-bit or 64-bit app? On a cursory glance through the command-line options,
> I didn't find anything.
I don't think there are cross-compiling version of GHC to be
down
On Wed, Jul 15, 2009 at 3:02 AM, Thomas Hartman wrote:
> Please suggest more of these types of exercises if you have them and
> maybe we can collect the folk wisdom into a wiki page and/or exercise
> page for beginners.
My 'stream' library[1] also has some examples. Look at the following
functions
38 matches
Mail list logo
