Re: [Bug-apl] Suggestions needed: Editing of named lambdas

[Juergen Sauermann]

Hi,

in GNU APL you can have lambdas without result (eg. {}) and they don't start with λ←.
As Kacper has pointed out you can also have user-defined functions starting with λ←.

I have no plans to prevent that, but  I have also no idea where the lambdas will bring us
in GNU APL. Right now {...} is simply a wrapper for ⎕FX. IMHO it is not a good idea to
have two kinds of functions with different rules in one language, even if some APL programmers
seem to like that.

I have added a function UserFunction::is_lambda() in SVN 156 that tells if the function
was initially defined via '{ ... }'.

No idea what happens if you edit the function later on.

/// Jürgen


On 03/06/2014 03:53 AM, Elias Mårtenson wrote:

The Emacs mode allows the user to edit an existing function by pressing C-c C-f, or typing ∇ followed by the name of the function. This opens up the function editor in a separate window.

However, when the user creates a function using the dfn notation:

avg ← {(+/⍵)÷⍴⍵}

And then tried to edit it using ∇avg, the Emacs mode will run the equivalent of ⎕CR 'avg' behind the scenes, and present the following in the function editor:

∇λ←avg ⍵   

λ←(+/⍵)÷⍴⍵

This will of course fail when the user tries to save the function.

First a question for Jürgen:

Can I rely on the fact that if the first character in a function definition is λ, does that guarantee that the function is a dfn? A consequence of this is, for example, that I am guaranteed that the function consists of only one statement.

So, I have a few options here and I would like people's input on it:

• I can simply pop up an error message if an attempt is made to edit a lambda function (then how should they be edited?)
• I open the function editor in a special "lambda mode", limiting the function to a single statement
• I replace λ, ⍺ and ⍵ with proper variables, thus converting the lambda function into a normal function when saving.
• Jürgen allows the use of λ, ⍺ and ⍵ as variables in normal functions so they behave just like any other function, except with unusual parameter names.

What solution do you think should be used? The current state is really not ideal.

Regards,

Elias