octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

handling comments in the parser


From: John W. Eaton
Subject: handling comments in the parser
Date: Wed, 6 Jun 2012 17:04:07 -0400

While looking at implementing classdef, which will require the largest
changes to the parser in a long time, I started thinking about how we
handle comments there and am wondering if we could simplify things a
lot with little noticeable difference in the user experience.

At some early point in Octave's history, I modified the parser to
store comments in the parse tree.  The idea was that a command like
"type" would be able to reproduce the text of a function from the
syntax tree that is generated by the parser, and that the text would
include the comments.  Attempting to do this added a fair amount of
complexity and I don't think I ever got it completely right.

Part of the motivation for generating text from the parse tree was so
that the "type" command could work for functions defined on the
command line.  But really, how often does one comment those functions?
And now, type doesn't even work for functions defined on the command
line.  That should probably be fixed, but is it really necessary for
the output of type to include comments in that case?  If it is, then
perhaps we should store the input text directly and display that
instead of attempting to recreate it from the internal parse tree.
That would be similar to what we do now when "type" is asked to
display a function defined from a file, which is to simply open the .m
file corresponding to a given function and display it verbatim.

One place where printing the parse tree still happens is if you set
echo_executing_commands to a non-zero value.  For example,

  octave:1> function f
  > % this is a comment
  > 1
  > end
  octave:2> echo_executing_commands (3)
  octave:3> f
  + function f ()
  + ## this is a comment
  + 1
  ans =  1
  + endfunction;

But note that some possibly unwanted transformations have happened
here (% -> ##, end -> endfunction, displaying an empty argument list
with '()' when nothing was entered) so that seems to me like another
reason that we should really be storing the input text directly from
the command line instead of trying to attach comments to the parse
tree.

So would there be any objection to simplifying the parser so that it
discards comments (except for the first block that defines the
docstring for a function; we would continue to store that as needed)?
Can anyone think of trouble that this change would cause?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]