Arc Forum | Alternate form of fn

Arc Forum

Alternate form of fn

1 point by tokipin 6227 days ago | 34 comments

Currently fn is:

  (fn (x) (+ x 1))

I propose an alternate form:

  (fn add1 (x) (+ x 1))

Which would be equivalent to:

  (def add1 (x) (+ x 1))

  (= add1 (fn (x) (+ x 1)))

This would simplify things and let us get rid of def.

Also, I think it would be easier to teach lambdas by having the two major function-creating tasks taken care of by one function, since the anonymous case is a simple removal of the variable-to-be-assigned. Though probably not the highest priority, things that are simpler to beginners are likely to be simpler to the rest of us, too.

There would be a conflict with functions of the form:

  (fn args ...)

Because we couldn't tell if it is a vararg lambda or a function named 'args'. I think an acceptable solution would be to make the vararg form be:

  (fn ('() . args) ...)

Or something like that. In other words, we would require that the parameters always be in parens. It might not be the prettiest, but vararg isn't very common, and I think the simplification that the alternate form for fn would bring would be worth it.

3 points by eds 6227 days ago | link

Several things I'd like to point out.

Firstly, if you want to give a name to a 'fn form, use 'rfn.

Secondly, 'def is not redundant with 'fn because 'def is not an axiom. 'def (defined in arc.arc) is just a convenience macro on top of 'fn (in ac.scm). So if you made 'fn take on the behavior of 'def, you would actually be pulling functionality into the axioms rather than leaving it in the core language.

Thirdly, exactly what would your named form of 'fn do? Would it assign the name in (fn name (...) ....) to the function? That behavior seems very out of line with what 'fn does; in fact, that is specifically what 'def is for. If it does not assign the name, than that is a lot of boilerplate you would be requiring users to type.

Fourthly, the (fn args ...) case is actually fairly common, especially in the core language. If your version of 'fn can't support this case, then it almost certainly can't be used without modifying the core language, not to mention all the other code that has been written so far.

-----

2 points by tokipin 6226 days ago | link

(fn name (...) ...) would be equivalent to the current (def name (...) ...), while (fn (...) ...) would be equivalent to the current (fn (...) ...). the intention isn't to replace the current form of fn, but to give it an optional parameter at the front so that both forms work

btw you can already use def in place of fn:

  arc>((def fun (x) (+ x 1)) 3)
  4
  arc>fun
  #<procedure: fun>

this version would be able to handle varargs, just not with the same notation as it currently uses. i mentioned (fn name ('() . args) ...) as a possibility, but i think something better would be

  (fn name ((v args)) ...)

sort of like the o notation for optional parameters. (fn name (() . args) ...) isn't that bad either. varargs of the form:

  (fn name (a1 . rest) ...)

would be unchanged. the only requirement necessary is that args always be in parens, and the only place where that currently conflicts is with full varargs

-----

2 points by eds 6226 days ago | link

Even if your intention is to just add an optional parameter to 'fn, you still have to implement it in ac.scm. You can't even redefine it in Arc because it is dealt with specially in 'ac.

I still think there is a logical distinction between defining a function literal, and assigning that function to a variable. One should be implemented as an axiom, and the other really should be implemented in the core language. Pulling the latter into the former just doesn't make sense.

As for varargs notations, the only one I like is (fn ((v args)) ...). Because (fn args ...) is basically a case of destructuring, the (fn (() . args) just doesn't make sense. In fact that notation actually does work in the current Arc, it just throws away the first argument. (Which makes sense if you think through what that code is actually saying.)

But even considering the possible alternatives, I still think the current syntax is the most elegant.

-----

1 point by tokipin 6226 days ago | link

how about if i said: "make the name parameter of def be optional and rename it fn, and rename the current fn to axiomfn" ? we wouldn't be touching the axioms in that case except with a rename

i'm just saying there should be a functionality like that. how the internals are structured to meet that end isn't as significant so long as we're not butchering things. and i'm a big fan of the concise axiomatic approach. it's the reason i use Lua instead of Ruby. and that's why i think merging def and fn would be better -- because to the programmer it would be simpler, even though underneath it may need a bit more sophistication to handle the special case of full varargs

-----

3 points by eds 6226 days ago | link

There's still this logical distinction between creating an anonymous function and assigning it to a variable, and I don't think merging 'def and 'fn captures this distinction.

Note the differences in the use of 'def and 'fn. 'fn is used most frequently as a local function, while 'def is a global definition. If you provide a named form of 'fn that assigns a global name, then it will be really tempting to misuse that form in a local context where you really shouldn't be messing with global bindings.

And why should 'def get a pulled into 'fn but not 'afn or 'rfn? In some ways, those make much more sense than the integrated 'def form, but note that all of those were made explicitly different in the core language. We want to make it explicit how we are handling the naming (and scoping) of our functions. Thus the four or more different ways to define a function.

-----

1 point by tokipin 6225 days ago | link

> > There's still this logical distinction between creating an anonymous function and assigning it to a variable, and I don't think merging 'def and 'fn captures this distinction.

(fn name (arg) ...) and (fn (arg) ...) seem pretty distinct to me

> >Note the differences in the use of 'def and 'fn. 'fn is used most frequently as a local function, while 'def is a global definition. If you provide a named form of 'fn that assigns a global name, then it will be really tempting to misuse that form in a local context where you really shouldn't be messing with global bindings.

if fn is being used in a local context they probably won't need to give it a name

for afn and rfn i was actually thinking they could be merged as afn:

  (mac afm (first . rest)
       (if (alist first)
           `(afn ,first ,@rest)
           `(rfn ,first ,@rest)))

then there would only be two function-creating thingies: fn and afn. i stated elsewhere that i see the necessity for 'and' and 'aand'. fn and afn are substantially different in that the variable environments of their evaluated bodies are different, as well as producing different classes of functions

truthfully it would be nice if they could all be merged into one, and they could be, except for example 'self' would always be pre-set in lambdas which would be (conceptually) annoying. that would be tolerable though

Behold, the God Fn:

  (mac fn (first . rest)
       (if (alist first)
           `(afn ,first ,@rest)
           `(rfn ,first ,@rest)))

-----

2 points by eds 6225 days ago | link

> > There's still this logical distinction between creating an anonymous function and assigning it to a variable, and I don't think merging 'def and 'fn captures this distinction.

> (fn name (arg) ...) and (fn (arg) ...) seem pretty distinct to me

Think about the difference between (car x) and (scar x). Those are two distinct cases (assignment and retrieval), we wouldn't want to create a single 'car function that would do assignment if given an optional parameter.

  (_car x)   =>  (car x)
  (_car x y) =>  (scar x y)

Because these are two entirely different concepts. Similarly the assignment of a function to a variable is distinct from creating that function. In my opinion, merely creating an optional parameter for it in 'fn doesn't capture that distinction.

> if fn is being used in a local context they probably won't need to give it a name

Then why do 'afn and 'rfn exist?

> fn and afn are substantially different in that the variable environments of their evaluated bodies are different

And thus 'fn and 'def are different in that 'fn creates no binding and 'def creates a global binding.

-----

2 points by tokipin 6224 days ago | link

fn and def both create functions. in one case we donate money. in the other we donate money and get a star with our name on it. in both cases we've donated money. car vs scar would be like donating money vs robbing a bank

>> if fn is being used in a local context they probably won't need to give it a name

> Then why do 'afn and 'rfn exist?

to create self-referencing functions

> And thus 'fn and 'def are different in that 'fn creates no binding and 'def creates a global binding.

yes, and afn can create a different class of functions from fn. almkglor had a good point about requiring gymnastics in some cases with a God Fn. those sorts of issues wouldn't happen with (fn,def) -> fn and (afn,rfn) -> afn, except for the full vararg thing

if we use software structure/logic as the only metric, sure, they're all very different, but then we'll lose sight of the way the end user sees all these things

-----

2 points by eds 6224 days ago | link

> fn and def both create functions. in one case we donate money. in the other we donate money and get a star with our name on it.

No, the star gets permanently placed in the floor of the quad outside the central office. As opposed to 'afn and 'rfn where we get to keep the star.

Admittedly my 'car and 'scar example wasn't accurate. Let me try again. Say we have a version of 'table called 'ntable that is just like table except it assigns the new table to a global variable. Now suppose we redefine 'table to take an optional parameter, in which case it acts like 'ntable. But all this does is confuse the purpose of 'table, which is to create a table, and 'ntable which creates a table in the global namespace. The overloading here doesn't help shorten or clarify code. So we remove one function from the global namespace. So what?

Unlike in real life, the presence or absence of the star really does matter here, enough that the two shouldn't be condensed into a single operation.

>>> if fn is being used in a local context they probably won't need to give it a name

>> Then why do 'afn and 'rfn exist?

> to create self-referencing functions

Exactly! So you can use the function in more places than just the return value. 'def is similar in that the name allows it to be referenced elsewhere (or inside the definition), and this is totally different from the one-shot usage that 'fn gets most of the time.

> if we use software structure/logic as the only metric, sure, they're all very different, but then we'll lose sight of the way the end user sees all these things

I think we are making very different assumptions about the way the user thinks about 'fn and 'def. When I see 'fn, I think local/anonymous function. When I see 'def on the other hand, I think global/named function (and yes, where the name goes is an important issue, even to an end user). I don't think it is a simplification of this model to merge the two operations.

-----

1 point by tokipin 6224 days ago | link

when i see fn, i see "fundamental function-creating function." i see def as "(= name (fundamental function-creating function))." i said elsewhere that i can see how someone familiar with lisp would see fn and def as essentially lambda and set, and

  (lambda name (arg) ...)

would definitely be odd. but the name isn't "lambda," it's "fn." and i conceive that as "function," which has no semantic bias to locality or scope

-----

1 point by almkglor 6224 days ago | link

ooh, ECMAscript:

  function foo(x){
    return function(){return x;}
  }

-----

1 point by almkglor 6225 days ago | link

Please realize that this makes the following otherwise OK code much more difficult to express using your "God Fn":

  ((afn (m-tree)
    (when (in-sight m-tree)
      (map
        (fn (node)
          (render node)
          (self node))
        m-tree!children)))
    m-tree)

So no. I don't think this puritan attempt at merging ideas is a good one.

"All processes are impermanent ... All processes are afflicted ... All phenomena are not ‘Self’; when this is seen with knowledge, one is freed from the illusion of affliction. This is the pathway to purity."

-----

1 point by tokipin 6225 days ago | link

uh... it would just be a replacement of 'afn' with 'fn', unless i'm missing something [edit]ah, i see the extra fn you lodged in there

what about:

  ((afn (m-tree)
    (when (in-sight m-tree)
      (map
        (afn (node)
          (self node)
          (self node))
        m-tree!children)))
    m-tree)

i wonder how we would refer to the different selves within the inner function without explicitly setting something in the outer one or using rfn. a let around the inner function isn't that bad. in any case, good catch

-----

3 points by sacado 6227 days ago | link

I don't like it. If you want to get rid of def, use =. If you want to teach anonymous functions, just say : "you see, (def foo (x)) is the same as assigning the variable foo a function that takes one parameter named x. This can be written : (= foo (fn (x))".

And it makes fn have a strange behavior, plus the fact that we lose the simple syntax for varargs functions. And how do you read (fn nil nil) ? Is it a function I try to call nil with no argument and no body ? Is it a no argument anonymous function that returns nil ?

-----

2 points by tokipin 6227 days ago | link

with the requirement that the parameters always be in parens, that would be an error

[edit]the inspiration for giving fn an optional parameter is that def is redundant. i don't think it would be strange at all. except for full-vararg cases, a straightforward 'def -> fn' search & replace would be sufficient

-----

1 point by sacado 6227 days ago | link

"with the requirement that the parameters always be in parens, that would be an error" : not really, because without parameters, you would have '() which is automatically translated to nil. You could do (fn (nil) nil), however, but I don't like the look of it. Not enough consistent, I guess (and a list containing the empty list to denote the empty list does not look right to me).

-----

1 point by tokipin 6226 days ago | link

well, as a special form i don't think it would have trouble differentiating between () and nil. () seems to be different from '() even though (is () '()) is t

-----

1 point by eds 6226 days ago | link

'() is (quote ()) while () is (). You won't notice the difference if you pass both to a normal function but you might if you passed both to a macro or special form.

-----

2 points by tokipin 6224 days ago | link

it occurred to me that (fn (. args) ...) would be decent and fairly consistent, though i don't know how currently possible it is

-----

1 point by eds 6224 days ago | link

While superficially (fn (. args) ...) may look decent, it is entirely inconsistent with the Arc reader. Function definitions have to be entirely representable in lists, and the example you list above is not a valid list. Not only would this break the current Arc, but you would have to reimplement the entire reader that Arc currently borrows from Scheme. Not to mention that you would have to define what it even means to have a cons with no 'car field.

-----

1 point by Jesin 6226 days ago | link

Simplification!? You seem confused. We have two concepts here. Using one symbol for two concepts does not combine two concepts into one. All it does is add confusion. Overloading is fine for some things (eg. + adds numbers and joins lists), but be careful with it. Remember that post (which I'm too lazy to track down right now) titled "You want brevity? You can't handle brevity!" that gave an example of K code? That language wanted to fit APL into ASCII, and did so by overloading the punctuation characters over 4 times each on average. That results in code like this:

  (!R)@&{&/x!/:2_!x}'!R

Again, overloading should be used sparingly, and only when the concepts are related in a certain way that I won't bother trying to articulate right now.

I think that in this case any benefits this might have are outweighed by the confusion it would cause and the kludge required for certain things like varargs.

  (fn (() . args) body)

Doesn't that hurt your eyes? Not to mention what it is saying: "Function that accepts the empty list and any number of other arguments". That doesn't make sense to me.

-----

2 points by tokipin 6225 days ago | link

> > Simplification!? You seem confused. We have two concepts here. Using one symbol for two concepts does not combine two concepts into one.

i don't think these are distinct concepts. to me they are the exact same thing except in one case we're attaching a name to what we're making, and in the other we aren't. i can see how people familiar with lisp might see essentially 'lambda' and 'set' in the forms, but on the surface 'fn' and 'def' are very similar

i see the need for say, 'and' and the anaphoric 'aand', but to me def is so redundant with fn i actually do use that (= name (fn (x) ...)) form someone mentioned here

> > Again, overloading should be used sparingly, and only when the concepts are related in a certain way that I won't bother trying to articulate right now.

i agree, but again i don't think this is an inappropriate case. what i would like to see in Arc is something that Lua does in various places. the best example is its tables, which are simultaneously arrays, hash tables, and with its metatable system, any other structure you can think of from multiple-inheritance objects to arbitrarily-linked lists. and they act respectively depending on how they're used. eg if you use a table as an array it will iterate fast. the result is that the programmer is relieved of the details of choosing and using structures, and can instead focus on actually using them

is Lua's implementation of tables more sophisticated than arrays, hash tables, etc would have been individually? definitely. but it relieves the programmer of a lot of thought that is able to focus on something else. tables are definitely simpler than if their functionality was spread out, yet no functionality is lost compared to such a model. in fact, functionality is gained through the flexibility

by upping the sophistication underneath, a language can become simpler. if you only rely on the sort of simplicity brought about by a pure axiomatic approach, you get a sort of "assembly" simplicity. is MOV DX,8 simple? yes, but for naught

(not to blitzkrieg with text, but i thought i would explain the philosophy in one place)

> > for certain things like varargs

full varargs would be the only alteration

> > Doesn't that hurt your eyes?

yes, which is why i proposed another syntax. someone may be able to come up with something better. i use full varargs commonly so it wouldn't be easy for me to let go of the current syntax either

-----

2 points by eds 6225 days ago | link

It is true though that whenever you overload an operator you depend on the programmer understanding more about a single operation. Thus by definition overloading increases the complexity of a language.

Please see (and refute if you like) my comment at http://arclanguage.org/item?id=5213 .

There is some significant complexity in setting a variable. Note the current existence of four (or more) different forms of 'fn: 'fn (anonymous), 'afn (capturing 'self as a local name), 'rfn (using a user defined local name), and 'def (using a user defined global name). All these forms exist for the purpose of creating functions, but they each has a different way of setting varaibles.

How do you capture that complexity if you want to start combining them into a single operation? Do you just ignore everything except 'fn and 'def and say the user can type the extra character for 'afn and 'rfn? That seems rather inconsistent.

-----

1 point by tokipin 6225 days ago | link

> > It is true though that whenever you overload an operator you depend on the programmer understanding more about a single operation. Thus by definition overloading increases the complexity of a language.

that's if we're looking at it from the perspective of the operator. but if we look at it from the perspective of an expression, i think it is simpler. to illustrate: one of the nice examples on the front page of ruby-lang.org is the following (keeping their comments):

  # Ruby knows what you
  # mean, even if you
  # want to do math on
  # an entire Array
  cities  = %w[ London
                Oslo
                Paris
                Amsterdam
                Berlin ]
  visited = %w[Berlin Oslo]
 
  puts "I still need " +
       "to visit the " +
       "following cities:",
       cities - visited

if we look at it from the perspective of the operators, we see we've overloaded + and - for non-numeric types. however, if we look at it from the perspective of the programmer as they are writing those lines, we see that the programmer just wants to say "remove the cities i've visited from the cities i have to visit," and "cities - visited" is almost a direct translation of that. it makes sense. the fact that that operator happens to be overloaded from another domain is irrelevant. the context secures the role of the operator

-----

1 point by Jesin 6219 days ago | link

There is no syntax for varargs. Destructuring argument lists are very simple and easy to understand once you understand the structure of Lisp code. What you're proposing is taking away the ability to manipulate s-expressions as they are just to free up another name that would rarely be used anyway.

-----

1 point by tokipin 6218 days ago | link

yes, i thought of it that way, but what about the dot operator? (def fun (a . b) ...) isn't called like this: (fun (1 . 2 3))

and the optional args parameter. (def fun (a (o b)) ...) isn't called like this: (fun (1 (o 2)))

and i don't see how changing the single case of varargs takes away the ability to manipulate expressions as they are. it alters it for that one case

-----

1 point by eds 6226 days ago | link

"You want brevity? You can't handle the brevity :)"

http://arclanguage.org/item?id=3355

And as I said before (http://arclanguage.org/item?id=5189),

  (fn (() . args) body)

actually works under the current implementation of Arc, it just throws away the first argument.

-----

1 point by tokipin 6226 days ago | link

here is a basic macro with this functionality to show more precisely what i mean

  (mac fm (first . rest)
       (if (alist first)
           `(fn ,first ,@rest)
           `(def ,first ,@rest)))

-----

3 points by Jesin 6219 days ago | link

Why are you complaining about def being redundant, instead of railing against let? Nobody will argue that let isn't redundant (although many will say that it's useful).

  arc> (macex1 '(let a b c d))
  (with (a b) c d)

-----

1 point by tokipin 6218 days ago | link

i see 'let' as the core operator, and 'with' as the one that is redundant. you're right though. i wonder if they couldn't be combined into just let. i don't see the difficulty in something like

  (mac Let (first . rest)
       (if (alist first)
           `(with ,first ,@rest)
           `(let ,first ,@rest)))

(we need first-class macros so i can manufacture these things)

would there be any issues with something like that?

then you might ask, why don't we just merge everything so we only have two or three functions to work with?

  (def mathop args
       (map [apply _ args] '(+ - * /)))

  arc> ((mathop 3 2) 0)  ;addition
  5

but the intention isn't to merge everything for the sake of it, it's to simplify the surface "interface" for the programmer. fn/def and let/with are both things the programmer will use often

though in the case of let/with it may be more readable to keep the current setup since it saves the eyes the trouble of checking how many variables are bound, even though it's just a check for parens. i haven't programmed enough to really say

-----

4 points by absz 6218 days ago | link

Your Let fails on destructuring:

  (def mag (vec)
    (let (x y) vec
      (expt (+ (* x x) (* y y)) 1/2)))

Your Let would fail there, trying to bind x to y.

-----

1 point by tokipin 6218 days ago | link

ah, didn't know you could do that. thanks

-----

1 point by absz 6218 days ago | link

To be fair, that example would be more simply written

  (def mag ((x y))
    (expt (+ (* x x) (* y y)) 1/2))

, but destructuring in let does have real uses.

-----

1 point by eds 6218 days ago | link

I agree with you that 'let and 'with are redundant (although I still disagree about 'fn and 'def).

But I think the difference between the 'let and 'with forms would be removed better simply by removing the implicit progn. This was brought up previously in http://arclanguage.org/item?id=3234 .

This would allow (let a 1 form) like the current 'let, or (let a 1 b 2 form) like the current 'with. For multiple statements you would need (let a 1 (do forms)), but pg already said how he liked that 'do highlighted non-functional code.

-----