I think the point is portability. Axis notation in function definition
(especially using an character array as an axis) is not in any standard, afaik,
so it's impossible to hack such a function in any other APL implementation. An
workspace/package uses this FIO function wouldn't be able to function properly
in other APL implementation.
> On Jan 5, 2017, at 8:16 PM, Christian Robert <christian.rob...@polymtl.ca>
> wrote:
>
> I see your point, well, I hacked something, some kind of a wrapper around ⎕FIO
> who give me *very near* of what I wanted, eg: not to have to copy tenth's of
> functions
> to be able to call the FIO by name.
>
> ∇FIO[⎕]∇
> ∇
> [0] z←L FIO[X] R;a
> [1] →(2≠⎕nc 'X')/Noaxis
> [2] →(0=↑0⍴X)/Number
> [3] a← ('errno' 1) ('strerror' 2) ('fopen' 3) ('fclose' 4) ('ferrno' 5)
> ('fread' 6) ('fwrite' 7) ('fgets' 8) ('fgetc' 9) ('feof' 10)
> [4] a←a,('ferror' 11) ('ftell' 12) ('fseek_set' 13) ('fseek_cur' 14)
> ('fseek_end' 15) ('fflush' 16) ('fsync' 17) ('fstat' 18) ('unlink' 19)
> ('mkdir' 20)
> [5] a←a,('rmdir' 21) ('printf' 22) ('fwrite' 23) ('popen' 24) ('pclose' 25)
> ('readfile' 26) ('rename' 27) ('dir' 28) ('ls' 29) ('getcwd' 30)
> [6] a←a,('access' 31) ('socket' 32) ('bind' 33) ('listen' 34) ('accept' 35)
> ('connect' 36) ('recv' 37) ('send' 38) ('usend' 39) ('select' 40)
> [7] a←a,('read' 41) ('write' 42) ('uwrite' 43) ('getsockname' 44)
> ('getpeername' 45) ('getsockopt' 46) ('setsockopt' 47) ('fscanf' 48)
> [8] a←a,('open' 3) ('close' 4) ⍝ And some handy aliases
> [9] →(0=↑⍴X←,⊃((⊂X) ≡¨↑¨a)/a)/Nomatch
> [10] X←¯1↑X
> [11] Number: →(2≠⎕nc 'L')/Monadic
> [12] Diadic: z← L ⎕FIO[X] R ⋄ →0
> [13] Monadic: z← ⎕FIO[X] R ⋄ →0
> [14] Nomatch: ∊("Unknown function:") (X) ⋄ →0
> [15] Noaxis:→(2≠⎕nc 'L')/NoaxisMonadic
> [16] NoaxisDiadic: z←L ⎕FIO R ⋄ →0
> [17] NoaxisMonadic: z← ⎕FIO R ⋄ →0
> ∇
>
> Only one function is needed to be copied into a workspace (FIO), it
> understand the axis by number as usual but it also
> understand the axis by name.
>
> Juergen, feel free to include it into the FILE_IO workspace if you think it
> may be useful to others (and rename it if you
> want, like FIO∆ or something else).
>
> not yet 100% tested but you get the idea. I had to use "usend" and "uwrite"
> for the UTF-8 aware send/write.
>
> and thanks again for your thoughtful explanation,
>
> Xtian.
>
>
>
> On 2017-01-04 11:33, Juergen Sauermann wrote:
>> 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.
>>>
>>
>
> )sic
> )erase FIO
> ∇z←L FIO[X] R;a
> →(2≠⎕nc 'X')/Noaxis
> →(0=↑0⍴X)/Number
> a← ('errno' 1) ('strerror' 2) ('fopen' 3) ('fclose' 4) ('ferrno' 5) ('fread'
> 6) ('fwrite' 7) ('fgets' 8) ('fgetc' 9) ('feof' 10)
> a←a,('ferror' 11) ('ftell' 12) ('fseek_set' 13) ('fseek_cur' 14) ('fseek_end'
> 15) ('fflush' 16) ('fsync' 17) ('fstat' 18) ('unlink' 19) ('mkdir' 20)
> a←a,('rmdir' 21) ('printf' 22) ('fwrite' 23) ('popen' 24) ('pclose' 25)
> ('readfile' 26) ('rename' 27) ('dir' 28) ('ls' 29) ('getcwd' 30)
> a←a,('access' 31) ('socket' 32) ('bind' 33) ('listen' 34) ('accept' 35)
> ('connect' 36) ('recv' 37) ('send' 38) ('usend' 39) ('select' 40)
> a←a,('read' 41) ('write' 42) ('uwrite' 43) ('getsockname' 44) ('getpeername'
> 45) ('getsockopt' 46) ('setsockopt' 47) ('fscanf' 48)
> a←a,('open' 3) ('close' 4) ⍝ Aliases
> →(0=↑⍴X←,⊃((⊂X) ≡¨↑¨a)/a)/Nomatch
> X←¯1↑X
> Number: →(2≠⎕nc 'L')/Monadic
> Diadic: z← L ⎕FIO[X] R ⋄ →0
> Monadic: z← ⎕FIO[X] R ⋄ →0
> Nomatch: ∊("Unknown function:") (X) ⋄ →0
> Noaxis:→(2≠⎕nc 'L')/NoaxisMonadic
> NoaxisDiadic: z←L ⎕FIO R ⋄ →0
> NoaxisMonadic: z← ⎕FIO R ⋄ →0
> ∇
>
