[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation of the BOXING values.

From: Hans-Peter Sorge
Subject: Re: Documentation of the BOXING values.
Date: Sat, 9 Jan 2021 02:12:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0


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...

   apl.data ← bash_command

   python_command apl.data


   ⍝ 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

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,

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….



reply via email to

[Prev in Thread] Current Thread [Next in Thread]