Subroutine, lambda abstraction, tacit form 
Author Message
 Subroutine, lambda abstraction, tacit form

David Gurr responds:

Quote:
>Anyone want to comment on why first class functions might not be safe?

By "safe" I merely meant lexically scoped.

Quote:
>Tail recursion is exactly thoes recursions that are
>exactly equvelent to simple iterations.  Continuations are functions
>that represent "what the rest of the program computes" and are
>functional counterparts to gotos and escapes.

They were invented to speed up procedure calls and to make compilation easier.
On the other hand they can be harder to read/understand than traditional
control.  Whether they are "necessary" I really don't know.

Quote:
>> One possibility is to return
>> the funarg label; it acts like a number (as in current APL) inside its
>> definition environment but becomes a closure when it is passed out;
>I think that it should become a continuation rather than a closure.

Why?  That would be an escape (which is fine) or a _goto_ into a subroutine
(which must be passed another continuation for return) or worse the middle
of a function.  A closure is just a safe subroutine, pretty straight forward.

Quote:
>> a "gosub" (args)->f will invoke it
>The usual understanding of -> is goto, not gosub.  goto invokes continuations
>rather than closures.  To be a conforming extension, we must continue to allow
>-> to invoke continuations, but if -> can invoke both, the compiler cannot
>assume that X in the context "->X" is invoking a continuation and thus would
>be prevented from making some optimizations.

Gosub is _dyadic_ -> therefore no problem at all.

Quote:
>> As I said before, function assignment can become very  unstructured.
>ANY assignment can become very  unstructured.

Not nearly as bad as function assignment.

Quote:
>> We need a (nice) notation for
>> manipulating and returning (upward) funargs.
>lambda notation extended by array matching.   One way to do this is to
>make lambda an operator over expressions (expressions are NOT first class),
>"(A lambda B)(A + B)" whould be equv. to "+"; (lambda (A B C))(A + B + C)
>would create a function that takes enclose(iota(3)) to 3.

The "expression" had better be enclosed in {} or equivalent; lambda is really
a _control structure_--the expression is not evaluated.  The notation should
make it immediately obvious that we have a lambda expression; yet it can't be
totally unAPLish.  Which is why I suggested the labelled subroutine which also
happens to look sort of like a "direct definition".  By being a "label", a new
data type (lambda) does not have to be thrown at the implementor or user,
but rather sits in the background until invoked with a gosub (i.e. apply).
Rest of the time labels look like line numbers (like now, for better or worse).
They can be returned (by an operator or whatever) using an explicit (monadic)
"<- label", or passed as arguments, or allowed to trickle through scoping.
The question is whether to allow subroutines to be assigned to variables etc.  
I don't know the answer (yet).

K's notaton is {[arg;arg;...;arg] expr} I believe.  The way I see it, local
variables should be inside {} because nobody else should know they exist.
On the other hand parameters should be outside the {} because the world must
know how to call a lambda.  The mathematical notation is lambda X.Y; perhaps
we should write {arg;arg;...}.{local;...; expr}.  (Stuff in () are evaluated,
stuff in {} are not.)  Or, do what AWK does (yuck), mix the args and locals
and fill them in one by one (a curry operator is then needed to postpone
evaluation until all the args come in).  As I said I don't know if these are
APLish enough, or even if lambda is a good idea.  Tacit/phrasal form is more
APLish, and it is not a "control structure" because it _evaluates_ to a
(lexically scoped) function.  It makes more sense to assign one, as in Dyalog
or in J.  

What's the difference between tacit form and lambda?  Well, a name in a tacit
form is immediately evaluated, to an array or function or operator.  A name
in a lambda is _eventually_ evaluated, in the same lexical context, but may
produce (multiple) different results.  I think this is a real distinction.
Put it another way, lambda is an "abstraction" whereas tacit form is an (APL)
object.  The big problem I have with J's tacit form is ambivalence (as many
people have written).  This should be cured if APL is to have tacit form.

Finally, the "tokens" can certainly be keywords, although some will complain.

ungramatical :keyword, which to me makes absolutely no sense.




Tue, 04 Mar 1997 06:02:45 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Re-writing abstractions, or Lambda: the ultimate pattern macro

2. Lambda abstractions in C++ vs. Scheme

3. Re-writing abstractions, or Lambda: the ultimate pattern macro

4. Lambda abstractions in C++ vs. Scheme

5. Lambda abstractions in C++ vs. Scheme

6. lambda abstraction in Tcl?

7. problems converting to tacit form

8. tacit form involving Power

9. recursive lambda forms

10. settable-lambda implementation starter kit (settable forms)

11. Lambda Forms Question

12. Limitation of lambda list in DEFUN form?

 

 
Powered by phpBB® Forum Software