|From:||Dr . Jürgen Sauermann|
|Subject:||Re: Sage council and advice|
|Date:||Tue, 17 Dec 2019 18:38:58 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1|
here are my comments...
1. I have seen that every function in your workspace has a comment line
that briefly explains what the function does. Very good. Many libraries that
I have seen before were lacking adequate documentation, which is quite
a waste of time on the part of the developer, although not uncommon in APL
Now, if you would replace the single ⍝s in you code by a double ones, i.e. make
them ⍝⍝ then you (and everybody else) could use the GNU APL command ]DOXY to
create a browsable (HTML-based) documentation of the workspace without any
other effort. So people could get a rather convenient documentation of your
workspace. ]DOXY should even work for workspaces imported from other APL
interpreters, e.g. for documenting historic APL code.
2. The workspace name utf8 suggests that some conversion to/from UTF8-encoding
is taking place. However, I haven't found that happening in the workspace. For a function
that reads a UTF8 encoded file, the most convenient result would, IMHO, be a nested
vector of lines with CR/LF removed in the process. Something along lines of ⎕FIO but
combined with 18⎕CR or 19⎕CR to convert the UTF8 bytes into/from proper APL
Regarding the FILE_IO workspace, I believe it will die out as some point in time. I was
thinking of allowing string arguments for the axis, so that one could say, for example
⎕FIO['read'] instead of ⎕FIO. Once that is done, the FILE_IO is obsolete. I just
didn't have the time to fix ⎕FIO.
Another problem (not in your case, though) related to the use of libraries is
clashes of function and variable names. I was thinking about namespaces,
but the way in which other APL interpreters have done it has alienated me more
than convinced. Also C++ namespaces seems to be more of a burden than
an improvement, not to talk about other languages. Any suggestions in that
direction (scope, syntax) will be considered (the implementation will take quite
a while, though).
On 12/12/19 10:31 PM, Bill Daly wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|