On May 10, 7:18 pm, Carl Banks wrote:
> On May 10, 12:40 pm, namekuseijin
> wrote:
> theoretical argument like, "everything reduces to a function so it
> doesn't matter what syntax you use," yet people in the real world are
> out there trying to find alternatives because functional languages'
> s
Carl Banks writes:
> Syntax--the thing you claim doesn't matter--got in the middle because
> it was the main factor that drove the OP to look for alternatives to
> Haskell.
I don't think so. The OP said that "... the syntax would be a lot
easier to understand, than most functional languages, li
On May 10, 12:40 pm, namekuseijin
wrote:
> Carl Banks wrote:
> > Now, maybe readability concerns don't matter to you personally, but it
> > does matter to the OP, who is trying to advocate functional
> > programming but is having difficulty because most purely functional
> > languages have hideous
Carl Banks wrote:
On May 9, 10:57 am, namekuseijin
wrote:
Carl Banks wrote:
On May 8, 7:19 pm, namekuseijin wrote:
On May 8, 10:13 pm, Carl Banks wrote:
In Haskell, Lisp and other functional programming languages, any extra
syntax gets converted into the core lambda constructs.
So? The us
> Python also has higher-order functions like that, but their use is
> disfavored in certain circles. With Python 3, there has actually been
> movement towards removing them from the language.
... Buh? Reduce was moved to functools, map and filter weren't touched;
there was some discussion befor
Steven D'Aprano writes:
> > So it's really true you can get rid of almost all Haskell expression
> > syntax.
>
> And what you've got left is syntax. Without syntax, how can you tell the
> difference between a meaningful character string and a jumble of random
> gibberish? Without syntax, how ca
On May 9, 10:57 am, namekuseijin
wrote:
> Carl Banks wrote:
> > On May 8, 7:19 pm, namekuseijin wrote:
> >> On May 8, 10:13 pm, Carl Banks wrote:
> >> In Haskell, Lisp and other functional programming languages, any extra
> >> syntax gets converted into the core lambda constructs.
>
> > So? The
Steven D'Aprano wrote:
On Sat, 09 May 2009 14:57:24 -0300, namekuseijin wrote:
I'm saying syntax is nothing special. They are user-defined, as
functions. And it all gets converted into functions. Functions matter,
syntax is irrelevant because you can do away with it.
How do you call functi
On Sat, 09 May 2009 12:08:49 -0700, Paul Rubin wrote:
> Steven D'Aprano writes:
>> I think your point is wrong. Without syntax, there can be no written
>> communication. In Haskell, f.g is not the same as f+g -- the difference
>> is one of syntax.
>
> In Haskell, (+) and (.) are both functions.
Steven D'Aprano writes:
> I think your point is wrong. Without syntax, there can be no written
> communication. In Haskell, f.g is not the same as f+g -- the difference
> is one of syntax.
In Haskell, (+) and (.) are both functions. (+) takes two numbers as
arguments and returns their sum. (.
On Sat, 09 May 2009 14:57:24 -0300, namekuseijin wrote:
> I'm saying syntax is nothing special. They are user-defined, as
> functions. And it all gets converted into functions. Functions matter,
> syntax is irrelevant because you can do away with it.
How do you call functions without syntax? B
Carl Banks wrote:
On May 8, 7:19 pm, namekuseijin wrote:
On May 8, 10:13 pm, Carl Banks wrote:
In Haskell, Lisp and other functional programming languages, any extra
syntax gets converted into the core lambda constructs.
So? The user still uses that syntax, so how can you claim it doesn't
m
Lawrence D'Oliveiro wrote:
In message <692b7ae8-0c5b-498a-
a012-51bda980f...@s28g2000vbp.googlegroups.com>, namekuseijin wrote:
On May 8, 6:48 pm, Lawrence D'Oliveiro wrote:
In message , namekuseijin wrote:
Carl Banks escreveu:
2. However, functional programming is cryptic at some level no
On May 8, 7:19 pm, namekuseijin wrote:
> On May 8, 10:13 pm, Carl Banks wrote:
>
> > On May 8, 5:47 pm, namekuseijin wrote:
>
> > > My point is that when all you do is call functions, syntax is
> > > irrelevant. You call functions pretty much in the same way regardless
> > > of language: funct
In message <692b7ae8-0c5b-498a-
a012-51bda980f...@s28g2000vbp.googlegroups.com>, namekuseijin wrote:
> On May 8, 6:48 pm, Lawrence D'Oliveiro central.gen.new_zealand> wrote:
>> In message , namekuseijin wrote:
>>
>> > Carl Banks escreveu:
>>
>> >> 2. However, functional programming is cryptic at
Casey Hawthorne wrote:
I'm intrigued that Python has some functional constructions in the
language.
Would it be possible to more clearly separate the pure code (without
side effects) from the impure code (that deals with state changes,
I/O, etc.), so that the pure code could be compile
On May 8, 10:13 pm, Carl Banks wrote:
> On May 8, 5:47 pm, namekuseijin wrote:
>
> > My point is that when all you do is call functions, syntax is
> > irrelevant. You call functions pretty much in the same way regardless
> > of language: functionname, optionalOpenPar, parameters,
> > optionalCl
Carl Banks writes:
> I can go on, but you get the idea. Point is: functional programmint
> isn't "nothing but calling functions".
I would mainly describe functional programming as programming with the
pervasive use of higher order functions. For example, loops in
functional programming can be i
On May 8, 5:47 pm, namekuseijin wrote:
> My point is that when all you do is call functions, syntax is
> irrelevant. You call functions pretty much in the same way regardless
> of language: functionname, optionalOpenPar, parameters,
> optionalClosePar.
then...
> Functional programming is all a
Casey Hawthorne writes:
> Would it be possible to more clearly separate the pure code (without
> side effects) from the impure code (that deals with state changes,
> I/O, etc.), so that the pure code could be compiled and have
> aggressive functional transformations applied to it for efficiency.
On May 8, 7:22 pm, Carl Banks wrote:
> On May 8, 1:56 pm, namekuseijin wrote:
> > Carl Banks escreveu:
> > > 2. However, functional programming is cryptic at some level no matter
> > > how nice you make the syntax.
>
> > When your program is nothing but function definition and function
> > applic
On May 8, 6:48 pm, Lawrence D'Oliveiro wrote:
> In message , namekuseijin wrote:
>
> > Carl Banks escreveu:
>
> >> 2. However, functional programming is cryptic at some level no matter
> >> how nice you make the syntax.
>
> > When your program is nothing but function definition and function
> > ap
On May 8, 1:56 pm, namekuseijin wrote:
> Carl Banks escreveu:
>
> > 2. However, functional programming is cryptic at some level no matter
> > how nice you make the syntax.
>
> When your program is nothing but function definition and function
> application, syntax is meaningless.
For mere function
In message , namekuseijin wrote:
> Carl Banks escreveu:
>
>> 2. However, functional programming is cryptic at some level no matter
>> how nice you make the syntax.
>
> When your program is nothing but function definition and function
> application, syntax is meaningless.
On the contrary, syntax
Carl Banks escreveu:
2. However, functional programming is cryptic at some level no matter
how nice you make the syntax.
When your program is nothing but function definition and function
application, syntax is meaningless.
It's kinda like scripting, say, Microsoft Word in either Visual Basic
prueba...@latinmail.com escreveu:
Don't forget that the Python interpreter is simple. It makes
maintenance easier and allows embedding it into other programs. Good
optimizing compilers for functional languages are not simple.
Good optimizing compilers are not simple, period.
The python interpr
On May 8, 12:04 pm, Casey Hawthorne
wrote:
> I'm intrigued that Python has some functional constructions in the
> language.
>
> Would it be possible to more clearly separate the pure code (without
> side effects) from the impure code (that deals with state changes,
> I/O,
On May 8, 3:04 pm, Casey Hawthorne wrote:
> I'm intrigued that Python has some functional constructions in the
> language.
>
> Would it be possible to more clearly separate the pure code (without
> side effects) from the impure code (that deals with state changes,
> I/O,
I'm intrigued that Python has some functional constructions in the
language.
Would it be possible to more clearly separate the pure code (without
side effects) from the impure code (that deals with state changes,
I/O, etc.), so that the pure code could be compiled and have
aggressive funct
29 matches
Mail list logo
