29 May 2001 22:44:38 +0200, Ketil Malde <[EMAIL PROTECTED]> pisze:
> Wouldn't
> x f g
> in a Forth'ish machine mean
> g(f,x) -- using "standard" math notation, for a change
> rather than
> g(f(x))
> ?
It depends whether f changes the value at top of the stack or only
p
On Tuesday, May 29, 2001, at 04:44 PM, Ketil Malde wrote:
> Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes:
>
> Wouldn't
> x f g
> in a Forth'ish machine mean
> g(f,x) -- using "standard" math notation, for a change
> rather than
> g(f(x))
> ?
In PostScript, a Forth der
Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes:
>> BTW, before I knew Haskell I exprimented with a syntax in which 'x f'
>> is the application of 'f' to 'x', and 'x f g' means '(x f) g'.
> Hmmm. An experimental syntax, you say...
> Oh, say, you reinvented FORTH?
Wouldn't
x f g
in a For
Marcin Kowalczyk:
> BTW, before I knew Haskell I exprimented with a syntax in which 'x f'
> is the application of 'f' to 'x', and 'x f g' means '(x f) g'. Other
> arguments can also be on the right, but in this case with parentheses,
> e.g. 'x f (y)' is a function f applied to two arguments.
Hm
Mon, 28 May 2001 10:23:58 +0100, Malcolm Wallace <[EMAIL PROTECTED]> pisze:
> It seems that right-associativity is so intuitive that even the
> person proposing it doesn't get it right. :-)
And even those who correct them :-)
>> f x (foldr1 f xs)f x foldr1 f xs
>
> Wouldn'
It seems that right-associativity is so intuitive that even the person
proposing it doesn't get it right. :-) Partial applications are a
particular problem:
> Haskell Non-Haskell
> Left Associative Right Associative
> From Prelude--
S. Alexander Jacobson writes:
| On Fri, 25 May 2001, Zhanyong Wan wrote:
| > As you explained, the parse of an expression depends the types of the
| > sub-expressions, which imo is BAD. Just consider type inference...
Also, we can no longer take a divide-and-conquer approach to reading
code,
At 05:25 PM 5/25/2001 -0400, S. Alexander Jacobson wrote:
>Admittedly, this is different from how haskell type checks now. I guess
>the question is whether it is impossible to type check or whether it just
>requires modification to the type checking algorithm. Does anyone know?
I don't thi
On Fri, 25 May 2001, Zhanyong Wan wrote:
> As you explained, the parse of an expression depends the types of the
> sub-expressions, which imo is BAD. Just consider type inference...
Ok, your complaint is that f a b c=a b c could have type
(a->b->c)->a->b->c or type (b->c)->(a->b)->a->c depending
"S. Alexander Jacobson" wrote:
>
> Does anyone know why the haskell designers did not make the syntax
> right associative? It would clean up a lot of stuff.
>
> Haskell Non-Haskell
> Left AssociativeRight Associative
> foo (bar (baz (x)))
Does anyone know why the haskell designers did not make the syntax
right associative? It would clean up a lot of stuff.
Haskell Non-Haskell
Left AssociativeRight Associative
foo (bar (baz (x))) foo bar baz x
foo $ bar $
Peter Douglass writes:
:
| but in ( foo ( bar (baz x) ) )
|
| You would want the following I think.
|
| foo . bar . baz x
|
| which does have the parens omitted, but requires the composition
| operator.
Almost. To preserve the meaning, the composition syntax would need to
be
Peter Hancock wrote:
> > foo( bar( baz( x ) ) )
> > it's:
> > (foo ( bar (baz x) ) )
>
> Clearly the outer parentheses are unnecessary in the last expression.
> One undeniable advantage of (f a) is it saves parentheses.
Yes and no. In
( ( ( foo bar) ba
Hi, you said
> Unfortunately in many cases you need to apply nearly as many
> parens for a Haskell expression as you would for a Python one, but
> they're in different places. It's not:
>
> foo( bar( baz( x ) ) )
> it's:
> (foo ( bar (baz x) ) )
Clearly t
Hi, you said
> Unfortunately in many cases you need to apply nearly as many
> parens for a Haskell expression as you would for a Python one, but
> they're in different places. It's not:
>
> foo( bar( baz( x ) ) )
> it's:
> (foo ( bar (baz x) ) )
Clearly t
[EMAIL PROTECTED] wrote:
> There's another piece to this question that we're overlooking, I
> think. It's not just a difference (or lack thereof) in precedence, it's the
> fact that parentheses indicate application in Python and many other
> languages, and a function name without parenthe
> -Original Message-
> From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 6:55 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Functional programming in Python
>
> Pertti Kellomäki <[EMAIL PROTE
> I realize this is a topic where it would be very easy to start a flame
> war, but hopefully we can avoid that.
No problem :-)
> Maybe I did not express my point clearly. What I was trying to say was
> that
> because of the syntax, it is very easy for M-C-q in Emacs to convert
> that to ...
Ok
I realize this is a topic where it would be very easy to start a flame
war, but hopefully we can avoid that.
Paul Hudak wrote:
> Why not have your tool generate layout-less code? Surely that would be
> easier to program, and be less error prone.
The tool in question is Happy, and the error mate
> Two points: I have been with Haskell less than half a year, and already
> I have run into a layout-related bug in a tool that produces Haskell
> source.
Why not have your tool generate layout-less code? Surely that would be
easier to program, and be less error prone.
> Second, to a Lisp-head
> > For humans, it is quite natural to use
> > visual cues (like layout) to indicate semantics.
I agree, but let us not try to do that with just two (already overloaded)
symbols.
> (let ((a 0)
> (b 1))
>(+ a b))
let { a = 0; b = 1; } in a + b
is valid Haskell and the way
"Manuel M. T. Chakravarty" wrote:
> In languages that don't use curring, you would write
> f (1, 2) + g (2, 3)
> which also gives application precedence over infix
> operators. So, I think, we can safely say that application
> being stronger than infix operators is the standard
> situation.
Ag
Pertti Kellomäki <[EMAIL PROTECTED]> wrote,
> > From: Ketil Malde <[EMAIL PROTECTED]>
> > "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> > > You want to be able to write
> >
> > > f 1 2 + g 3 4
> >
> > > instead of
> >
> > > (f 1 2) + (g 3 4)
> >
> > I do? Personally, I find it
> From: Ketil Malde <[EMAIL PROTECTED]>
> "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> > You want to be able to write
>
> > f 1 2 + g 3 4
>
> > instead of
>
> > (f 1 2) + (g 3 4)
>
> I do? Personally, I find it a bit confusing, and I still often get it
> wrong on the first att
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> You want to be able to write
> f 1 2 + g 3 4
> instead of
> (f 1 2) + (g 3 4)
I do? Personally, I find it a bit confusing, and I still often get it
wrong on the first attempt. The good thing is that the rule is simple
to remember.
> -Original Message-
> From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 14, 2001 10:46 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Functional programming in Python
>
> [EMAIL PROTECTED] wrote,
>
[EMAIL PROTECTED] wrote,
> > From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> > Absolutely. In fact, you have just pointed out one of the
> > gripes that I have with most Haskell texts and courses. The
> > shunning of I/O in textbooks is promoting the image of
> > Haskell as a p
> -Original Message-
> From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 12:57 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Functional programming in Python
>
[Bryn Keller] [snip]
>
On Tue, 8 May 2001, Erik Meijer wrote:
> Interestingly enough, I have the same feeling with Python!
Speaking of problems with Haskell, almost every time I write a larger
program, I'm frustrated with lack of efficient arrays/hashtables in the
standard. I know about ghc (I|U|M)Arrays for arrays an
[EMAIL PROTECTED] wrote,
> It's interesting to me to note the things that were interesting to
> you. :-) I'm the author of the Xoltar Toolkit (including functional.py)
> mentioned in those articles
Cool :-)
> and I have to agree with Dr. Mertz - I find
> Haskell much more palatable than
Interestingly enough, I have the same feeling with Python!
> As for the difficulty with imperative constructs, I agree it's not
> even an issue for many (Dylan, ML, et. al.) languages, but for Haskell it
> still is, in my humble opinion. I found the task of writing a simple
program
> that did a f
[SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, May 06, 2001 10:02 PM
> To: [EMAIL PROTECTED]
> Subject: Functional programming in Python
>
> Two quite interesting articles about FP in Python are over
> at IBM developerWorks:
>
> http://www-106.ibm.com/developerworks/lib
Two quite interesting articles about FP in Python are over
at IBM developerWorks:
http://www-106.ibm.com/developerworks/library/l-prog.html
http://www-106.ibm.com/developerworks/library/l-prog2.html
Two IMHO interesting things to note are the following:
* In Part 1, at the start, there is a
33 matches
Mail list logo
