Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
Any hints are appreciated.
Thanks
Harald.
Ce courriel
voigt:
Donald Bruce Stewart wrote:
harald.rotter:
Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
Richard O'Keefe [EMAIL PROTECTED] wrote:
Another change to the order to give us MORE sharing takes less time
AND less space. The surprise is how much less time.
Interesting stuff. My students and I briefly chatted about powerset
this morning and came up with the same function, but the very
Harald ROTTER [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.cafe:
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Donald
Bruce Stewart
andrewcoppin:
I don't know if anybody cares, but... Today a wrote some
trivial code to
decode (not encode) UTF-16.
I believe somebody out there has a UTF-8 decoder, but I
needed UTF-16 as it
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Donald
Bruce Stewart
Does anyone know why Takusen isn't on hackage yet? It appears to be
cabalised, and have a tarball:
http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Database
harald.rotter:
Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
Any hints are appreciated.
On Thursday 26 July 2007, Harald ROTTER wrote:
Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
As
A bandaid suggestion:
longFunctionName various and sundry arguments = f where
f | guard1 = body1
f | guard2 = body2
| ...
where declarations
(Disclaimer: untested)
As I understand it, there can be guards on the definition of f even if
it takes no arguments. Those guards can reference your
On Thu, Jul 26, 2007 at 02:58:21PM -0500, Nicolas Frisby wrote:
A bandaid suggestion:
longFunctionName various and sundry arguments = f where
f | guard1 = body1
f | guard2 = body2
| ...
where declarations
(Disclaimer: untested)
As I understand it, there can be guards on the
Another advantage here - an analog I'm always eager to point out - is
that just as we can augment functions if they haven't yet been fixed,
we can augment functors. One can extend datatypes and functions (a la
open functions) or generically generate constructs such as (co-)free
(co-)monads in
Dan Weston wrote:
1) Commenting out the type annotation f :: Bool makes the program hang
Turning on code optimizations (e.g., ghc -O) helps. I don't know why.
2) If I replace f = f by f = undefined, I get an annoying print of
LazyOr: Prelude.undefined before it returns the correct value.
Thank you Jonathan for your answer, it really helped me find the solution,
which, just for the record, was:
correctLabelGenerator =
do s - choose (1, 63 :: Int)
liftM2 (:) (elements validFirstChars) (replicateM (s - 1) (elements
validChars))
where validFirstChars = ['a'..'z'] ++
Stefan O'Rear wrote:
Out of curiousity, what do you find objectionable about (legal):
function argument argument2
| guard = body
| guard = body
as compared to (currently illegal):
function argument argument2
| guard = body
| guard = body
I see the vertical strokes as visually lining up,
On Thu, Jul 26, 2007 at 08:17:06PM -0400, anon wrote:
but one could likewise dismiss the entire layout business as a
needlessly complicated way to save a few keystrokes if one were so
inclined.
The main point of layout, in my eyes, is to make code more readable.
It achieves this both by
Concerning
function argument argument2
| guard = body
| guard = body
I feel that anything that prevents that kind of horror is
a great benefit of the current rules and that this benefit
must not be lost by any revision of the rules.
The Fundamental Law of Indentation is
If major syntactic
2007/7/26, Stefan O'Rear [EMAIL PROTECTED]:
Out of curiousity, what do you find objectionable about (legal):
function argument argument2
| guard = body
| guard = body
as compared to (currently illegal):
function argument argument2
| guard = body
| guard = body
The extra space, obviously
On 7/26/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
The non-termination is (probably) due to the fact that you can have
uninterruptible threads in ghc.
If a thread never allocates it will never be preempted. :(
To elaborate on that, the different behavior between the two versions
of
On Thu, 2007-07-26 at 12:04 -0500, Spencer Janssen wrote:
On Thursday 26 July 2007 11:02:00 Jon Harrop wrote:
On Thursday 26 July 2007 17:03:31 C.M.Brown wrote:
Hi Jon,
On Thu, 26 Jul 2007, Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be
Whoops, read too fast. Sorry for the noise.
On 7/26/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007 at 02:58:21PM -0500, Nicolas Frisby wrote:
A bandaid suggestion:
longFunctionName various and sundry arguments = f where
f | guard1 = body1
f | guard2 = body2
| ...
On Thursday 26 July 2007 11:02:00 Jon Harrop wrote:
On Thursday 26 July 2007 17:03:31 C.M.Brown wrote:
Hi Jon,
On Thu, 26 Jul 2007, Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other
languages?
Yes,
Melissa O'Neill wrote:
BUT, it generates the output in an order that'll accommodate infinite
lists, thus we can say:
power_list [1..]
-- Count in binary and use that to create power set
power_list xs = loop zero where
[snip code that works lazily without wasting memory and
On 7/26/07, Nicolas Frisby [EMAIL PROTECTED] wrote:
Trying to summarize in one phrase: you can do interesting
manipulations to functions before applying fix that you cannot do to
functions after applying fix (conventional functions fall in this
second category).
Something similar holds for
I installed this and ran the sample program at
http://www.b7j0c.org/content/haddock/finance-quote-yahoo/Finance-Quote-Yahoo.html
This timed out. I suspect, because I am behind a corporate proxy server.
$ env | grep -i http
http_proxy=http://myproxy.com:3128
ross:
On Fri, Jul 27, 2007 at 12:08:30AM +1000, Donald Bruce Stewart wrote:
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents =
On Fri, Jul 27, 2007 at 12:08:30AM +1000, Donald Bruce Stewart wrote:
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents = (lines map read
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents = (lines map read sum print)
Indeed, all Arrow ops are infixr.
Are there any technical/compelling
Melissa O'Neill wrote:
For example, consider yet another variant of power_list:
power_list l = [] : pow [[]] l where
pow acc [] = []
pow acc (x:xs) = acc_x ++ pow (acc ++ acc_x) xs
where acc_x = map (++ [x]) acc
By many standards, this version is inefficient, with plenty of
Hello Alistair,
Thursday, July 26, 2007, 12:29:06 PM, you wrote:
Obviously a proliferation of UTF8 modules isn't great for code re-use.
Is there a plan to consolidate and expose UTF8 and UTF16 de- and
encoders in the libraries?
afair there is utf-string module, which provides utf-8
Hello Donald,
Thursday, July 26, 2007, 8:13:37 AM, you wrote:
I don't know if anybody cares, but... Today a wrote some trivial code to
decode (not encode) UTF-16.
These functions already exist in win-specific part of base:
cWcharsToChars :: [CWchar] - [Char]
charsToCWchars :: [Char] -
Jon Fairbairn wrote:
I currently only get f :: [t] - something, so if I later
discover that I need to change the input representation to
be more efficient than lists, I have to rewrite f. Wouldn't
it be so much nicer if I could simply add a declaration
f:: Stream s = s t - something
and get
Ok, I am evaluating HDBC. I wrote a simple test program:
...
Can I get a more specific error? Is there a way to inspect this exception
more deeply?
handleSqlError does the trick, for other newbies:
main =
handleSqlError $
do
dbc - connectPostgreSQL dbname=test user=postgres
On Thu, Jul 26, 2007 at 08:17:06PM -0400, anon wrote:
2007/7/26, Stefan O'Rear [EMAIL PROTECTED]:
Out of curiousity, what do you find objectionable about (legal):
function argument argument2
| guard = body
| guard = body
as compared to (currently illegal):
function argument argument2
Hi
Why do you think it should be allowed? The current rules are arbitrary,
but they are quite simple; we don't want to add an ad-hoc exception just
for this.
The current rules are already quite complex, I believe there is some
thought being given as to how to simplify them.
Out of
The non-termination is (probably) due to the fact that you can have
uninterruptible threads in ghc.
If a thread never allocates it will never be preempted. :(
-- Lennart
On 7/24/07, Dan Weston [EMAIL PROTECTED] wrote:
I am trying to get my feet wet with Haskell threads with the following
On Thu, Jul 26, 2007 at 02:56:57PM -0400, anon wrote:
Greetings,
I wish to be able to indent my code like so:
longFunctionName various and sundry arguments
| guard1 = body1
| guard2 = body2
| ...
where declarations
That is, with guards and where clauses indented to the same level as
the
On Thu, Jul 26, 2007 at 01:34:24PM -0400, Thomas Hartman wrote:
I installed this and ran the sample program at
http://www.b7j0c.org/content/haddock/finance-quote-yahoo/Finance-Quote-Yahoo.html
This timed out. I suspect, because I am behind a corporate proxy server.
i am sorry you are
On Thu, Jul 26, 2007 at 05:08:33PM +0100, Jon Harrop wrote:
I've heard that there are a plethora of Haskell compilers available. Which
others give performance comparable to GHC?
Jhc - experimental whole program compiler. slightly better than jhc,
but not by much due to a lack of
Hi
I've heard that there are a plethora of Haskell compilers available. Which
others give performance comparable to GHC?
None. If you want a stable, well supported, currently maintained, fast
Haskell compiler, then that's GHC. (in fact, if you drop fast from
that list, you are still left with
I've heard that there are a plethora of Haskell compilers available. Which
others give performance comparable to GHC?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
I think we got this to work. We had to connect to MS SQL Server via odbc.
Geoffrey Zhu [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
07/25/2007 06:11 PM
To
cc
haskell-cafe@haskell.org
Subject
Re: [Haskell-cafe] HDBC or HSQL
Hi,
I use HSQL with PostgreSQL bindings. It works great
Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other languages?
Yes, although the meaning of the phrase evaluated before is a bit
tricky in a lazy language, so it's probably better to state it with
denotational semantics
On Thursday 26 July 2007 17:03:31 C.M.Brown wrote:
Hi Jon,
On Thu, 26 Jul 2007, Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other languages?
Yes, I believe it is defined thus:
True || _= True
_|| True
Hi Jon,
On Thu, 26 Jul 2007, Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other languages?
Yes, I believe it is defined thus:
True || _= True
_|| True = True
_|| _= False
Therefore it is strict in
I think what you're describing is equivalent to making the implicit
view function syntax so terse that you don't write anything at all. So
the pattern 'p' is always (view - p). This seems like a pretty
invasive change:
I don't think the version with the functional dependency works (unless
you
On Thursday 26 July 2007, Harald ROTTER wrote:
Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
Any
Dan Licata wrote:
apfelmus wrote:
The idea is to introduce a new language extension, namely the ability to
pattern match a polymorphic type. For demonstration, let
class ViewInt a where
view :: Integer - a
instance ViewInt [Bool] where
view n = ... -- binary representation
Donald Bruce Stewart wrote:
harald.rotter:
Hi,
I read about the usage of fix to define recursive functions. Although I
think that I understood how to use fix, I still wonder what the
advantages of fix are (as compared to the conventional approach to
define recursive functions).
Any hints are
Greetings,
I wish to be able to indent my code like so:
longFunctionName various and sundry arguments
| guard1 = body1
| guard2 = body2
| ...
where declarations
That is, with guards and where clauses indented to the same level as
the function name.
This seems like a perfectly reasonable
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other languages?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
On 7/26/07, Tim Chevalier [EMAIL PROTECTED] wrote:
To elaborate on that, the different behavior between the two versions
of Dan's code, one with and one without a type signature, happens
because f compiles like so if the type signature isn't given (this is
the STG code):
f_ri5 = \u []
2007/7/26, Stefan O'Rear [EMAIL PROTECTED]:
As for why, it's just a matter of Haskell Committee taste. Nothing
too deep, just an arbitrary set of rules.
That's not much of an explanation, is it? I imagine someone must have
given the matter some thought before describing the layout rule in
On Thu, Jul 26, 2007 at 05:34:32PM -0400, anon wrote:
2007/7/26, Stefan O'Rear [EMAIL PROTECTED]:
As for why, it's just a matter of Haskell Committee taste. Nothing
too deep, just an arbitrary set of rules.
That's not much of an explanation, is it? I imagine someone must have
given the
On Thursday 26 July 2007, Jon Harrop wrote:
If you have a boolean-or expression:
a || b
will a be evaluated before b in Haskell as it is in other languages?
Yes.
The definition of (||) is roughly
True || b = True
False || b = b
Which de-sugars to
(||) = \ a b - case a of
True - True
Just casting my vote for the helpfulness of this reference.
Trying to summarize in one phrase: you can do interesting
manipulations to functions before applying fix that you cannot do to
functions after applying fix (conventional functions fall in this
second category).
On 7/26/07, Chung-chieh
On Thursday 26 July 2007, anon wrote:
2007/7/26, Stefan O'Rear [EMAIL PROTECTED]:
Out of curiousity, what do you find objectionable about (legal):
function argument argument2
| guard = body
| guard = body
as compared to (currently illegal):
function argument argument2
|
2007/7/26, ok [EMAIL PROTECTED]:
The Fundamental Law of Indentation is
If major syntactic unit X is a proper part of major syntactic
unit Y, then every visible character of X is strictly to the
right[%] of the leftmost[%] visible character of Y.
[%] If you are using a right-to-left
Hi Dan
On 25 Jul 2007, at 15:18, Dan Licata wrote:
Hi Conor,
[..]
Why are you so fatalistic about with in Haskell?
I guess I'm just fatalistic, generally. Plausibility is not something
I'm especially talented at.
Is it harder to
implement than it looks?
For Haskell, it ought to be
On 7/27/07, Neil Mitchell [EMAIL PROTECTED] wrote:
Personally, I have no problem with the current way (and would consider
anything other than 4 leading spaces in the first example to be evil).
However, if you are using a text editor which doesn't automatically
indent the start of following
Ok, I'm writing a command line tool, using System.Console.GetOpt to
handle command line arguments. My Flags structure so far is
data Flag
= Filter String
| DateFormat String
| DocStart String
| DocEnd String
...
and I want to write accessor functions that return the strings
Hi,
Not sure if this will help avoid the boilerplate, but I've always liked
the approach at
http://leiffrenzel.de/papers/commandline-options-in-haskell.html
(particularly the section Towards a higher level) for being able to
specify defaults. It's the best resource I've found on command line
61 matches
Mail list logo
