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 > <juergen.sauerm...@t-online.de> 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, enz...@gmx.com <mailto:enz...@gmx.com> 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 <juergen.sauerm...@t-online.de> >>> <mailto:juergen.sauerm...@t-online.de> 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 >>>> <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 >>>> >> >> >
