Why I don't use Ruby.

S

Sean O'Dell

Sean O'Dell said:

One of the benefits of functional languages is the ability to do
algebraic-like manipulations of the source code ... kinda like provably
correct refactorings. For example, given X=12, within the scope of X I
can replace all occurances of X with the value 12 (or the reverse, replace
all occurances of 12 with X). If X is sometimes 12 and sometimes 13, then
the substitution is no longer valid anywhere in the scope of X. That is
why even local variables are immutable in a "pure" functional language.

But this is more of an implementation feature. Tail recursion optimization
and currying are features, not really part of the true definition of a
functional language. You could make C's variables totally immutable and
pre-process C code in the same way. It's a feature that's easy to do with
functional languages, but I don't think truly at the heart of them. Having
mutable, local variables in a functional language disables such features, but
the language is still a functional one.
Function being defined as an operation that returns the same result given
the same input, right? Operators in functional languages are functions in
this sense. The difference is a matter of syntax, not semantics. E.g.
1+2 is allowed in a functional language. The binary operator + is treated
as a two argument function.

Yes, precisely what I meant.

Sean O'Dell
 
S

Sean O'Dell

Most of those operators are exactly like functions. = isn't if its an
assignment operator, but if it is an comparison operator it indeed is
compatible to the definition of the function.

(Just because there's a different syntax for applying it doesn't mean
that it's really different -- in fact in LISP + is just a function with
a special name without any additional syntactic sugar.)

I know, but I was trying to illustrate how some people seem to get the rule
against assignment operators confused with simple assignment. You can assign
values to variables in a functional language, you just have to do it through
a function call; the assignment is permitted, however. We're in agreement.
Functional languages don't enforce a specific syntax like function(arg1,
arg2) etc., but they indeed specify that a function should have no side
effects which means that the only way it should be able to interact with
the outside world is by returning values. (Lambda calculus is the origin
of functional languages and compared to computer languages its syntax is
indeed very exotic.)

Unless something has changed, functional languages DO have to enforce a
specific syntax; it must be functional (call, parameter). The precise syntax
is up to each language; lisp does it something like (set a 10) I believe, but
another language could do it set(a, 10). It really doesn't matter.
I hope I was able to add something valuable.

You did, because I didn't realize that what I had said came out to sound as
though I were asserting a specific syntax was needed. The only real rule
about assignment, I believe (been a long time), is that it must be in a
functional form, and operators are not allowed (can't do a=10).

Sean O'Dell
 
F

Florian Gross

Sean said:
But how are they usually implemented? In ASM, C, ... ?

What are ASM interpreters implemented in? What are lambda calculus
interpreters (mathematicians) implemented in?

And also note that there *are* machines out there that use LISP as their
native language. (Which means that everything on them, even C compilers,
are implemented in LISP.) :)
Precisely. What is returned is most important; functions must return
consistent results for a given set of parameters, regardless of when they are
called or how often.

This is one important aspect, yes, but this definition still allows side
effects which are disallowed in purely functional languages.
But within a function, local variables don't affect the return value. True,
every new function a developer writes could be simply nested calls to other
functions, but for readability, local variables are very helpful, and as long
as they're not global or stateful, they don't affect the return value, so to
the outside world it's still just a function.

Yes, I didn't say that aliases for values were forbidden -- they're just
not necessary in purely functional languages, because you can replace
every refer with the alias to the computation. It's even reasonable to
assume that the languages interpreter will automatically factor out
multiple calls to the same function with the same arguments automatically.

And also note that your program won't be functional anymore when it
depends on a non-functional function, because calling it is usually seen
as replacing its call with its body with arguments inserted into the
right places. (This is inherited from lambda calculus.)
Think of new functions that developers write in the language as part of the
implementation itself. You can give them tools to write new functions in the
language which don't allow them to break the functional language paradigms,
such as local variables, just like you can implement a functional language
such a C, which is definitely NOT a functional language.

If you give them something then it's part of your interface. If
non-functionality is part of your interface then you can't be purely
functional anymore in my opinion.

Regards,
Florian Gross
 
F

Florian Gross

Sean said:
I know, but I was trying to illustrate how some people seem to get
the rule against assignment operators confused with simple
assignment. You can assign values to variables in a functional
language, you just have to do it through a function call; the
assignment is permitted, however. We're in agreement.

I'm not sure we're that rule is coming from -- do you remember any
sources for this or could you try to explain why it exists for yourself?

