🚀 go-pugleaf

In article <1834@etive.ed.ac.uk< nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
<In article <5973@pdn.paradyne.com> alan@rnms1.paradyne.com (Alan Lovejoy) writes:
<><ML is
<><certainly polymorphic, although you can't "inspect" all values (they may
<><be abstract, or function objects). 
<>
<>By "inspect" I simply mean "read."  If I can code "IF a = b," then I can
<>"inspect" or "read" "a" and "b".
<
<I stand by my words. You can't evaluate "a = b" in ML if a and b are functions,
<since equality doesn't make sense. If they're abstract types, then any
<default interpretation of "=" may be incorrect (e.g. sets represented as
<lists).

I'm sorry, I thought the meaning of my example was clear.  Obviously, I was
wrong.     

Let the example be "a OP b," or if you don't like to distinguish between
operators and functions, "f(a, b)."  My point has nothing whatever to do
with the "=" operator.

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.

<><"modification" is only allowed on
<><objects created specially for the purpose: how do you modify a function?
<>
<>By "modification" I simply mean "change."  If I can code "INC(i)", so that
<>the value of "i" is incremented to the next "higher" member of the ordered set
<>of values of which "i" is a member,  then I have the ability to "modify" "i".
<
<I stand by my words here as well. If I bind X to 3 (in a functional language),
<I don't want X to be alterable.

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)."  Bindings, of course, represent part of the
environment of execution.  They are state.  Rebinding implies a modification
of this state, a change in the environment.  The fact that only bindings are 
modifiable values in functional languages provides such languages with some 
impressive benefits.  It also means that either bindings, or else all other 
values, are not first class citizens in such languages.  Whether the benefits 
are worth the cost is an interesting topic for debate.  I am as yet undecided.

<>Also, I really want to require that modification be possible in principle,
<>if the programmer wants to define any operations that modify values of some
<>type.
<
<But the point of a high-level language is that it provides a firm semantic
<framework for the objects that you're dealing with and the operations that
<they support...? I don't think that making "any modification possible in
<principle" is desirable. Or feasible, for that matter.

I am reminded of Chomsky's distinction between competence and performance.  
Writing the software for the SDI system may not be desirable--or feasible, for 
that matter.  But it should be possible in principle, given the right tools.

The purpose of a high level language is to provide abstraction mechanisms.
It's the job of the programmer to use those abstraction mechanisms to define
the semantics of the abstractions he creates with the abstraction mechanims
provided by the language.  The firmness of the semantic framework is his
responsibility, provided the language's abstraction mechanisms give him
sufficient control over the nature of his abstractions that he can provide
a firm semantic framework for them.

There are two schools of thought in langauge design:  the Bondage&Discipline
School and the Freedom&Liberty School.  The Disciplinarians worry about
preventing misuse of value types and functions.  The Freedom Fighters
worry about arbitrary restrictions on the power of a language.  Happily,
there is a middle ground:  let the programmer define his own restrictions,
to be enforced by the language.  After all, the programmer is the expert
on the scene.  He's writing the program.  He knows the application domain.
Such decisions are rightfully his.  If he does not have the intelligence
to discern what safeguards he should build into his abstractions, he probably
won't be smart enough to appreciate a Bondage&Discipline language.  He'll use
C, or something similar.

<>As for "modifying a function," how about recompiling it?  Or changing the
<>input parameter "type" and/or "range" checking?
<
<I distinguish "modification" and "re-binding". If I rebind a function "F",
<that declares a new "F", which I can then go on and use. Existing code
<doesn't see the change (unless it is also recompiled).

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.

<><"Storage in memory" - doesn't make sense for higher-order garbage collected
<><languages. 
<>Would you accept Smalltalk as a higher-order garbage-collected language?
<>What did you think I meant?
<
<ML has objects which accept assignment, but no notion of "memory" or "address"
<in the classical sense. The behaviour of ML reference objects is defined
<semantically.

Again, rephrase the definition using the terms for the things that functional
languages do instead of "storage in memory."  At a more primitive level,
where a functional language program is actually implemented in machine code,
"storage in memory" IS occuring.

Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne.  They do not speak for me. 
_________________________Design Flaws Travel In Herds_________________________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.