I agree with you that extensions should, as far as possible, be in a loadable package.
However, some features can't be built in pure APL. Either because the underlying functionality simply isn't there, or because an APL-based implementation would be too slow. Let's take a simple example: a timer facility. I want to be able to have an operator that evaluates an expression, giving me the time it did to run that. Such a function is hard to impossible to write correctly in standard APL since all you have is the ⎕TS variable, which you cannot reliably convert to a timestamp (because of leap seconds and DST. The days-in-month is also a problem, but can at least be managed with lots of superfluous code). Hence, an extension is needed. In the case of GNU APL, that extension is accessed through FIO∆gettimeofday. This extension can then be used to build the necessary functionality to do timers, as well as plenty of other things. Now, if you don't want to use these features, you don't have to touch the ⎕FIO functions at all, and I really see no benefit in having a separate version of GNU APL that does not include it. Now, personally I'd love to see the ability go outside of ⎕AV when defining functions, but that one is a bit more controversial. :-) Regards, Elias On 24 February 2017 at 11:47, Peter Teeson <peter.tee...@icloud.com> wrote: > No offence intended but > > There seems to me to be a whole lot of accretion in the non language part > of GNU APL. > Useful as it may be to certain people I don’t think it’s in the elegant > spirit of APL. > > What used to be a nice clean, simple and easily comprehended project is now > suffering from encrustations that everyone is burdened with. > > Personally it would be nice to have a basic package that is simply the > interpreter, quad fns and the system commands > leaving the rest of the detritus in add-on packages of some form. > > Just my grumpy 80-year old man's opinion…<grumble grumble> > > with respect…. > > Peter > > >
