Just some extra information: There is not currently (at least as far as I know) any way you can read this information from within APL. You can, however, set it using the dyadic form of ⎕FX:
*0 'foo.c:10' ⎕FX 'Z←aa X' 'Z←X+1'* This specifies that the function aa was defined on line 10 of the file foo.c . The Emacs mode reads this information using C++ code. Regards, Elias On 15 July 2014 07:45, David Lamkins <da...@lamkins.net> wrote: > That's good to know. Thanks! > > > On Mon, Jul 14, 2014 at 4:34 PM, Elias Mårtenson <loke...@gmail.com> > wrote: > >> This information is already stored. The Emacs mode uses this when >> navigating to definition of a function. >> >> Regards, >> Elias >> On 15 Jul 2014 02:19, "David Lamkins" <da...@lamkins.net> wrote: >> >>> I apologize for the confusion, but this proposal is about capturing the >>> file location of a function's definition; not about the function's >>> comments. My lead sentence was just an indicator that the earlier >>> discussion of comments triggered this new line of thought... >>> >>> >>> On Mon, Jul 14, 2014 at 11:14 AM, Juergen Sauermann < >>> juergen.sauerm...@t-online.de> wrote: >>> >>>> Hi, >>>> >>>> my favourite for code documentation is *Doxygen*. It does not currently >>>> support APL comments but we might be able to change that. Or use one >>>> of the existing tags like --- for *VHDL* or %%% for *Erlang*. >>>> >>>> It would need some changes in GNU APL - multi-line comments and >>>> proper storage of documentation information in the function so that it >>>> can de *)DUMP*ed without loosing that information. >>>> >>>> /// Jürgen >>>> >>>> >>>> >>>> On 07/14/2014 07:56 PM, David Lamkins wrote: >>>> >>>> Elias' thread about docstrings got me to thinking about other >>>> function metadata. >>>> >>>> One thing that might be nice to have is for APL to record the source >>>> location of a function's definition. >>>> >>>> If the function is defined in a file, record the path and the line >>>> number of the first line of the definition. If the function is defined from >>>> some other source, either record a suitable token that won't be confused >>>> for a filename or simply record nothing. >>>> >>>> The source location information could be exposed to APL programs via >>>> an extension to ⎕AT or via a new system function created for this purpose. >>>> >>>> Source location information could be used to implement a meta-dot >>>> command. Unlike an approach that requires use of a tags file (I'd be >>>> surprised if ctags or etags even works for APL code), the location >>>> information maintained by the APL session would be up-to-date and would >>>> correctly distinguish between a function loaded from a file and a function >>>> redefined from within the session. >>>> >>>> Finally, it'd be nice to expose a system function to allow update of >>>> the source location metadata for use by tools which need to programatically >>>> load APL code from a file. >>>> >>>> Note that capturing the source file location of a function definition >>>> is something that can't already be done in APL without writing APL >>>> equivalents of )LOAD, )COPY, )PCOPY, )IN, )PIN, etc. >>>> >>>> -- >>>> "The secret to creativity is knowing how to hide your sources." >>>> Albert Einstein >>>> >>>> >>>> http://soundcloud.com/davidlamkins >>>> http://reverbnation.com/lamkins >>>> http://reverbnation.com/lcw >>>> http://lamkins-guitar.com/ >>>> http://lamkins.net/ >>>> http://successful-lisp.com/ >>>> >>>> >>>> >>> >>> >>> -- >>> "The secret to creativity is knowing how to hide your sources." >>> Albert Einstein >>> >>> >>> http://soundcloud.com/davidlamkins >>> http://reverbnation.com/lamkins >>> http://reverbnation.com/lcw >>> http://lamkins-guitar.com/ >>> http://lamkins.net/ >>> http://successful-lisp.com/ >>> >> > > > -- > "The secret to creativity is knowing how to hide your sources." > Albert Einstein > > > http://soundcloud.com/davidlamkins > http://reverbnation.com/lamkins > http://reverbnation.com/lcw > http://lamkins-guitar.com/ > http://lamkins.net/ > http://successful-lisp.com/ >