I've not seen it before -- I think the only restriction about all this
is that assignment is only a way of aliasing functions or results of
function calls, but nothing more than a notation. (Which means that it
doesn't really give any more power to you than you already had without it.)
Unless something has changed, functional languages DO have to enforce
a specific syntax; it must be functional (call, parameter). The
precise syntax is up to each language; lisp does it something like
(set a 10) I believe, but another language could do it set(a, 10).
It really doesn't matter.

Well, all you need to do is providing a way to define and apply
functions and some basic built-in functions to make the language
turing-complete. (Unlambda states that only the K- and S-combinators are
needed for defining a turing-complete language, but I still don't
understand this completely.)

I'm not sure if we're saying the same or something different regarding
this point. :)
The only real rule about assignment, I believe (been a long time), is
that it must be in a functional form, and operators are not allowed
(can't do a=10).

Why? Where's the difference? :)

Regards,
Florian Gross
 
S

Sean O'Dell

I'm not sure we're that rule is coming from -- do you remember any
sources for this or could you try to explain why it exists for yourself?

I just found a great primer on FP, and I think I have either forgotten a lot
of it from my LISP days, or LISP never had these FP features I'm reading
about. This is really a very authoritative, clear and concise explanation:

http://www.cs.nyu.edu/goldberg/pubs/gold96.pdf

Sean O'Dell
 
M

Mikael Brockman

Sean O'Dell said:
I just found a great primer on FP, and I think I have either forgotten a lot
of it from my LISP days, or LISP never had these FP features I'm reading
about. This is really a very authoritative, clear and concise explanation:

http://www.cs.nyu.edu/goldberg/pubs/gold96.pdf

Do you realize that paper disproves both of your claims? It uses
operators and explicitly disallows all assignment and side-effects.

mikael
 
F

Florian Gross

Sean said:
I just found a great primer on FP, and I think I have either forgotten a lot
of it from my LISP days, or LISP never had these FP features I'm reading
about. This is really a very authoritative, clear and concise explanation:

http://www.cs.nyu.edu/goldberg/pubs/gold96.pdf

Heh, I actually meant to say what's written there on the first page with
all that "variables are just aliases" speech.

If you intended to say this, too, then we're already agreeing here. :)

(Which means that this special aliasing assignment can be done via an
operator-style syntax or a function-call-style syntax. This also means
that operators and functions are actually the same things with different
syntaxes. :))

Oh, and I think that let x = y is actually an operator-style syntax.

Regards,
Florian Gross
 
S

Sean O'Dell

Heh, I actually meant to say what's written there on the first page with
all that "variables are just aliases" speech.

If you intended to say this, too, then we're already agreeing here. :)

Well, I was talking about variables, but I realized after looking at that
primer that I think most people were talking about "macros" or, at least,
that's what I remember calling them. It's been a long time, and LISP was my
only exposure to FP, really. I think I was mis-understanding some of the
terms people were using.
(Which means that this special aliasing assignment can be done via an
operator-style syntax or a function-call-style syntax. This also means
that operators and functions are actually the same things with different
syntaxes. :))

Oh, and I think that let x = y is actually an operator-style syntax.

It sure is; I think I just got a really skewed version of FP in my head.

Sean O'Dell
 
G

gabriele renzi

il Wed, 14 Jul 2004 06:52:18 +0900, "Sean O'Dell" <[email protected]>
ha scritto::

Unless something has changed, functional languages DO have to enforce a
specific syntax; it must be functional (call, parameter). The precise syntax
is up to each language; lisp does it something like (set a 10) I believe, but
another language could do it set(a, 10). It really doesn't matter.

not necessarily.
IIRC Haskell, wich is known as one of the purest functrional language
allows
arg1 `function` arg2
:)
 
Z

zuzu

Well, I was talking about variables, but I realized after looking at that
primer that I think most people were talking about "macros" or, at least,
that's what I remember calling them. It's been a long time, and LISP was my
only exposure to FP, really. I think I was mis-understanding some of the
terms people were using.

waaaaaay back in the thread, i said:

also, assignment in ruby is much improved over von neumann C-style
assignment. in ruby assignment is merely the naming of objects for
convenient reference (like pointers). see "Assignment" @
http://www.rubycentral.com/book/tut_expressions.html correct me if
i'm wrong, but isn't this essentially what functional programming
languages call "macros"?

i suppose this has been clarified?
 
J

Jim Weirich

I see elsewhere in this thread you found a functional primer that may
resolve some of these issues. I'll just respond to one thing here ...
One of the benefits of functional languages is the ability to do
algebraic-like manipulations of the source code ... kinda like provably
correct refactorings. For example, given X=12, within the scope of X I
can replace all occurances of X with the value 12 (or the reverse, replace
all occurances of 12 with X). If X is sometimes 12 and sometimes 13, then
the substitution is no longer valid anywhere in the scope of X. That is
why even local variables are immutable in a "pure" functional language.

