Re: [Bug-apl] [PATCH]: allow using lambdas in ]USERCMD

[Peter Teeson]

Thanks for your thoughtful response Jürgen, and also Elias and Blake.

As to elegance, I would say that yes, APL is elegant, but APL systems have never been. 

Amen….

It is helpful to recognize the computing environment at the time that APL became a commercially viable product.

I. P. Sharp and STSC both had modified APL/360 systems that were time-sharing - you paid for CPU cycles and file space.

Users would log on to the mainframe with a user id over modems that were initially 75baud. Hallelujah for the Gandalf 1200 baud.

Hurrah for the 2741 IBM golf ball for APL. Packet switched networks over phone lines also became available. We wrote our own.

We ran at first on an IBM 360 mainframe with 5MB hard drives. 

Memory was core - donut shaped rings with wires magnetizing them to form 1’s and zero’s.

If I recall correctly the size of a workspace was 50KB. Each user had a WS loaded at logon.

This could be the )CONTINUE WS. Otherwise you got a )CLEAR WS or  )LOADed a )SAVEd one.

Initially the mainframe OS was IBM DOS. It had 3 partitions: F1, F2, and BG.

The interpreter ran as the only process in F1  with the highest priority; 

The file system, BSS (Backing Store System) ran as the only process in F2 - 2nd highest priority.

Various other batch processes ran in BG (BackGround) which had the lowest priority.

Later on we moved to MFT and then to MVT. I left Sharp in 1986 so don’t what was used afterwards.

When a user logged in they were one of a number of users whose WS was in main memory.

Each user was allocated a quantum of CPU time. 

If they consumed their initial quantum they were allowed a certain smaller amount to complete.

If they still hadn’t completed after that there was a PANIC INT which forced a swap out to disk (hard drive).

Hence )CONTINUE.

The WS structure consisted of a heap and a stack 

I don’t recall exactly which was which but one grew up from the lower address of the allocated memory 

and the other down from the higher address of the allocated memory.

When they collided you got a WS full, and were swapped out to disk.

So there was 

1) the actual APL language interpreter itself, 

2) a mechanism to manipulate WSs (System Commands) and 

3) a number of QUAD functions to set various environmental variables and interface with the file system

(FTIE, FUNTIE, FAPPEND etc - all preceded with the QUAD symbol)

These days the environment is much richer from a resource point of view and if we had to do it again

it is interesting to speculate how we would design an environment for the interpreter to live in.

That is my interest to help satisfy my continuing passion for programming in general and APL in particular.

Meanwhile my highest regards to all of you and specially to Jürgen.

Peter

On Feb 24, 2017, at 9:02 AM, Juergen Sauermann <address@hidden> wrote:

Hi Peter,

I fully support your view. However, it is my impression that we two are fairly isolated with that opinion.
In my opinion most, if not all, attempts to "improve" on APL have failed big style. That includes J and
its various successors, but also some APL interpreters.

On the other hand it is difficult to reject a reasonable improvement proposal.
As of today the bug-apl mailing list contains 5677 posts. Many errors but also many change
requests. My algorithm (you need one) for change requests is roughly this:

1. does the change create significant incompatibilities? If yes then reject.
2. Estimate the implementation effort and the benefit for the user. If the first is far bigger than
    the latter then reject the request.
3. Can it be achieved with existing means? If so, reject (unless the benefit is considerable).
4. Does it fit into the APL language? If not then reject.
5. Otherwise accept and implement.

An example for a "good" change request was. in my opinion,  the extension of the monadic ⍳ from
scalars to vectors. No incompatibilities, easy to implement, and fitting nicely into the language.

An example for a "bad" change was the introduction of {...}. It should have passed 1., but then
been rejected in 2. (I totally under-estimated the effort), and rejected in 4 at latest. My fault, apologies
to Kenneth I.

Regarding add-on modules, I also share your view. However, my attempt to accomplish this was by
means of native functions. That approach was compatible at APL level, much more powerful than
shared variables, simple to use, in other words: perfect. However, only very few people adopted it.
So we are back to adding more and more ⎕-functions to the interpreter.

As to elegance, I would say that yes, APL is elegant, but APL systems have never been. I wrote my
first programs on punch cards, just like you probably did. I still remember my first "Wow" when working
interactively with a CRT Terminal and an immediate response from the mainframe when entering a
command. At that time, the ∇-editor and the interactive APL mode was simply cool. But since then a
lot of things have changed and things that used to be cool (and efficient for the programmer) are no
longer so. From today's perspective I would rate the ∇-editor as odd and interactive APL mode as
merely a tool for trying out short APL expressions. You cannot write larger APL programs that way.

All in all I am afraid that we have to live with a number of compromises that neither you nor me are
happy with. I also see a trend, in particular with apparently younger programmers, to see their daily
work as a burden rather than a joyful opportunity to spend their time. Maybe that is a consequence
of turning programming from an art into an industry.

Best Regards,
Jürgen Sauermann

On 02/24/2017 04:47 AM, Peter Teeson wrote:

No offence intended but 

There seems to me to be a whole lot of accretion in the non language part of GNU APL.
Useful as it may be to certain people I don’t think it’s in the elegant spirit of APL.

What used to be a nice clean, simple and easily comprehended project is now
suffering from encrustations that everyone is burdened with.

Personally it would be nice to have a basic package that is simply the interpreter, quad fns and the system commands 
leaving the rest of the detritus in add-on packages of some form.

Just my grumpy 80-year old man's opinion…<grumble grumble>

with respect….

Peter