From: Arnulf W. <ar...@wi...> - 2010-04-09 08:50:04
|
Am Freitag 09 April 2010 09:28:46 schrieb Lars Hellström: > Bartek Nowakowski skrev: > > Hi, > > > > I've just filled all paragraphs of my student proposal, which could be > > found under: > > http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/sup > >/t127074590978 . I would be very thankful for any comments and criticism. > > First be warned: I've got several projects of my own > (http://wiki.tcl.tk/14031, http://wiki.tcl.tk/17367) in this area, but > with a philosophy that is rather different from the autodoc one, so my > remarks may be biased. > > Second, from glancing through Arnulf's code, I'm somewhat skeptical > regarding the parsing approach he's taken; I fear it is too simplistic > to be reliable. Also, it may as far as raw parsing of Tcl scripts is > concerned merely be a duplication of work already done -- see for > example http://wiki.tcl.tk/9649. I wasn't aware of parsetcl when I did that code, so it might be useful to use that instead for normal Tcl. For itcl and TclOO general structure parsing I think the approach is ok, for the body of the methods then again the parsetcl package could be used. The cross reference could be made on the tree structure then > On the other hand, a lesson I learnt > there is that parsing by the Dodekalogue is merely the beginning, > because then you need to identify commands and interpret their > arguments accordingly, which can lead to new rounds of parsing. > > In other words, the traditional model of "scan source, producing > tokens; parse token stream; done" doesn't fit the Tcl reality -- the > "tokens" are usually trivial, and you're far from done understanding > the program just because you've parsed it.[*] A significant task will > be to find a language for describing command syntaxes to the > documentation tool, so that it can adapt to new control structures. > > [*] Of course, one might argue that the Dodekalogue merely describes > how Tcl code is /scanned/; in that case a division into "scanning" and > "parsing" may actually be appropriate. > > Third, I would in general be interested in a tool that can read Tcl > code and tell me where various things are used, even if I'd have to > provide a separate back-end to it. > > Finally, it feels a bit odd that the first two paragraphs of the > application are so similar. Maybe the abstract shouldn't say what > Arnulf is doing, but rather focus on what you intend to accomplish? I also think instead of mentioning my name a link to the wiki page with the GSoC proposals would be enough. @Bartek: maybe you should mention that the plan is to parse the Tcl scripts into some meta data and then as one dedicated part you build the documentaion and the cross reference part using that meta data Arnulf > > Lars Hellström > > > --------------------------------------------------------------------------- > --- Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Tcl-gsoc mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-gsoc > |