1. Speed up search and replacements in the APL+Win Editor (when replacing All occurrences of some string)This is very slow when there are many occurrences to replace, and moreover it sometimes crashes APL (when there are really very many occurrences to replace and the function has many lines).

It does not seem necessary to me to scroll the display or show the replacements being done while the replacement process is running to replace all occurrences. This is of no use and certainly dramatically slows down the whole process. Maybe just display the new text with all the replacements done once they are all done.

2. Avoid the SI DAMAGE error when fixing a function after having changed it in the editor while it is interrupted in a :for loop

3. Add a HideRows method to the Grid object (which would accept an argument being the row numbers of rows to be hidden)4. Add a HideCols method to the Grid object (which would accept an argument being the column numbers of columns to be hidden)(Note, this would not be the same as setting the row heights or column widths to 0 for the rows or columns to be hidden.When you set the column widths to 0, it does hide the corresponding columns, but when you navigate inside the grid using the cursor keys you see that the columns are there.)

5. Fix the scrolling problem in the Editor(after some operations in the Editor, maybe deleting lines, using PgUp and PgDn multiple times, it happens that pressing the Up or Down key jumps to a completely different row than the one it should to)

6. Allow pasting APL characters to the Find and the Replace dialog (at least if the Enable Unicode Clipboard menu option is checked: currently it is possible to type APL characters in those dialogs but not to paste APL characters; it is possible to paste APL characters in UEdit so it should be possible to paste APL characters in the Find and the Replace dialogs)

7. Allow Unicode characters to be used in Frame captions (maybe a UFrame control?)

8. Allow to use Unicode characters in the APL Grid (and in other controls as well)?

9. Implement the Compose (∘) operator (i.e. speeding up sequences of ¨ operations like +/∘5↑∘⍴∘⊂¨ being same as +/¨5↑¨⍴¨⊂¨ but faster)

Eric.Lescasse wrote:[list]2. Avoid the SI DAMAGE error when fixing a function after having changed it in the editor while it is interrupted in a :for loop

I spoke to the developers about this many years ago and was informed that you can't really fix that. The :FOR structure creates a lot of loop-control data, including internal pointers, and recreating the function must necessarily destroy that information. I agree that the result would be wonderful, but it would be very difficult (and impossible in many circumstances) to come up with a way to adjust the control structures when the function is redefined.

When faced with this problem myself, which usually happens on the first time through the loop, I'll reset the current-line pointer to before the loop and execute one line. Then I can edit the function and resume before the loop begins. This usually gets me around the problem, if awkwardly.

This has been implemented forever (since "each"). The problem is that it doesn't do what you would normally expect. In order for "/" (for instance) to work with either a function or data as a "left argument", it must be defined as an operator, not a function. Each (also an operator) must have a function to work on, not another operator, so the "/" must be combined with something else to produce a derived function before applying each to it. This works fine with +/¨ because the +/ is what is being eached. If you pass "/" a 1 0 1 boolean (for instance), then the data combines with the compression first, giving 1 0 1/, after which that whole thing is eached, producing (1 0 1/)¨. This is why you can't pass "/" a nested boolean argument and expect each to take the data apart. It can't, because the whole of the nested data is already "composited" with the compression before each gets to see it. A 1 0 1/¨ will work just fine on a nested vector of three-item vectors, removing the middle item from each one.

Does that make sense why you seem to have trouble using this operation?

What you need to do to get what you want is to replace the "/" with a function instead of an operator. You can write one yourself, but fortunately the APL2000 team has provided us one some years ago, called ⎕REPL. This is a true function and can be used with each like you want. It will also accept axis specifiers such as ⎕REPL[1] to work on matrices. See if that will solve your problems for you!

I'd like to add my own request to this list. I asked for it years ago but nobody seemed to think it was important enough to pursue.

11. I'd like to be able to write user-defined operators (things that can take functions as arguments as well as data). This gives me lots more options for the way I write both tools and complex application code.

12. I would like to have the ability to define subroutines statically within a function. Using ⎕FX within a small function that may execute millions of times is simply too slow and awkward, and yet I often run across a need for such tools that are much better when self-contained (no external subroutines). Dyalog can do this with d-fns, but of course we don't have those here and I'm not asking for that specifically -- just some way to have a static local definition.

... This is why you can't pass "/" a nested boolean argument and expect each to take the data apart. It can't, because the whole of the nested data is already "composited" with the compression before each gets to see it. A 1 0 1/¨ will work just fine on a nested vector of three-item vectors, removing the middle item from each one...

Sorry to not have been clear enough. I was indeed talking about (⊂booleanVector)/¨Shouldn't it be possible to make this working: it works in Dyalog APL:

the latter expression returning a 3 element nested vector where the 2nd is empty.It would be nice to have this working in APL+Win, thus not forcing us to use ⎕repl or ⎕expand.Same thing for (⊂bv)⌿¨ (⊂bv)\¨ (⊂bv)⍀¨That was my enhancement request.

Last edited by Eric.Lescasse on February 14th, 2017, 12:18 pm, edited 1 time in total.

Eric.Lescasse wrote:Sorry to not have been clear enough. I was indeed talking about (⊂booleanVector)/¨

If you don't enclose the left argument here then you get the result that I think you're asking for.

The extra behavior that you're talking about from Dyalog I think would have to come from a language parser change. The original versions of nested APL (as I understand them) defined slash strictly as an operator, apparently to keep intact the original intent regarding an invariant syntax. The only thing I can think of offhand that Dyalog could have done to support such a split-personality behavior is to parse slash as either an operator or a function (two completely different uses of the same symbol) depending upon its context. That's not really allowed by the standard APL syntax definitions, and I would think it would take a significant change to the code-parsing system in APL+Win to allow it to work so differently.

I believe that when these system functions were first introduced there were issues with them relating to the setting of )evlevel.My point was that I would expect / to work when the length of the left- and right- hand arguments were diferent but had 1:1 conformance.

This shouldn't work the way you've described it because your left argument is nested and compression is not defined for a nested left argument. I'd think you'd want to at least {each} that there (which leads us back to the main topic).