It could be argued that it makes some sense on mobile, since native libraries on Android is messy at best.
That said, I intend to provide a built-in API to support various Android-specific features. Some of those will probably be more useful than shared variables, maybe. Regards, Elias On 29 Jun 2014 17:31, "Juergen Sauermann" <[email protected]> wrote: > Hi David, > > my view regarding shared variables is that they are a creature of their > time, kind of Dinosaurs. > > I have implemented them only for compatibility with IBM APL2 to ease > portability existing APL programs. You can have a look at > *testcases/AP*.tc* > to see how to use them. > > Shared variables are OK for experimenting (and I will fix the faults that > you > will find) but I would not use them for new programs. Native functions are > more state-of-the-art and easier to use than shared variables. > > /// Jürgen > > > On 06/28/2014 07:14 PM, David B. Lamkins wrote: > > On Sat, 2014-06-28 at 14:13 +0200, Juergen Sauermann wrote: > I also doubt that anybody is using shared variables at all because I > haven't received any trouble reports on them. > > > /// Jürgen > > > > That's true in my case. > > Earlier this week I did make a first attempt to understand how SVs work. > > In the short term I'll need to construct a workflow that lets me do more > than trivial experiments with SVs. I rely on Elias' gnu-apl-mode for APL > input. To work with SVs I'll need to patch gnu-apl-mode to provide for > additional command-line options (so I can pass --SV --id # to GNU APL). > Or something... It seems inelegant to have to customize each running > instance of Emacs to set up an id. > > At this point, I don't have any definite plans for SVs beyond > experimentation to help me understand the strengths and weaknesses of > the approach. > > > > > > > >
