Re: Documentation of the BOXING values.

[Hans-Peter Sorge]

Hi,

just my opinion...

The list of programming languages I used to use is looong.

When APL got deployed at IBM, all employees were supposed to learn APL - 
for a supposedly more efficient work environment.

Few were able to efficiently use it.

Production Control code -> I modified it ~400 lines to 15 lines, much 
faster .

5100 ( who remembers it ); It was connected via modem to Sindelfingen host
(slightly illegal at that time as we connect a computer to a telecom 
land line. Local APL to pickup data from chip mfg.)
We got a call who the hell was able to type that fast :-))

Will say, APL was perfectly matching the needs of our engineering people 
from the 70s to 90s.

When having developed a planning application for the European 
translation centers,
APL was not up to par (any more) having two significant drawbacks:
1 - more complex UI development (compared to 3270 green screen, rexx)
2 - even more important: The beauty of APL, to work with complex but 
always fully defined data structures
   in a closed work space, limited the data volume that could be 
handled in "one shot".

CMS - pipes is a tool, which goes beyond those APL limits.
1 - Actually there is 'no UI'. The data representation "will just be 
displayed" - not magic - but rather simple.
2 - The "functions", called stages, STRICTLY DO NOT DELAY A RECORD.
   That is, a multi stage pipe ( eg. 4000 lines of code), reads a 
record, processes it, and dispositions the record.
   It's possible to process a virtual unlimited number of records. 
There is no workspace needed for all data records.
   The disposition of data can happen based on the records content. 
Move the record to DB, disk, screen, port, discard - 'in one shot'

An APL equivalent could be.
   ⍝ display data in libreoffice (or even any other 'application' like 
gimp, librecad, inkscape ....) - (my be no need for ⎕QT, ⎕GTK ....)
   'libreoffice.sheet' ⎕APP some.matrix  ⍝ display data from 
some.matrix on a spread sheet.

   ⍝ Elements are being processed one by one each from source to target 
- like record wise processing in CMS pipes.
   ( file terminal port ) ← selection_by_element_function 
some.complex.data.structure
   ⍝ a super position of  ( file terminal port )  will result in the 
same rank, shape and depth as given in some.complex.data.structure

As each programming language has a sturdy foundation, and it's quite a 
challenge to extend them
there might be a way to combine them...

)BASH
   apl.data ← bash_command

)PYTHON
   python_command apl.data

)PERL
   ........

)APL
   ⍝ back to normal

Even if it is hard to maintain the nature of a programming language, I 
think to exclude extensions is not an option.

Time for weekend:-)

Best Regards
Hans-Peter


Am 08.01.21 um 22:18 schrieb Dr. Jürgen Sauermann:
> Hi Peter,
>
> yes, ⎕CR and ⎕FIO are entirely "nice to have" things that I felt could
> be useful. ⎕CR is a pandora box of conversion functions while ⎕FIO
> contains a collection of operating system functions.
>
> I have tried to limit the number of functions in ⎕CR and ⎕FIO to
> only those that are really tricky to do in APL itself, so they are
> a bit more than just convenience functions.
>
> I remember that in the 1970s we used to write auxiliary processors
> to implement this kind of functions - primarily for performance reasons.
> In my opinion the lack of this kind of interfaces was one of the reasons
> why APL was not as widely adapted as it should have been (the other
> reason was, IMHO, the high prices of APL interpreter and machines
> at that time). So with GNU APL at my disposal I can now create an
> APL that has exactly the features that I want it to have.
>
> I'm a retired programmer and I still like to program as a hobby. Many of
> the ⎕-functions started as little programming exercises that I like to
> do from time to time. After having spent considerable time with such
> an exercise, I sometimes decide to share the result, either as ⎕CR
> or ⎕FIO sub-functions or, for more complex ones, as ⎕-functions.
> My current exercise is, by the way, ⎕XML which will become an
> interface to XML files.
>
> Having that said, there is no need to keep up with the development
> of ⎕CR and other ⎕-functions. You can safely ignore their presence
> (and they don't eat bread as we say in Germany).
>
> Best Regards,
> Jürgen
>
>
> On 1/8/21 8:03 PM, Peter Teeson wrote:
> > Hi Jürgen:
> >
> > Thanks so much for your patient help.
> >
> > Being so out of date with modern APL I am completely “gob-smacked” 
> > (as the Brits used to say).
> > Did not realize how much ⎕CR has been extended from the 1984 IBM APL 
> > 2 Language Reference Manual.
> > Ditto for the 2000 ISO Standard.
> >
> > The elegance and beauty of the pure language, as extended, still 
> > remains.
> > But to me the proliferation of ⎕ functions, useful as they may be, 
> > seem somewhat overwhelming.
> > Do we really need all of them I wonder? Or are they just “it would be 
> > nice to have” things”?
> >
> > Oh well… I’m just a grumpy old man I guess….
> >
> > respect….
> >
> > Peter