Hi,
actually *]SYMBOL *shows it as *Creator* attribute.
/// Jürgen
On 07/15/2014 04:39 AM, Elias Mårtenson wrote:
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
<mailto: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 <mailto: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
<mailto: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
<mailto: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/
