Hi Xtian,
thank you very much for your proposal. I am not too fond of the idea
though.
Not because of the coding effort on my side, but because of other
considerations.
Consider the following syntactical variants of the same thing, and
my personal
judgements of their readability and portability:
Syntax Readability
Portability
a. Z←A
⎕FIO[3] B worse no
b. Z←A ⎕FIO['fopen'] B OK no
c. Z←A FIO∆fopen B better yes
then your proposal (which is obviously
b. above) is IMHO
better readable than a.,
but arguably worse than c. (which is
)COPY 5 FILE_IO). But
there are also some
downsides:
- is is an entirely redundant syntax, and
- it lacks portability
I believe it is generally a good thing to have a wrapper workspace
like
FILE_IO because it
makes workspaces using it portable to other interpreters (where, of
course, somebody
has to implement the functions provided by
FILE_IO). It was,
for example, possible to change
the underlying implementation of
FILE_IO from a native
function to a system function
⎕FIO.
People using
FILE_IO at that time would (at least
conceptually) not notice any difference
when that change was made, while people not using
FILE_IO
will need to change their
workspaces all over the place when the native variant will finally
disappear.
And my experiences with redundant syntax constructs in GNU APL are
also rather negative.
Looking backwards I would judge my decision to accept lambdas in GNU
APL (which was, BTW,
also proposed by a GNU APL user at that time) as my worst decision
in the GNU APL project so far.
Best Regards,
/// Jürgen Sauermann
On 01/04/2017 07:16 AM, Christian
Robert wrote:
I would love to be able to do:
fd ←⎕fio['open'] '.bashrc'
⎕fio['fclose'] fd
and so on ...
I have a Workspace named "fio" who just do that, but I would love
if gnu-apl could just understand 'open'/'close'/... rather than
just random numbers, as actually.
Numbers are fine, but a tagged name as in ⎕fio['bind'] would be a
*plus*. (no need for us to remember the random numbers, only the
function name)
Yes, a couple of hours for Juergen to code it, but so much
reliefs/and/easier on our side, as end user.
my wishes for 2017 ;-)
Xtian.