|
From: | Juergen Sauermann |
Subject: | Re: [Bug-apl] Request to add to the ⎕fio[] a 'function_common_name' as argument |
Date: | Wed, 4 Jan 2017 17:33:08 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 |
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: |
[Prev in Thread] | Current Thread | [Next in Thread] |