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/
>
