Hi Elias: If we consider other programming languages and the size of their vocabularies vs the number of apl symbols, 256 seem to be enough for now. (and if we add in the plethora of system functions, variables and commands which have been added on willy nilly … well ….)
We tend not to think in terms of the textual names of the symbols. Consider a dictionary / thesaurus using the symbol names. I suggest it would be an interesting read. But because of the delightful terseness of the language we overlook the depth that each symbol has. > What is needed is an API that allows an extension developer to work on a > higher level. My question was mainly about what that API should look like. Yep… that’s why my suggestion of I-Beam…simple, clean, easily understood, and it’s up to the developer to do the work… which is where it should lie... We could certainly discuss what tags along with the I-Beam… Dyalog’s is pretty extensive and I think a bit excessive. I don’t know if APL2 has an implementation - I couldn’t find it in the Lang Ref Manual. To me I think something along the lines of: a) add the symbol to the parser so we don’t get "No Token” as an error message b) define what environment is made available to the called library - a.k.a. plugin. c) should it be able to be localized in a user defined function? d) should it support just a single plugin - with the path passed at launch perhaps? e) should an array of paths be allowed at launch so that several libraries could be used but only one active in scope? And so on…. However all these question should be deferred until there is some agreement that this would be agreeable. Unless I don’t understand, it would not be a huge effort for Jürgen to implement. respect…. Peter
