bug-apl
[Top][All Lists]
Advanced

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

Re: Sage council and advice


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

Hi Bill,

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

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[49] but
combined with 18⎕CR or 19⎕CR to convert the UTF8 bytes into/from proper APL
characters.

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[41]. 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).

Best Regards,
Jürgen Sauemann


On 12/12/19 10:31 PM, Bill Daly wrote:

I've attached a work-in-process, utf8.apl

When I created this library my objective was to simply read and write utf8 text files without the overhead of FILE_IO. As I've worked on other projects and discovered a file related need I inserted here.

The very simplicity is now undermined.

Do I

  1.  Ignore simplicity and just keep adding useful stuff here.
  2. Create a new work space to supplement FILE_IO
  3. Lobby the powers that be to add somethings to FILE_IO
  4. Learn how to fish and retire for APL.

Thanx in advance for you imput


w



reply via email to

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