Talk:Programming language/Archive 5

message: Again, I'm not a big fan of italics, but it's good enough so I won't quibble.  Ideogram 01:46, 22 June 2006 (UTC)
thread_title:  Lead section again 

message: I feel this article is in good shape now and all outstanding issues have been resolved.  The only major obstacle to FAC status now is the paucity of citations.  Ideogram 02:09, 22 June 2006 (UTC)
replies: text: I agree this section is too short.  Unfortunately I don't know what "dynamic semantics" means.  I don't know what else you want to say here.  Ideogram 19:50, 22 June 2006 (UTC)
replies: text: It's not clear to me what that section is even trying to say. It seems to conflate several ideas: the notion of "keywords" and program structure (which is basically syntax), and operations that might be performed. I think it might be useful to have something that discusses the basic elements of a language (sequence, selection, iteration/recursion, procedural/functional abstraction, etc.). But I don't think the current version of the section does that. --Allan McInnes (talk) 20:15, 22 June 2006 (UTC)

text: After the FAC nom process is over we can list it for peer review.  Ideogram 19:46, 22 June 2006 (UTC)
thread_title:  FAC 

message: I saw K.lee just re-bulletized the languages discussed in the History/Refinements section.  I took out bullets because... well, I find them yucky.  Maybe that's not a precise word, but it sort of suggests "Powerpoint" to me rather than "Professional article"; or more specifically, it's not quite the sort of logical enumeration that I might actually want in bullets (there is something enumerated about it, I confess, but it still somehow feels like an arbitrary enumeration).
However, K.lee is an excellent contributor, and I'm certainly not just going to change back.  Do other editors have a preference between bullets and paragraph text? LotLE×talk 19:03, 22 June 2006 (UTC)
replies: text: I have a slight preference for the paragraph-text version. However, I think that version would need a little work, since it did have an enumerated feel to it even without the bullets. That said, I'm happy enough with the bulleted version. --Allan McInnes (talk) 19:26, 22 June 2006 (UTC)

text: I don't care one way or another about bullets vs. paragraph text, but nested bullets -- yuck.  Ideogram 19:27, 22 June 2006 (UTC)

text: Oh well, I still disprefer the bullets... but there seems to be a slight tilt in their favor.  Actually, reading through the whole article again with this in mind, I realized how much I'd rather remove most of the bulleted lists.  I only actually did it that one place because I condensed the History section a bunch (since there's a more expansive child).  Then again, I wrote a long book on programming that consists of basically headings, paragraphs, and code samples.  150K words of eschewing bullets, cutesy graphics, decorations, font changes, etc... of course, Knuth is up to something like a million such words worth of dry paragraphs in TaoCP :-). LotLE×talk 19:48, 22 June 2006 (UTC)
replies: text: I certainly understand your distaste.  Nevertheless, web readers are not TAoCP readers, the web is (currently) a medium typographically inferior to print, and we are not Knuth.  Best to be realistic.  k.lee 19:58, 22 June 2006 (UTC)

text: In Wikipedia:Peer review/Scheme programming language/archive1 someone commented that most lists should be in prose form.  Ideogram 19:54, 22 June 2006 (UTC)
replies: text: The exact comment there was "This article may be a bit list-weighty; in other words, some of the lists should be converted to prose (paragraph form)."  If the article begins to feel like a collection of lists rather than a coherent article, then OK, we can revisit which lists should be converted into prose.  The commenter did not say that most lists should be in prose form, nor did (s)he reference any Wikipedia policy saying that most lists should be in prose form.  Judicious use of bullets to reflect list structure is OK.  k.lee 20:01, 22 June 2006 (UTC)
thread_title:  Bullets? 

