Ruby and Python

[Marcin 'Qrczak' Kowalczyk]

Mon, 20 Nov 2000 21:31:46 +0100, Philip 'Yes, that's my address' Newton <nospam.newton at gmx.li> pisze:

> > So by this definition C has first class functions. Does it?
> 
> No. You can only do all the above with pointers to functions,
> not with functions themselves.

It is irrelevant whether you call them functions or function pointers.
Terminology and minor syntactic nuances don't matter.

What matters is that in C you cannot define a function inside a local
environment. Thus a function is only a piece of code, without any data
attached, because anything it can refer to must be global.

Python is a lot better in this respect. But it's not as good as many
other languages where you don't need to enumerate pieces of the local
environment mentioned in the inner function.

C cannot be really fixed. If C allowed local functions (as gcc does),
the major problem is still the lifetime of local objects of the
outer function mentioned in the inner one. If they must disappear
where the outer function terminates, the solution is half-baked:
you can use such function as long as the outer function is running,
but it cannot exist on its own after its birth place is over. If
these objects don't disappear, then how long do they live? C lacks
garbage collection and this is the problem. These objects should be
attached to the function object, but various function objects of the
same type can have different patterns of objects attached, so they
cannot be freed explicitly from outside.

I believe that Python can be fixed. It's not obvious how to define it
however, because variable declarations are implicit. Variables begin
their lives with the first assignment, which is a dynamic concept
and does not define a scope.

Ruby solves it by letting the syntactic assignment define a scope.
Smalltalk has explicit variable declarations, as languages with static
type systems do. Perl has explicit variable declarations using the
"my" keyword, with other variables being global by default. Lisp does
it like Perl.

No solution is perfect if there are no explicit variable declarations:
there are perverse programs when the variable in question may belong
to inner or outer scope, it does influence the result, and it is
not deducible by the compiler. But in reality variables are used at
least once in the outermost scope they belong to, and if they don't,
it's easy to add an artificial usage. So I propose a variant of the
Ruby solution. E.g. that any use of a local variable defines a scope
(and of course formal parameters and function definitions too). All
uses of the name as a local variable in inner scopes refer to the
same variable. I see no reason to disallow assignments in inner scopes.

Deeply nested functions won't be used much in practice, but at least
there would be no need of this annoying passing by default arguments
and local recursive functions will work normally.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK