Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
First of all, I want to thank everyone for carrying on this discussion. Second, I'd like to echo the positive comments regarding GNU APL. I've seen a lot of free APL systems come and go over the past 40 years; GNU APL is really the first one that's both useful and open-sourced. My heartfelt praise goes out to Jürgen and GNU APL's many contributors. I'd like to shift the discussion slightly toward the notion of programming-in-the-large. Libraries are a part of this, but there are other considerations. When APL was new, large software systems tended to be constructed using a combination of purpose-built code and a limited selection of special-purpose libraries. The libraries tended to be either designed specifically for the larger system, or were carefully evaluated and curated for inclusion based upon specific criteria. The culture of library-oriented-programming, although discussed as a desirable part of software engineering pretty much since the origin of those discussions, has really only come to fruition in the past decade or two. IBM/ISO APL (i.e. the ancestor of GNU APL) was designed at a time when libraries were scarce. As such, IBM/ISO APL is not well-suited to the modern practice of mixing and matching from among a broad selection of similar or competing libraries. There are, I believe, two primary issues that ought to be addressed: 1. namespace management, and 2. package/dependency management. Namespace management is simply a way of being able to use software authored by various people or organizations without having to involve the original authors in the resolution of conflicting identifiers. There are nearly as many solutions to this problem as there are modern computing languages. Namespace Management (example) -- In the APL world, Dyalog (which I cite only due to familiarity and experience) has namespaces. You can download the manual from their web site and get the full documentation, but I'll summarize to the best of my recollection: )ns creates a namespace )cs sets the interpreter's default context to the given namespace Dyalog namespaces may be nested. There's a distinguished token to identify the root namespace. IIRC, there's another distinguished token to allow navigation upward (similar to .. in the Linux shell). You can use dotted paths to name identifiers in other namespaces. The name of a Dyalog namespace is independent of the identifiers created within the namespace. This is an important distinction, as it allows the application programmer to choose the name of the namespace. I don't recall whether Dyalog has any quad-functions specific to their namespace implementation. I imagine certain existing quad-functions and system commands (quad-NC and )SINL, to name just a couple) would need to be aware of namespaces. To be clear: I don't have any particular affinity for Dyalog's particular solution to the namespace problem. I do, however, believe that *some* namespace solution is required in order for APL to be viable for programming-in-the-large. Package Management (discussion) --- I haven't actually seen a good example of package management in APL. Dyalog has SALT (see the documentation on their web site); I believe that SALT doesn't go far enough. In my opinion, an APL package management system should address at least the following concerns: * provide access to repositories of code, both local and remote, * maintain metadata to aid in the identification and selection of packages * allow access to multiple versions of each package, * express and resolve dependencies among packages, and * provide a command to instantiate a package and its dependencies within the current workspace, automatically using namespaces to isolate the packages from the application programmer's code. I believe that such a package management system could be coded entirely in GNU APL given the existence of a namespace facility in the core language. I have some preliminary thoughts regarding a design of an APL package management system, but I'll save that discussion for later. Anyhow, that's my musing for the day... I'll be interested to hear whether anyone else thinks that it would be of value to push GNU APL beyond a core plus libraries, toward some measure of support for programming-in-the-large.
Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
This discussion is and has been healthy and useful - at least to me. Jürgen's point's wrt the open issue of libraries etc gives us good ground to stand on. Are we not all "newbies" wrt GNU APL even those who have a history using APL? I certainly feel that way. Personally there has been an underlying philosophy one tries to follow in computer programming. How best to resolve the tension between immediacy and elegance; between commercial deadlines and beauty. And the issue of libraries and other add ons is part of a larger one - which language to use for implementation. Because the choice of language so often conditions and constrains the solution set of the problem. Personally I cannot recall how many times I have wished for access to call into APL to use it's array processing strengths. Each language has strengths and weakness': Assembly,C/C++/Obj-C, Lisp. SNOBOL, COBOL, Fortran, APL, ADA, PL1, OpenGL, etc, etc. To me these are all merely tools that should be available to artisan programmers to use wherever and whenever appropriate. So in an ideal world one would be multi-lingual and be able to make use of whatever "tool" one chooses at the moment. Providing GNU APL with an elegant and beautiful mechanism for libraries is a highly worthy objective. Totally agree with Jürgen's quotes below. But in this exploration stage perhaps we should branch this off, or use some mechanism to indicate it's experimental. This so that it can be withdrawn or deprecated should it turn out not to be the "best" solution. from Jürgen's email: "That means that Elias is correct in asking for certain functions in order to make GNU APL more useful. And most of you seem to agree that such functions shall not be part of the core GNU APL, but in libraries. ... A. the extension mechanism used shall be native functions B. A library consist of: 1. C/C++ support functions in the GNU APL interpreter (creating APL values, access to values, etc.) 2. C/C++ code for native functions, typically wrappers to existing libraries, 3. APL code (⎕FX of the native function, but possibly more), 4. documentation"
Re: [Bug-apl] clang Warning
Hi, I see. I have changed the test in configure so that it checks whether the compiler is g++ rather than whether it accepts -rdynamic. SVN 221. That should also avoid the same warning in Solaris. /// Jürgen On 04/22/2014 07:01 PM, Peter Teeson wrote: Hi Jürgen: Gandalf:~ pteeson$ man gcc No manual entry for gcc Gandalf:~ pteeson$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix Apple discontinued using gcc a while back and it is no longer installed as part of Xcode. For gcc external builds Apple uses llvm-gcc. respect…. Peter On 2014-04-22, at 12:39 PM, Juergen Sauermann wrote: Hi Peter, man gcc ? /// Jürgen
Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
Hi , don't wait any longer for ⎕host. Its already there - called popen() in FILE_IO. see man popen how to use it. /// Jürgen On 04/23/2014 03:33 PM, enz...@gmx.com wrote: On Tue, 22 Apr 2014 22:14:21 -0400 Peter Teeson wrote: Blake said: "This means creating a quad function to load, execute, and interface with shared libraries (so/dll/etc). It also means standard ways of communicating data back and forth" clap clap clap. +1. This would be just perfect and remove the burden of developing interfaces specific for libcurl and libsqlite3 and libmysqlclient etc and reinforce the meaning of open source. As for the file system it was built separately but interfaced with the interpreter through the same idea. I could in fact ask one of my former colleagues with whom I'm still in touch as he was the maintainer. Right now i've been using fpc (freepascal) and bash file functions and )host for my file work I'd love to see )host (become ]host or ⎕host) and return output And I think GNU APL is a great gift and Jürgen's herculean effort to bring us this far is beyond compare. Well said and kinda unbelievable actually how good it is. I've already quit using the nearest thing I had SAX (Sharp APL)
Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
Hi Blake, I believe your 1, 2, 3 below is exactly the current priorities of GNU APL and 3. is already present. We use shared libraries for extending APL so you don't need an extra developer lib for that. The only thing needed is a header file declaring the functions available in GNU APL (maybe not all of them), compile, and then dlopen() the lib in APL (which is already the essence of GNU APL native functions). I would not make such functions ⎕-functions, (see my previous posting) because that would blur the line between user-defined and system functions. /// Jürgen On 04/23/2014 02:10 AM, Blake McBride wrote: Greetings, Your email sparked many thoughts. Not that my opinion necessarily counts for anything, I think this should be GNU APL's priority list: 1. Fix all known bugs and portability issues as they are discovered. 2. Support all of APL's standard defined features (i.e. trace, stop, etc.) 3. Create a generic mechanism whereby APL can be arbitrarily extended without re-compiling its source. This means creating a quad function to load, execute, and interface with shared libraries (so/dll/etc). It also means standard ways of communicating data back and forth. Doing it this way, all extensions can/should be done via shared libraries and APL glue code. This way modules (shared libraries & APL glue code) can be added for component or keyed file systems, GUI libraries, Regex, XML, etc.. The APL source would have to be enhanced a bunch of times to increase the generality of its interface to the external object. This would occur as limitations or inconsistencies are discovered. After a time, this interface will stabilize. I know GNU APL already has this, I just think it needs to mature - and it will as we hit the interface with a greater variety of needs. Just thinking out loud for a moment, perhaps a GNU APL developer library can be built that the shared objects can utilize. It would provide functions to translate APL objects to and from C/C++ objects and other functionality that would make it easier to write the extension modules. You state: "The obvious question is: Why would we want another open-source APL?" Another? There are only two other open-source APL system worth even mentioning: NARS2000 & OpenAPL. NARS2000, while good, suffers from two problems. First it is (unfortunately and unnecessarily) bound to Windows. The second problem is that it has insufficient persistence capabilities - only the rawest. Already GNU APL puts it to shame. OpenAPL is an old hack that was whipped together in a short time and never really worked. IMO, GNU APL is a thing of beauty. It's available in source, it's close to complete, it's portable, it is well supported by the author and the community. And, with all the off-putting, insulting communities out there, the GNU APL community is fantastic! I have waited 30 years for something like this, and I like and appreciate it! So, I think there is nothing like GNU APL. It is a gift. As the generic interface is enhanced, and more modules are built, this could become extremely powerful. In fact, I think GNU APL can surpass the APL vendors easily. Given source access opens up the system to many, many developers. Just think about Linux. The stability and efficiency of Linux far surpasses that of Windows and even Mac OS/X. With respect to the compiler bit, APL has always stressed the use of array processing rather than loops. APL is at a good place with respect to the increase of multi-processors. The value of a compiler decreases as one increasingly does thing in an APL/array oriented way. The interpreter orientation of most APL's enables much or APL's development conveniences, appeal, and productivity. I think an APL compiler is the subject of a different project. Just some thoughts. Thanks. Blake
Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
On Tue, 22 Apr 2014 22:14:21 -0400 Peter Teeson wrote: > Blake said: > > "This means creating a quad function to load, execute, and interface with > > shared libraries (so/dll/etc). > > It also means standard ways of communicating data back and forth" > clap clap clap. +1. This would be just perfect and remove the burden of developing interfaces specific for libcurl and libsqlite3 and libmysqlclient etc and reinforce the meaning of open source. > As for the file system it was built separately but interfaced with the > interpreter through the same idea. > I could in fact ask one of my former colleagues with whom I'm still in touch > as he was the maintainer. Right now i've been using fpc (freepascal) and bash file functions and )host for my file work I'd love to see )host (become ]host or ⎕host) and return output > > And I think GNU APL is a great gift and Jürgen's herculean effort to bring us > this far is beyond compare. > Well said and kinda unbelievable actually how good it is. I've already quit using the nearest thing I had SAX (Sharp APL)
Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
Hi, I really appreciate the discussions on this because I believe there is a open issue (libraries and how to provision them). 1. First of all I would like to share my current point of view regarding ⎕-functions and -variables. The (only ?) good thing about them is that they are ready to be used from the beginning of an APL session. Some ⎕-functions are definitely useful while others look more like vendor-lock-in features as David has correctly noticed. But they have a number of disadvantages as well: - more effort (than native functions) to integrate them into GNU APL, - shift of maintenance responsibility from the creator to core GNU APL, - difficult to extend, - they don't scale well (in terms of producing, testing and documenting them). - non-standard and therefore non-portability of code using them. These were the main reasons for me to not implement them when asked to do so, like "why does ⎕xyz not work on GNU APL ?". Since GNU APL is public domain, there is not point in locking-in users. 2. The other traditional extension mechanism, shared variables, is a little more modular and avoid some of these disadvantages, but have others (awkward interface, separate thread or process needed, etc.) As an intermediate summary, I will not put much effort into developing new ⎕-functions or shared variables. I may integrate shared variables contributed by GNU APL users if they are compatible with existing IBM shared variables. 3. This brings us to the point of libraries. Historically APL has always been suffering from a lack of libraries like we know them from other languages. There have been APL code-snipplets around, but using them has always been difficult. I would even argue that the lack of a mechanism to provide was one of the reason that APL has not been as successful as other languages. How else could you explain that eg. Perl is so much more popular than APL? That means that Elias is correct in asking for certain functions in order to make GNU APL more useful. And most of you seem to agree that such functions shall not be part of the core GNU APL, but in libraries. We already have a few libraries created (FILE_IO, emacs_mode, SQL databases, ... ) and I believe there will be more. What I see technically (and also considering my role in that) is this: A. the extension mechanism used shall be native functions B. A library consist of: 1. C/C++ support functions in the GNU APL interpreter (creating APL values, access to values, etc.) 2. C/C++ code for native functions, typically wrappers to existing libraries, 3. APL code (⎕FX of the native function, but possibly more), 4. documentation Each of component 1-3 is optional, so you could have an APL-only lib or a native-function-only lib. I can take care of 1. because I expect that the number of such functions needed will decrease considerable over time. For 2. it is possible to provision these functions as part of GNU APL (as we have done it for FILE_IO and emacs_mode) or outside GNU APL (as currently for SQL). There are pros and cons for both cases. I would leave it to the designer of a library to decide whether she wants to have it distributed with the GNU APL package or else to store on some other repository. In the first case we can then discuss the details. For 3. and 4. I have no strong opinion yet. With the new )DUMP command I have tried to establish a basis for exchanging APL code in a generally usable (i.e. UTF8) text format. Such text files can easily be created, modified, and published on web pages. The )COPY command now accepts these files as input and can also be used recursively. Pretty much like #include in C/C++. I would prefer such text files over binary files because of portability. So the remaining question is where to store (eg. s...@gnu.org, github, etc) and how to distribute (contained in GNU APL tar file or separate) 2., 3. and 4. For me as a designer that is not so relevant, but I guess the the friends of GNU APL shall make themselves heard. /// Jürgen