message: I worked up a parse tree image of Allan's code.  Actually, I wrote a utility to generate a DOT language representation of an arbitrary Python program.  But the image I put above is actually a slight manual simplificaton of the actual parse tree.  Does the image seem usable? I can tweak options like fonts and layout style.  For example, there's a wild looking "energy minimized" layout; but the top-down hierarchical seems more usual.
Later: Since there was so much whitespace in the parse tree image, I stuck syntax highlighted code in the middle of it, including highlighting the part that's actually parsed.  As a little self-referential joke, the code I put around it was the actual utility used to generate the parse tree.
Anyway, the code to generate the graphics is below.  Btw. Allan: where did you get the symbol names for your parse tree.  I found that symbol.sym_name had some but not all the names, so I had to improvise by copying from your output.
 # mk_dot.py
 import parser, symbol, sys
 symbol.sym_name[0] = 'ENDMARKER'
 symbol.sym_name[1] = 'NAME'
 symbol.sym_name[2] = 'NUMBER'
 symbol.sym_name[4] = 'NEWLINE'
 symbol.sym_name[5] = 'INDENT'
 symbol.sym_name[6] = 'END'
 symbol.sym_name[7] = 'LPAR'
 symbol.sym_name[8] = 'RPAR'
 symbol.sym_name[11] = 'COLON'
 symbol.sym_name[14] = 'PLUS'
 N = 0
 def getNodename():
     global N
     N += 1
     return 'node%s' % N
 def dotwrite(ast):
     nodename = getNodename()    
     label= symbol.sym_name.get(int(ast[0]), ast[0])
     print '    %s [label="%s' % (nodename, label),
     if isinstance(ast[1], str):
         if ast[1].strip():
             print '= %s"];' % ast[1]
         else:
             print '"]'
     else:
         print '"];'
         children = []
         for n, child in enumerate(ast[1:]):
             children.append(dotwrite(child))
         print '    %s -> {' % nodename,
         for name in children:
             print '%s' % name,
         print '};'
     return nodename 
 if __name__=='__main__':
     ast = parser.suite(sys.stdin.read())
     l_ast = parser.ast2list(ast)
     print 'digraph L0 {'
     print '    size = "8,8";'
     print '    ordering=out;'
     print '    node [shape = box];'
     dotwrite(l_ast)
     print '}'
The tokenization is simple enough I'd just do it by had.  Well, it wouldn't be tough to write a similar DOT output utility. LotLE×talk 01:21, 24 June 2006 (UTC)
replies: text: The other symbols come from the tok_name dictionary in the token module. Sorry should have made that clear before. --Allan McInnes (talk) 19:18, 25 June 2006 (UTC)
thread_title:  Parse tree image 

message: The new practice section and placing the specification and implementation subsections there is very good.  Ideogram 02:58, 23 June 2006 (UTC)
thread_title:  Practice section good 

message: Somewhat along the line of the NLP thing, I wonder if we should have a bit of a nod to literate programming here.  I think the idea that programming languages are, in fact, as much about communicating concepts among people as actual instructions to machines, is worth noting.  It's not entirely excluded from the existing text, but I think it's underplayed.  I'm not sure the literate programming itself is the main point: many languages emphasize readability, and good programs that aren't "LP" as such, still have clear and extensive comments.  Something like Python's doctest is interesting as what I find a better fulfillment of the original goals of LP.  But Java's Javadoc has some of this idea as well... or even Perl's POD.  Actually, there's "Literate Haskell" too, which is a funny creature. LotLE×talk 20:28, 23 June 2006 (UTC)
thread_title:  [[Literate programming]] 

message: Sorry, I wasn't clear.  First, the inset depicts the code to invoke the Python parser.  This isn't necessary.  The point is to illustrate a piece of code and its syntax tree, not the Python parser API.  The inset should just have add5.  Second, the Python docs may call the result an AST, but it's much more like a CST in the Dragon Book sense (although admittedly the distinction between a CST and an AST does not have a precise technical definition).  To make the tree more AST-like I would:
:I added the extra code inset to illustrate syntax highlighting, as was suggested above.  The fact the code hightlighted happens to be the same as used to generate the parse tree is just one of those recursive jokes.  However, the one-line suite of 'add5()' seemed too short to illustrate syntax highlighting.  If there's some other bit of "famous" or "notable" source code, we could highlight that, I just like self-reference.
:Anyway, here's two more things for discussion.  The one is the actual complete parse tree as generated by Python's parser module (more CST-like, I recognize).  The second is the minimized version that I generate by automatically removing single-linked intermediate productions.  It still includes some terminals like parens that you may consider superfluous, but I like the idea of having a moderately robust looking tree. LotLE×talk 23:44, 25 June 2006 (UTC)
replies: text: I think this minimized version is good enough.  Let's put it in.  Ideogram 23:59, 25 June 2006 (UTC)
replies: text: Agree.  However, I think that we should demonstrate syntax highlighting in a separate figure somewhere higher up in the article.  It's fine (actually, sort of cool) if the syntax highlighted code example is also the code that generates the parse tree shown in the later figure.  I just don't want this one figure to be too crowded.  k.lee 22:22, 26 June 2006 (UTC)

text: I meant "real" in the sense that the AST (or CST) is actually something generated by an existing Python interpreter or compiler. I'm fine with using a a notional AST of some kind. I just think it needs to be clear that the AST in question is notional, and created specifically for the article: the reader will not be able to recreate the AST in a Python interpreter. --Allan McInnes (talk) 21:49, 25 June 2006 (UTC)
replies: text: It seems I spoke too soon. Although I haven't played with it, it seems likely that this module might provide a way to get a Python AST that is more abstract than the so-called ASTs produced by the parser module. --Allan McInnes (talk) 22:00, 25 June 2006 (UTC)
thread_title:  Simplified