🚀 go-pugleaf

In article <6000@pdn.paradyne.com> alan@rnms1.paradyne.com (Alan Lovejoy) writes:
>It should be pointed out, however, that there is no inherent reason that
>function-values cannot or should not be compared for equality.  I know of
>at least one widely used language, in which functions are values and can
>be assigned to variables, which allows function values to be compared for
>equality.

It depends how you define "equality" on functions. Consider:

		let val F = lambda x. lambda y. x+y
		in
		   (F 1) = (F 2)
		end

Then, "F 1" and "F 2" are both functions. Are they equal? They've
evaluated to different dynamic objects, they have different closures,
and they will give different results. However, they both derive from
the static definition of F. The only sensible definition of equality
is equality of dynamic occurrence; but then, two functions may behave
identically (this is undecidable) but not be "equal".

>The definition I gave for polymorphism does not state that it is only to be
>applied to functional languages.  In languages which have modifiable value
>types, all types must be modifiable if all values are to be first class 
>citizens.  But in a functional language, values are not modifiable, only
>"readable" and "replaceable."  So "INC(i)" is done by rebinding "i" to
>the value of "add(i, 1)."
>Rebinding is what functional languages do instead of value modification.  So
>rephrase my definition so that "rebinding" replaces "modification" in the 
>case of functional languages.

But, consider:

	let i = 1
	in  (let i = 2 in i end, i)
	end;

there's no assignment going on here; just a (local) rebinding of the name.
If it was assignment, the value of the above expression would be (2, 2),
not (2, 1).
Binding is a static properly, and doesn't imply dynamic update-in-place
or anything like that. Functional programs have to model update by using
accumulating parameters and self-recursion.

>At a more primitive level,
>where a functional language program is actually implemented in machine code,
>"storage in memory" IS occuring.

At a very low-level, yes, but this information isn't of any use to the
programmer; after all, garbage collection, migration, etc. is going to
move things around at times which the user doesn't know about. It's best
to regard the runtime system as providing a heap of dynamic objects which
disappear when they aren't being referenced by anything; terms like "address"
and "memory" aren't of much use outside the runtime system.

>Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.

		Nick.
Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
               Fais que ton reve soit plus long que la nuit.