Hi Jürgen: Thanks for your usual gracious reply. I understand the points you present.
Perhaps my perspective is too narrow? The way I see it the key “module” is the interpreter of the language. IMHO display of the results, means to enter and store data of various types, providing an environment where the interpreter executes are really separate, but necessary, components.
You mentioned that rationals need to be explicitly configured. Personally I would prefer that approach rather than encrusting the interpreter. Each capability added to the interpreter just complicates it - of course not for you as the author but for us lesser mortals.
As you may recall I am on a Macintosh. One project I pickup and work on from time to time is to try and extract only the interpreter and then use the Mac OS facilities for the rest. Of course that is only of use to other Mac users (if at all). Separating the interpreter from the rest allows for different “models” - OS’s.
What we have right now is a monolithic code base which becomes more fragile with each added feature, version of GCC, or HW box - desirable as that might be.
I suppose what I am suggesting is that perhaps it’s time to take a fresh look at the project architecture and ask ourselves if we can improve.
FWIW
respect….
Peter
On Sep 22, 2017, at 11:48 AM, Juergen Sauermann < address@hidden> wrote:
Hi Peter,
I mostly agree with your concerns. As you may have noticed, I
already regretted some of the things that I implemented earlier
in GNU APL. On the other hand, you also see on the GNU APL mailing
list the proposals of other GNU APL users to implement
certain things. I haven't really found a way out of this dilemma.
My current thinking is this:
1. If a feature affects the APL language itself then it is
probably a bad thing to do. Examples for this are, IMHO, changing
the scoping
of variables, lexical binding and stuff like that. As useful
as these may be in other languages, my feeling is that they would
turn GNU
APL into something else which is no longer APL. For example, I
am a big fan of the powerful matching capabilities in Erlang but I
believe as useful as they may be, they simply do not belong
into GNU APL (or any APL for that matter). Those who really need
that (as
opposed to only believing it would improve GNU APL) might be
better off with one of the successors of APL.
2. Some areas, most notably FILE I/O have traditionally not been
part of the APL language itself, but are unfortunately needed in
the
real world. I am equally concerned about a proliferation of
quad functions (and most other APLs are more keen than GNU APL to
move in that direction). However, regular expressions are a
more fundamental concept than other "nice to have but never used"
features, so that adding them as a ⎕-function should not do too
much harm. Nobody is forced to use a ⎕-function that he or she
does not know or like. And the only thing that gets more
complicated when a ⎕ function is added is the implementation and
not
the language.
Rational number, BTW, have to be explicitly ./configured and are
not present in the default GNU APL. Same for parallel APL. I have
seen that some users are experimenting with these features and I
believe we should allow that because chances are that these
experiments result in something valuable some day. Who knows?
Best Regards,
/// Jürgen
On 09/21/2017 04:19 AM, Peter Teeson
wrote:
It so happens that 2 of my former colleagues from I.P.Sharp came visiting today and we were chatting about this.
Ken was not in favour of making APL complicated. When I worked at IPSA my office was next to Ken’s
and when someone suggested some form of addition to the language he would usually ask
why we could not do it with an APL function. (These days performance can hardly be a compelling argument
with multiple many-core CPU chips.)
Right now we already have a proliferation of Quad functions not to mention lambdas and native functions.
We also have divergent APLs such as Dyalog (good as it is) and so on.
Complex numbers, rationals and file systems are good additions.
But IMHO we should have one simple mechanism - i.e. the libapl APL API
and all the rest go through that as native functions.
Jurgen’s guiding light is to make GNUAPL an implementation that met the ISO and APL2 definitions.
We have already wondered away from that. Pity. When will it stop?
Just my 02¢
respect
Peter
On Sep 20, 2017, at 4:30 PM, address@hidden wrote:
<mumble> anyone who loves grep and hates perl (and i hope java too) can't be all bad </mumble>
using apl like syntax is good aaa' ⎕REX['s'] 'bbb' what would monadic ⎕REX['s'] 'bbb' return?
On Wed, 20 Sep 2017 21:47:29 +0200
Juergen Sauermann <address@hidden> wrote:
Hi Elias,
I am generally in favour of supporting regular expressions in GNU APL.
We should do that in a way that is compatible with the way in which the most commonly used libraries
do that (even if they are lacking some features that more exotic libraries may have. Unfortunately I do not
have a full overview of all (or even any) existing libraries. I personally love grep and hate perl (the latter not
only because of their regexes).
I would like to avoid constructs like s/aaa/bbb/ where operations are kind of text-encoded into strings.
That is, IMHO, a hack-ish programming style and should be replaced by a more APL-alike syntax such as
'aaa' ⎕REX['s'] 'bbb' or maybe 's' ⎕REX 'aaa' 'bbb'.
Or, if the number of operations is small (perl seems to have only 2, not counting the translate which is already
covered by other APL functions), then we could also have different ⎕-functions for them and thus avoiding a
third argument.
Everybody else, please feel invited to join the discussion.
Best Regards,
Jürgen Sauermann
On 09/20/2017 05:59 AM, Elias Mårtenson wrote:
On several occasions, I have felt that built-in regex support in GNU APL would be very helpful.
Implementing it should be rather simple, but I'd like to discuss how such an API should look in order for it to be as useful as possible.
I was thinking of the following form:
regex ⎕Regex string
The way I envision this to work, is to have the function return ⍬ if there is no match, or a string containing the match, if there is one:
'f..' ⎕Regex 'xzooy'
┏⊖┓
┃0┃
┗━┛
'f..' ⎕Regex 'xfooy'
'foo'
If the regex has subexpressions, those matches should be returned as individual strings:
'([0-9]+)-([0-9]+)-([0-9]+) '⎕Regex '2017-01-02'
┏→━━━━━━━━━━━━━━━┓
┃"2017" "01" "02"┃
┗∊━━━━━━━━━━━━━━━┛
This would be a very useful API, and reasonably easy to implement by simply calling into the standard regcomp() call: http://pubs.opengroup.org/onlinepubs/009695399/functions/regcomp.html
What do you think? Is this a reasonable way to implement it? Any suggestions about alternative API's?
Regards,
Elias
|