On Sat, 2012-03-17 at 15:09 -0400, Norman Ramsey wrote:
> Ross,
>
> I am delighted that someone wants to improve noweb's support for
> Python, and I took a quick look at your patches. I'm sorry to report
> that I am not very happy with the decisions that you have made.
> Perhaps we can work together to identify a way that noweb can support
> Python which will be more in keeping with the original design, and
> which I feel that I can incorporate into upstream sources and
> maintain.
It's great to hear from you. I knew the changes seriously broke the
program's model, partly out of expediency and partly, I thought, out of
necessity. Perhaps I'm mistaken about the necessity. Obviously it would
be good to avoid such changes if possible.
>
> > I could not simply add pipeline stages since the tangled file needs to
> > refer to itself and to the .nw file
>
> I'm not sure why you would ever want the tangled file to refer to
> itself, since the purpose of a #line directive is to refer to the
> original noweb sources.
I think the part about referring to itself was just a goof on my part.
The issue is that the tangled file needs to refer to *name* of the nw
file, not just line numbers. This is because the name is actually an
argument to the python code that repairs the line references.
>
> > the filenames are not available in standard processing.
>
> Have you overlooked the @file tag in noweb's filter representation?
> File names are available there.
I need the source (that is .nw) file name; since the source is the
standard input, that is unavailable in the current design, right?
>
> > I also wanted to add column information to the -L directive...
> > I found the out of the box behavior of -L not to work with
> > python--it screwed up the indentation of subsequent lines.
>
> Notangle in general, when used with the -L directive, has been
> carefully crafted to ensure that each character of code in the tangled
> output resides in the *same* column as it did in the original sources.
> However, this technique will clearly not work in languages like Python
> or Haskell, where indentation is significant, and the source code
> *must* be moved from its original position. Because the -L option
> *does* preserve the information about the original columns, I believe
> it may be best for you to shift the code using either a noweb filter
> or perhaps a postprocessing step. (I wrote noweb 23 years ago, and I
> don't remember exactly where the #line directives are introduced.)
I found that, apart from the glitch with -L, noweb did shift the columns
relative to the original. That is, using an indentation of 4 spaces
excerpted from my file:
-------------------- eg.nw--------------------
<<AbstractCommand>>=
class AbstractCommand:
"""Information about a command and its timing.
This embodies the command pattern through the execute method"""
<<AbstractCommand execution>>
<<AbstractCommand status queries>>
@
<<AbstractCommand execution>>=
def execute(self, timeoutQueue):
"execute self and put myself in timeout queue"
self._pre_execute(timeoutQueue)
--------------------------------------------------------------
results in .py output in which "def execute" is indented 4 spaces,
matching the indentation where the code block was invoked in the first
block. And the body of execute is indented 8 spaces.
This strikes me as the most natural behavior for python. So the final
(.py) code in general must end up with different indentation than the
lines in .nw. Any other behavior would make life hard for python
programmers.
>
> I'm handicapped by not knowing anything about what Python uses in
> place of #line or how you intend to exploit it. I inspected your
> patches but was not able to figure out the big picture, other than
> that you plan further postprocessing at run time with your 'detangle'
> script.
Python has no #line-like facility. The detangle script does dirty
tricks to achieve the same effect.
Here was my little test input and output.
-----------------------web.nw ---------------------------
@
<<web.py>>=
class Foo:
<<Foo methods>>
classy Bar:
"""I was a syntax error"""
pass #2nd time
x=Foo()
x.run_error()
@ Test if this is indented properly, and that is reverse for error
report.
<<Foo methods>>=
def run_error(self):
print 1/0
---------------------- web.py ----------------------
from detangle import detangle
detangle('web.py', 'web.nw')
#if 0:
#line 3 0
#class Foo:
#
#line 16 4
# def run_error(self):
# print 1/0
#
#line 6 0
#
#classy Bar:
# """I was a syntax error"""
# pass #2nd time
#
#
#x=Foo()
#x.run_error()
-------------------------------
Note web.py refers to the name of the .nw file in it's second line, and
the #line directives include extra indentation (relative to the .nw
original) as the second argument.
# is the comment character in python. So formally this is a 2 line
program with a long comment. When detangle runs it reads in the file
(first argument to detangle), strips the leading #, and uses the #line
entries to hold a translation table if an error arises. Then it
compiles and runs the real code.
>
> > I'm also contemplating using the python ast module to parse the code
> > for index purposes in noweave. Currently, only notangle has changed.
>
> I've had good luck using several different compilers to parse code and
> index it. I've always done this without touching noweb.
It becomes another syntax module, right?
>
>
> Norman
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
