I'm intrigued that Python has some functional constructions in the language.
Casey Hawthorne
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 functional transformations applied to it for efficiency.
That way, the syntax would be a lot easier to understand, than most
functional languages, like Haskell.
I gave a presentation at the beginning of last year on Haskell and at
the end, someone's comment was, "I can see the benefits of functional
programming but why does it have to be so cryptic."
--
Regards,
Casey
prue...@latinmail.com
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. Your
idea would be something that could be added to the PyPy project in the
future.
Carl Banks
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 compiled and have
> aggressive functional transformations applied to it for efficiency.
No not really, at least not in any way that it maintains compatibility
with Python.
Python does either expose or mimic the parsing process to the user, so
you could maybe exploit it to get parse trees of functions (checking
that there is nothing that has side-effects) to feed to a specialized
optimizer, but if you do that it might as well be a new langauge.
> That way, the syntax would be a lot easier to understand, than most
> functional languages, like Haskell.
>
> I gave a presentation at the beginning of last year on Haskell and at
> the end, someone's comment was, "I can see the benefits of functional
> programming but why does it have to be so cryptic."
A couple thoughts:
1. It's just one person's opinion.
2. However, functional programming is cryptic at some level no matter
how nice you make the syntax.
Carl Banks
namekuseijin
> 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 interpreter is not all that simple either. Have you ever
taken a look at it? It's a good bytecode interpreter, not some dumb toy
interpreter.
--
a game sig: http://tinyurl.com/d3rxz9
namekuseijin
> 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,
Python, Haskell or whatever: you're just calling functions provided by
the host, barely using any syntax or intrinsic language feature anyway.
Any language will do just fine.
Lawrence D'Oliveiro
> 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 is vital to the correct interpretation of functional constructs. See, for example,
<http://mail.python.org/pipermail/python-list/2008-October/683816.html>.
Carl Banks
> 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 application you could maybe argue that (and it'd be
a stretch), but there is no reasonable way to claim that syntax is
meaningless for defining functions. Unless you meant "function
declaration", and I think you did because you don't seem to know what
functional programming is.
> It's kinda like scripting, say, Microsoft Word in either Visual Basic,
> Python, Haskell or whatever:
No it's nothing like that at all.
> you're just calling functions provided by
> the host,
That's not what functional programming means, nor is it remotely
comparable to functional programming.
> barely using any syntax or intrinsic language feature anyway.
> Any language will do just fine.
Well, that's not true since I found it to be quite a different
experience to invoke Microsoft library functions in JScript than in
Visual Basic. (Mostly because it's a PITA even to "barely use any
syntax or intrinsic language feature" of Visual Basic.)
However, that has nothing to do with functional programming.
Carl Banks
namekuseijin
central.gen.new_zealand> wrote:
Yeah, it's important in an imperative language to have predefined
syntax to allow you to do things. Point taken.
namekuseijin
> On May 8, 1:56 pm, namekuseijin <namekusei...@gmail.com> 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 application you could maybe argue that (and it'd be
> a stretch), but there is no reasonable way to claim that syntax is
> meaningless for defining functions. Unless you meant "function
> declaration", and I think you did because you don't seem to know what
> functional programming is.
>
> > the host,
>
> That's not what functional programming means, nor is it remotely
> comparable to functional programming.
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. Office automation is all about calling predefined
functions in the host application, that's all my example was about.
Functional programming is all about defining functions and applying
functions. Core ML, Haskell and Scheme are all like that, pretty much
an extended lambda calculus. Haskell provides a bunch of syntatic
sugar, more so than Scheme for instance, but in the end, it all gets
converted into lambda expressions and application of arguments to
lambda expressions.
Python has a bunch of handy predefined syntax, because not everything
can be defined out of functions alone. Syntax is much more important
here than in true functional programming languages, where pretty much
everything besides basic "if" branching is a "userland" function --
including looping constructs. I have written my own list
comprehensions and generators in Scheme!
When you read a Haskell or Scheme program, it's truly hard to spot
predefined syntax: most of it is composable function application.
Once in a while you spot an "if".
> > barely using any syntax or intrinsic language feature anyway.
> > Any language will do just fine.
>
> Well, that's not true since I found it to be quite a different
> experience to invoke Microsoft library functions in JScript than in
> Visual Basic. (Mostly because it's a PITA even to "barely use any
> syntax or intrinsic language feature" of Visual Basic.)
Not quite Word, but here's in OpenOffice scripted either in BeanShell,
JScript and Java:
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Scripting/Writing_Macros
oDoc = context.getDocument();
xTextDoc = (XTextDocument) UnoRuntime.queryInterface
(XTextDocument.class,oDoc);
xText = xTextDoc.getText();
xTextRange = xText.getEnd();
xTextRange.setString( "Hello World (in BeanShell)" );
oDoc = XSCRIPTCONTEXT.getDocument();
xTextDoc = UnoRuntime.queryInterface(XTextDocument,oDoc);
xText = xTextDoc.getText();
xTextRange = xText.getEnd();
xTextRange.setString( "Hello World (in JavaScript)" );
XTextDocument xtextdocument = (XTextDocument) UnoRuntime.queryInterface
(
XTextDocument.class,
xDocModel);
XText xText = xtextdocument.getText();
XTextRange xTextRange = xText.getEnd();
xTextRange.setString( "Hello World (in Java)" );
Although this is a bad example because of the closeness of syntax
between the languages, it would not be much different in a completely
alien language. It would still make a call to get the data model of
the current document, another to get the text, another to get the end
and another to set the string. It's all function calls, really.
No, it's not functional programming, but it illustrates what I said:
when all you do is call functions, syntax is irrelevant.
Paul Rubin
> 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.
This doesn't fit Python semantics terribly well.
> That way, the syntax would be a lot easier to understand, than most
> functional languages, like Haskell.
I don't think it would help much, even if it was done (see below).
> I gave a presentation at the beginning of last year on Haskell and at
> the end, someone's comment was, "I can see the benefits of functional
> programming but why does it have to be so cryptic."
Haskell's syntax (like Python's or Lisp's) takes a little getting used
to, but in my experience it's not really cryptic. IMHO, functional
programming is difficult for imperative programmers to understand at
first, because the concepts in it are really different from what
imperative programmers are generally used to, and that take some head
scratching to make sense of. Think of a beginning imperative
programmer encountering recursion or coroutines for the first time, or
how someone learning calculus deals with the concepts of limits and
continuity. These subjects have certain hurdles that require effort
to get past, but which expand the range of problems that someone who
has put in the effort can solve. Functional programming presents more
such hurdles, and more such expansion.
Carl Banks
> 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 about defining functions and applying
> functions. Core ML, Haskell and Scheme are all like that,
Yet all three use a different syntax to call functions, none of them
the "pretty much the same way" you listed above.
Haskell, Python, and (I think) ML can define operators with different
syntax than function calls, that matters.
Haskell and Python have syntax for list operations, that matters.
Haskell nexts using indentation, the others nest using tokens(**),
that matters.
I can go on, but you get the idea. Point is: functional programmint
isn't "nothing but calling functions".
[snip irrelevant stuff about office scripting]
Carl Banks
(**) Python does using indentation to nest, of course, but not at the
expression level.
Paul Rubin
> 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 implemented using recursion, but in
practice, one doesn't see actual explicit recursion in Haskell code
all that often. Instead we see wide use of functions like map,
filter, and fold (a/k/a "reduce"), which can take the place of looping
constructs.
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.
namekuseijin
> On May 8, 5:47 pm, namekuseijin <namekusei...@gmail.com> 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 about defining functions and applying
> > functions. Core ML, Haskell and Scheme are all like that,
>
> Yet all three use a different syntax to call functions, none of them
> the "pretty much the same way" you listed above.
It's still functionName arguments AFAIK. Some using parentheses
around the arguments, some around all, some not using parentheses at
all.
> Haskell and Python have syntax for list operations, that matters.
>
> Haskell nexts using indentation, the others nest using tokens(**),
> that matters.
In Haskell, Lisp and other functional programming languages, any extra
syntax gets converted into the core lambda constructs. In Lisp
languages, that syntax is merely user-defined macros, but in Haskell
it's builtin the compiler for convenience.
> I can go on, but you get the idea. Point is: functional programmint
> isn't "nothing but calling functions".
Oh yes, functional programming is all about function definition and
function calling. You have a point about higher order functions, but
that's really only useful as far as your lambda expressions are useful
-- that is, conveniently defining anonymous functions on-the-fly and
immediately applying them.
Lie Ryan
> 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 functional transformations applied to it for efficiency.
Choosing a better algorithm usually have much more impact on efficiency
than programming to the language's optimization scheme. A slow algorithm
will always be slow no matter how much (functional or regular)
optimization in it[1]. If you bother efficiency that much, maybe python
is not the best suited language for you.
> That way, the syntax would be a lot easier to understand, than most
> functional languages, like Haskell.
Python's syntax is already easier to understand than most functional
language, and it also support functional-style programming. However,
python is still an imperative language, no matter how much functional
functionalities (pun not intended) is in it.
[1] of course there are certain types of optimizations -- that actually
changes the algorithm -- that may have a significant impact, such as
memoization. However if you know memoization well enough, you wouldn't
want to activate it on all pure functions...
Lawrence D'Oliveiro
a012-51b...@s28g2000vbp.googlegroups.com>, namekuseijin wrote:
> Yeah, it's important in an imperative language ...
That was an example of functional programming.
Carl Banks
> On May 8, 10:13 pm, Carl Banks <pavlovevide...@gmail.com> wrote:
>
> > On May 8, 5:47 pm, namekuseijin <namekusei...@gmail.com> 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 about defining functions and applying
> > > functions. Core ML, Haskell and Scheme are all like that,
>
> > Yet all three use a different syntax to call functions, none of them
> > the "pretty much the same way" you listed above.
>
> It's still functionName arguments AFAIK. Some using parentheses
> around the arguments, some around all, some not using parentheses at
> all.
Some using commas, some not, some grouping arguments by arity, some
not, some allowing keyword argument, some not, etc. Point is, even
the thing you claim hardly varies between languages does vary a
significant bit, but it's not nearly as much as other syntactic
differences in functional languages.
> > Haskell and Python have syntax for list operations, that matters.
>
> > Haskell nexts using indentation, the others nest using tokens(**),
> > that matters.
>
> 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
matter?
> In Lisp
> languages, that syntax is merely user-defined macros, but in Haskell
> it's builtin the compiler for convenience.
I don't even know what you're saying here
> > I can go on, but you get the idea. Point is: functional programmint
> > isn't "nothing but calling functions".
>
> Oh yes, functional programming is all about function definition and
> function calling.
Fine.
Functional programming isn't "nothing but calling functions USING
FUNCTION-CALL SYNTAX".
> You have a point about higher order functions, but
> that's really only useful as far as your lambda expressions are useful
> -- that is, conveniently defining anonymous functions on-the-fly and
> immediately applying them.
I made no such point. You may be confusing me with Paul, and I can't
imagine what higher-order functions have to do with whether syntax is
important or not.
Carl Banks
namekuseijin
I noticed the use of list comprehensions. The fact that list
comprehensions are only available as predefined syntax in Python is
noticed too.
namekuseijin
> On May 8, 7:19 pm, namekuseijin <namekusei...@gmail.com> wrote:
>> On May 8, 10:13 pm, Carl Banks <pavlovevide...@gmail.com> 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
> matter?
>> In Lisp
>> languages, that syntax is merely user-defined macros, but in Haskell
>> it's builtin the compiler for convenience.
>
> I don't even know what you're saying here
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.
In Haskell, point free style of programming shows almost no signs of
predefined syntax at all. It's all function composition.
In functional programming languages, predefined syntax is mostly
irrelevant. In Python and other imperative languages, it's absolutely
necessary. That's my point.
Steven D'Aprano
> 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? By mental telepathy? By direct
manipulation of the electromagnetic fields inside the CPU?
> In Haskell, point free style of programming shows almost no signs of
> predefined syntax at all. It's all function composition.
But it takes syntax in order to write function composition. There's at
least six ways of doing function composition:
f(g(x)) # used in many programming languages and mathematics
f . g (x) # Haskell
f o g (x) # mathematics
g f # stack-based languages like Forth
g x | f # Unix-like shells
compose(f, g)(x) # possible in many languages.
> In functional programming languages, predefined syntax is mostly
> irrelevant. In Python and other imperative languages, it's absolutely
> necessary. That's my point.
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.
--
Steven
Paul Rubin
> 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. (.) takes two functions as arguments
and returns a new function which composes f and g. 2 + 3 is the same
as (+) 2 3. f . g is the same as (.) f g. The infix notations
are considered syntax sugar. The parentheses around (+) and (.)
are so the compiler doesn't get lexically confused, but you could say
add = (+)
compose = (.)
a = add 2 3
b = compose square cube
c = b 2
now "print a" will print 5, and "print c" would print 64 (which is 2**6).
(There aren't actually builtins square and cube, but pretend there are).
So it's really true you can get rid of almost all Haskell expression
syntax. There's actually a preprocessor called Liskell that lets you
write Haskell as Lisp-like S-expressions, which is handy if you want
to use a macro processor on it.
Steven D'Aprano
> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> 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.
"Left-parens op right-parens" is syntax.
> 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 can you tell where one token finishes and
the next begins?
--
Steven
namekuseijin
> 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? By mental telepathy? By direct
> manipulation of the electromagnetic fields inside the CPU?
That's all the syntax notation you need in functional programming
languages: one to define functions, and another to call them. Any
extras are sugar around the basic definition and calling forms.
Carl Banks
wrote:
> Carl Banks wrote:
> > On May 8, 7:19 pm, namekuseijin <namekusei...@gmail.com> wrote:
> >> On May 8, 10:13 pm, Carl Banks <pavlovevide...@gmail.com> 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
> > matter?
> >> In Lisp
> >> languages, that syntax is merely user-defined macros, but in Haskell
> >> it's builtin the compiler for convenience.
>
> > I don't even know what you're saying here
>
> 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.
Nope, sorry, you're ignoring half the problem here. Syntax is only
irrelevant if you actually do do away with it. As long as syntax is
there and people use it, then it matters, regardless of whether it all
reduces to function calls.
For a very benign example, consider the ways that Python and Haskell
write listcomps:
[ x for x in ss ]
[ x | x <- ss ]
One of these might be more readable than the other (I make no
implication which); however, readability has nothing to do with
whether the compiler internally reduces it to a function call or not.
Readibility counts, therefore syntax matters.
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 minimalist syntax that turns people off.
If that syntax could be made a little more readable and workable,
maybe people wouldn't turn up their noses at it on first sight.
> In Haskell, point free style of programming shows almost no signs of
> predefined syntax at all. It's all function composition.
>
> In functional programming languages, predefined syntax is mostly
> irrelevant. In Python and other imperative languages, it's absolutely
> necessary. That's my point.
I think you are overstating this by a lot.
Carl Banks
Paul Rubin
I didn't say you could get rid of absolutely all of the syntax. Just
most of it. All that stuff you'd write in Python with loops,
if-statements, listcomps, etc. can be done with prefix function calls
in Haskell.
Haskell's type system, on the other hand, is much more complex than
Python's, and writing out type specifications does require some syntax.
Overall though, Haskell's syntax, either at the sugared or desugared
level, is not very complicated. The hurdles to learning Haskell
really are because the concepts it contains are really different than
what most programmers are familiar with. It's not like many languages
that contain familiar concepts wrapped in new syntax.
namekuseijin
> On May 9, 10:57 am, namekuseijin <namekuseijin.nos...@gmail.com>
> wrote:
>> Carl Banks wrote:
>>> On May 8, 7:19 pm, namekuseijin <namekusei...@gmail.com> wrote:
>>>> On May 8, 10:13 pm, Carl Banks <pavlovevide...@gmail.com> 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
>>> matter?
>>>> In Lisp
>>>> languages, that syntax is merely user-defined macros, but in Haskell
>>>> it's builtin the compiler for convenience.
>>> I don't even know what you're saying here
>> 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.
>
> Nope, sorry, you're ignoring half the problem here. Syntax is only
> irrelevant if you actually do do away with it. As long as syntax is
> there and people use it, then it matters, regardless of whether it all
> reduces to function calls.
It's handy, yes. It's just nothing special, specially when composing
programs out of function composition.
> For a very benign example, consider the ways that Python and Haskell
> write listcomps:
>
> [ x for x in ss ]
> [ x | x <- ss ]
>
> One of these might be more readable than the other (I make no
> implication which);
Haskell uses math notation, which may not be to everyone's tastes as far
as IT has largely left its compsci and math roots and every Joe Sixpack
might assembly an usable app with a scripting language, some
template-writing IDE and a few frameworks.
> however, readability has nothing to do with
> whether the compiler internally reduces it to a function call or not.
> Readibility counts, therefore syntax matters.
Function calls are perfectly readable.
> 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 minimalist syntax that turns people off.
BTW, rereading it again, the OP was originally questioning about
compiler optimizations for purely functional constructs within Python,
but somehow syntax got in the middle.
I don't see how "syntax would be a lot easier to understand" if it would
"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."
Syntax would remain the same, I guess.
>> In functional programming languages, predefined syntax is mostly
>> irrelevant. In Python and other imperative languages, it's absolutely
>> necessary. That's my point.
>
> I think you are overstating this by a lot.
Perhaps.
Carl Banks
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 minimalist syntax that turns people off.
>
> BTW, rereading it again, the OP was originally questioning about
> compiler optimizations for purely functional constructs within Python,
> but somehow syntax got in the middle.
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.
That's what makes your entire argument ridiculous; you are making this
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'
syntax sucks so bad in general.
> I don't see how "syntax would be a lot easier to understand" if it would
> "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."
>
> Syntax would remain the same, I guess.
You totally missed the point.
The thing that would make the syntax a lot easier to understand is
that it's in Python and not Haskell.
The reason the OP was asking about separating pure code from impure
was to see if some subset of Python could be used as a pure functional
language, that way they could employ Python and its already-much-
better-than-Haskell's syntax as a pedagogical replacement for Haskell.
I am sure there are many people who think that even "f a b" is cryptic
compared to "f(a,b)", but if that's the only issue it wouldn't be that
big of a deal. It's not the only issue. When a language requires you
to read and write stuff like "map :: (x -> y) -> f x -> f y" or "f s@
(x:xs) = x:s" then it's going to turn a lot of people off.
Carl Banks
Paul Rubin
> 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, like Haskell".
He didn't say that Haskell syntax caused him to look for alternatives
and didn't say that Haskell wouldn't still be difficult even if its
syntax were simpler. Hint: Liskell (Haskell with S-expression syntax)
is still difficult.
> yet people in the real world are out there trying to find
> alternatives because functional languages' syntax sucks so bad in general.
Again, I don't think so. Functional languages' syntax turns some
people off before they even look at other aspects closely, just like
Python's indentation-based syntax turns some people off. But, once
you get past the syntax, functional languages STILL present a lot of
obstacles that lots of users never get past.
> The reason the OP was asking about separating pure code from impure
> was to see if some subset of Python could be used as a pure functional
> language, that way they could employ Python and its already-much-
> better-than-Haskell's syntax as a pedagogical replacement for Haskell.
That wouldn't make sense at all. 60% of what makes Haskell different
(and harder) than Python is probably the complicated (but powerful)
static type system; 35% is the nonstrict evaluation strategy, and 5%
the syntax. If you somehow added a method in Python to separate pure
from impure code, but it was still a dynamic language with strict
evaluation, you'd only be 5% of the way to replacing Haskell.
namekuseijin
> On May 10, 12:40 pm, namekuseijin <namekuseijin.nos...@gmail.com>
> 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'
> syntax sucks so bad in general.
It's not that it sucks. More that it's pretty much non-existent.
Yes, many people are very sensitive to such issue -- that is, that
they feel lost without common constructs permeating the code rather
than the fluid and recursive nature of functional programming and its
never-ending flow of userland function calls.
OTOH, I can't help but think part of it has to do with plain text in
your face rather than lots of colorful keywords in your fav editor.
> The reason the OP was asking about separating pure code from impure
> was to see if some subset of Python could be used as a pure functional
> language, that way they could employ Python and its already-much-
> better-than-Haskell's syntax as a pedagogical replacement for Haskell.
ah, probably. Python has replaced Scheme in certain pedagogical
circles too. Scheme was considered a great tool for teaching basic
compsci concepts *precisely* for it's lack of syntax so that students
could concentrate on the concepts and problems at hand rather than
fight against the compiler or have to learn a huge tome of libs and
frameworks before even outputting a single "hello world".
But Java was all the rage in the past few years at introductory
compsci and at least no doubt Python is a blessing compared to that.
Though it too is not without a lot of quirks itself...
> I am sure there are many people who think that even "f a b" is cryptic
> compared to "f(a,b)", but if that's the only issue it wouldn't be that
> big of a deal. It's not the only issue. When a language requires you
> to read and write stuff like "map :: (x -> y) -> f x -> f y"
This is a type annotation and there's nothing similar in Python given
it's typeless nature. Should I call Python's non-existent type
annotations horrible too?
>"f s@ (x:xs) = x:s" then it's going to turn a lot of people off.
what about
@foobize
def dingle( n, *boz ): return boz[n:-2]
? Sounds perfectly cryptic for the non-initiated too.