But this is more of an implementation feature. [...]
You could make C's variables totally immutable and
pre-process C code in the same way. It's a feature that's easy to do with
functional languages, but I don't think truly at the heart of them. Having
mutable, local variables in a functional language disables such features, but
the language is still a functional one.

John Backus's 1977 Turing Award speech was entitled "Can Programming Be
Liberated from the von Neumann Style? A Functional Style and Its Algebra
of Programs". Even in the title of the speech emphasized the ability to
meaningfully manipulate and transform programs. This is hardly an
"implementation detail" of functional languages. It is why computer
scientists were interested in functional languages in the first place.

Quoting from the abstract:

"Associated with the functional style of programming is an algebra of
programs whose variables range over programs and whose operations are
combining forms. This algebra can be used to transform programs and to
solve equations whose "unknowns" are programs in much the same way one
transforms equations in high school algebra. These transformations are
given by algebraic laws and are carried out in the same language in
which programs are written. Combining forms are chosen not only for
their programming power but also for the power of their associated
algebraic laws. General theorems of the algebra give the detailed
behavior and termination conditions for large classes of programs."
 
N

Nicholas Van Weerdenburg

In University, I worked with a language called Turing that had both
procedures and functions. Is that a common idiom?

In Ruby, would it be possible to extend "def" and maybe introduce a
feature called "func" that adds some extra rules to what can be coded?

Thanks,
Nick
 
L

Lennon Day-Reynolds

also, assignment in ruby is much improved over von neumann C-style
assignment. in ruby assignment is merely the naming of objects for
convenient reference (like pointers). see "Assignment" @
http://www.rubycentral.com/book/tut_expressions.html correct me if
i'm wrong, but isn't this essentially what functional programming
languages call "macros"?

i suppose this has been clarified?

Ruby variables are indeed different from standard "procedural" ones,
in that assignment actually just changes the binding for that scope,
not the value of a memory location. However, they have very little to
do with macros, which allow language syntax extensions and source code
transformation.

The closest feature in Ruby is probably 'eval', which is in theory
just as "powerful" as a macro system, but far less convenient and
safe.

Lennon
 
G

gabriele renzi

il Wed, 14 Jul 2004 12:16:39 +0900, Nicholas Van Weerdenburg
In University, I worked with a language called Turing that had both
procedures and functions. Is that a common idiom?

not the most common, but I can think of some languages like this ,
i.e. PASCAL.
In Ruby, would it be possible to extend "def" and maybe introduce a
feature called "func" that adds some extra rules to what can be coded?

why? :)
 
M

Martin DeMello

Sean O'Dell said:
Well, I was talking about variables, but I realized after looking at that
primer that I think most people were talking about "macros" or, at least,
that's what I remember calling them. It's been a long time, and LISP was my
only exposure to FP, really. I think I was mis-understanding some of the
terms people were using.

Take a look at Haskell - it's well worth the time and effort.

martin
 
M

Martin DeMello

Nicholas Van Weerdenburg said:
In University, I worked with a language called Turing that had both
procedures and functions. Is that a common idiom?

BBC Basic (and, I believe, several other BASIC dialects) had this - I
think it's a distinction that has mostly died out in modern languages.

martin
 
R

Rainer Joswig

Sean O'Dell said:
I just found a great primer on FP, and I think I have either forgotten a lot
of it from my LISP days, or LISP never had these FP features I'm reading
about. This is really a very authoritative, clear and concise explanation:

http://www.cs.nyu.edu/goldberg/pubs/gold96.pdf

Sean O'Dell

how should the PROD function mentioned in that authoritative ;-) explanation
work? Looks not very convincing to me. M needs to be incremented
in the recursive call - otherwise it would be running for a very
LOOOOONG time. Obviously that example code has never been
checked.
 
L

Lennon Day-Reynolds

how should the PROD function mentioned in that authoritative ;-) explanation
work? Looks not very convincing to me. M needs to be incremented
in the recursive call - otherwise it would be running for a very
LOOOOONG time. Obviously that example code has never been
checked.
Tail-call elimination -- the recursive function will be optimized into
a loop by the compiler.

Lennon
 
N

Nicholas Van Weerdenburg

gabriele said:
With all the discussion of what makes a functional programming language,
I was wondering if you could extend Ruby syntax to enable a purely
functional mode. Not that I expect that it would practical, but it goes
to the problem of domain specific languages in general- e.g. if you
wanted to do lambda calculus in the abstract in Ruby. The other reason
I asked was because I was wondering if Ruby could be extended this way
in order to improve my understanding of Ruby.

Thanks,
Nick
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top