Re: [Bug-apl] APL and text editors- some initial thoughts
Hi Peter, good question, I'm really happy to explain it. GNU APL is almost completely Doxygen documented. Almost conmpletely means that new functions take a while before I update the Doxygen documentation (it makes little sense to do that while functions come and go). Doxygen is a terrific tool for creating software documentation. If you run 'make DOXY' in the top-level GNU APL directory then it will create a lot of .html files in the directory html. You can browse these files, starting at index.html. The files show the structure of the code, who calls whom etc. Now back to your question: You may have noticed that the comments in the header file start with /// instead of //. That is a marker for Doxygen telling it that the line is documentation for the item following it. And the \b is a Doxygen formating character for bold so that the next work will be bold in the Doxygen generated files. /// Jürgen On 04/28/2014 10:00 PM, Peter Teeson wrote: OK thanks I'll take a look. Been a long while since I did C++ so this will be a refresher. BTW why do I see so many \b just in .hh files where there are comments describing method declarations? e.g. /// true iff this line number is smaller than \bother bool operator <(const LineLabel & other) const; /// edit the function specified in \b cmd (e.g. cmd = "∇FUN") static void edit_function(const UCS_string & cmd); and many other places in the header files. I understand it as an ASCII backspace control code. But why is it in the comments? respect… Peter
Re: [Bug-apl] APL and text editors- some initial thoughts
Hi Peter, the current line editor of GNU APL is in Nabla.cc. It is pretty simple. The editor gets its line input from Input::get_user_line_nabla(). My concern with [a?b] is this: currently we print a prompt and then get a user line from either readline or from the operating system (in cooked mode). The editing facilities within the line (delete char, insert char, etc.) are either provided by readline or by the OS (or shell?). In order to do [a?b] we could: 1. ignore the column but recall the line and make it editable, or 2. full [a?b] with cursor positioned at column b (or was it a? The description in the IBM manual is pretty thin]. For readline this is kind of do-able (not trivial) because readline has functions for stuffing characters (the recalled line) back into it. For the OS (fgets() based) this could be entirely different and may need knowledge of the terminal (backspace vs. erase etc, or cursor positioning? The OS variant is probably much harder to get right and portable. I guess most user are fine with 1. alone because that is currently missing. Long term my plan is have an )EDITOR command that lets you specify an APL function (typically a native one) that is called with a character array like ?CR 'foo' and returns a new array with the new function header and body. So if you want to give it a try then please go ahead! I'll be happy to answer all questions that you may have. /// Jürgen On 04/28/2014 06:17 PM, Peter Teeson wrote: Hi Jürgen: Is there a way I can help with this? Which are the source files that implement the line editor? On the assumption that the internal line editor should behave the way that the APL2 Editor 1 does - for SVN 235 build 6472 on my Mac the internal line editor does not match the IBM APL2 Language Reference description of how their Editor 1 works. See page 391 respect Peter
Re: [Bug-apl] APL and text editors- some initial thoughts
Peter, The Emacs mode is much more than a simple way of editing functions in an editor. The intention is to transform the standalone GNU APL interpreter into some kind of IDE in a similar way as SLIME does for Common Lisp. The Emacs mode backend provides similar functionality as the Swank backend for Common Lisp. You can watch the video I posted yesterday to get an idea of how it integrates with Emacs: http://www.youtube.com/watch?v=yP4A5CKITnM As you might understand, there is a very tight level of integration there. I would be very happy if someone would like to write a Vim frontend (for example) utilising the same communications protocol. Currently, however, there is only an implementation for Emacs. Regards, Elias On 29 April 2014 00:14, Peter Teeson wrote: > Hi Elias: > Firstly I am *totally* agnostic as to which text editor should be used. > I don't even understand why there should be an Emacs mode. > But since you said it's actually generic maybe we can change it's name > to more clearly reflect its generic nature? External Editor Mode? Just a > fleeting thought. > [APL2 had an )Editor command] > > There does need to be state switching from (immediate) execution to > editing to etc… > The IBM APL2 Language Reference has a brief discussion about this in Ch 9. > > As I said I need to get up to speed on the existing mechanism. > Right now all that I have found is the existing source "Emacs" code. > > Rather than read through a multitude of postings of something that is > already in existence is there a document that I can read if I wished to > interface > e.g. TextWrangler telling me how would I go about it? > (I don't intend to do that - just try to understand what we have now as an > interface) > > respect > > Peter > >
Re: [Bug-apl] APL and text editors- some initial thoughts
Hi Elias: Firstly I am totally agnostic as to which text editor should be used. I don't even understand why there should be an Emacs mode. But since you said it's actually generic maybe we can change it's name to more clearly reflect its generic nature? External Editor Mode? Just a fleeting thought. [APL2 had an )Editor command] There does need to be state switching from (immediate) execution to editing to etc… The IBM APL2 Language Reference has a brief discussion about this in Ch 9. As I said I need to get up to speed on the existing mechanism. Right now all that I have found is the existing source "Emacs" code. Rather than read through a multitude of postings of something that is already in existence is there a document that I can read if I wished to interface e.g. TextWrangler telling me how would I go about it? (I don't intend to do that - just try to understand what we have now as an interface) respect Peter
Re: [Bug-apl] Bug-apl] APL and text editors- some initial thoughts
Hello Peter, You might want to read up in the email archives on the discussions that led to the creation of the Emacs backend. It was done exactly because Jürgen did not want to maintain a special protocol used for things such as the Emacs mode. It's included in the base release because shipping it separately would be incredibly cumbersome for anyone who wanted to use it. Besides, Emacs is the official editor of the GNU project, and GNU APL is, well, the official APL of the GNU project. :-) Besides, the backend may be called Emacs, but it's actually generic. Regards, Elias On 28 April 2014 23:26, Peter Teeson wrote: > Hi Jürgen - I'm back from a mini-break. > The ISO Standard Ch 16 p 239 et seq specifically states > "The user makes entries on a keyboard, and obtains responses by seeing > them presented on a display- device. The combination of a keyboard and a > display-device is intended to represent, abstractly, a terminal. This > International Standard does not require the use of any particular terminal, > keyboard, display or method of encoding characters. The ISO 2022.2 APL > character encoding reproduced in Annex A is widely used. > > The display-device is considered a window into an unbounded sequence of > past entries and responses. The mapping between this unbounded sequence and > the display-device is not specified by this International Standard. " > IOW it's implementation defined. Nevertheless APL2 has been mentioned as > a sort of de facto standard. > IMHO the design for a GNU APL text editing capability ought to be > something like this: > > (1) The default internal editor is an implementation of the APL2 Editor 1 > as described in the APL2 Language Reference Manual pp 383-394 et seq. > > (2) All other text editors are >(a) either written in APL itself and thus )LOADable from some library or >(b) are external editors, chosen by the user, and interfaced to the > interpreter in a standard manner. > In particular I think it highly undesirable to have code in the core > release to support any specific external editor. > > Why? Because we should have an as minimal as possible core implementation > that meets the standard. > Non-lingual extensions should be optional to the core implementation and > should interface through the cleanest and simplest possible mechanism. > Inclusion should be an intentional activity of the end user. > > Why? Because once code becomes part of the core implementation users > become "addicted" to it and later on it's impossible to remove it - it must > be supported forever and constrains future development. This is not a > clever design and we see numerous instances of this in the wild. Having an > OO paradigm approach is a more preferred way - not necessarily for > everything but certainly for interfacing add-ons, plugins, whatever you > want to call them. The interface is stable whilst the add-ons can change. > > So, for example, perhaps we can have a Session Manager Class as well as as > well as an Editor Class from which the internal Editor 1 inherits; external > editors can also do so even if they need wrappers. > > As to how the editor interfaces with the interpreter I need to get up to > speed with the current situation. > Last time I was involved with the internals was ~40 years ago and things > have changed - both in the language itself and in the programming > paradigms; particularly the Object Oriented paradigm becoming very > prevalent these days. > > More about designing the item (2)(b) standard interface later after I dig > deeper. > > respect > > Peter > > >
[Bug-apl] Bug-apl] APL and text editors- some initial thoughts
Hi Jürgen - I'm back from a mini-break. The ISO Standard Ch 16 p 239 et seq specifically states "The user makes entries on a keyboard, and obtains responses by seeing them presented on a display- device. The combination of a keyboard and a display-device is intended to represent, abstractly, a terminal. This International Standard does not require the use of any particular terminal, keyboard, display or method of encoding characters. The ISO 2022.2 APL character encoding reproduced in Annex A is widely used. The display-device is considered a window into an unbounded sequence of past entries and responses. The mapping between this unbounded sequence and the display-device is not specified by this International Standard. " IOW it's implementation defined. Nevertheless APL2 has been mentioned as a sort of de facto standard. IMHO the design for a GNU APL text editing capability ought to be something like this: (1) The default internal editor is an implementation of the APL2 Editor 1 as described in the APL2 Language Reference Manual pp 383-394 et seq. (2) All other text editors are (a) either written in APL itself and thus )LOADable from some library or (b) are external editors, chosen by the user, and interfaced to the interpreter in a standard manner. In particular I think it highly undesirable to have code in the core release to support any specific external editor. Why? Because we should have an as minimal as possible core implementation that meets the standard. Non-lingual extensions should be optional to the core implementation and should interface through the cleanest and simplest possible mechanism. Inclusion should be an intentional activity of the end user. Why? Because once code becomes part of the core implementation users become "addicted" to it and later on it's impossible to remove it - it must be supported forever and constrains future development. This is not a clever design and we see numerous instances of this in the wild. Having an OO paradigm approach is a more preferred way - not necessarily for everything but certainly for interfacing add-ons, plugins, whatever you want to call them. The interface is stable whilst the add-ons can change. So, for example, perhaps we can have a Session Manager Class as well as as well as an Editor Class from which the internal Editor 1 inherits; external editors can also do so even if they need wrappers. As to how the editor interfaces with the interpreter I need to get up to speed with the current situation. Last time I was involved with the internals was ~40 years ago and things have changed - both in the language itself and in the programming paradigms; particularly the Object Oriented paradigm becoming very prevalent these days. More about designing the item (2)(b) standard interface later after I dig deeper. respect Peter
