|
in reply to Re: Perl Programming Tools - (who, what, where, when, and why)
in thread Perl Programming Tools - (who, what, where, when, and why)
I don't know any tool that does syntactical hilighting.
What they do is lexical hilighting when this is possible, that
is when tokenization is orthogonal with parsing.
A real tool will have to hook to the Perl parsing engine
to do a decent job in all cases. More generally I don't
know of any litterate development environment in the Open
Source world. We still use age old tool like emacs and vi
which is a sure sign how backward we are.
BTW:I am told that MS-Visual tool are far mode advanced.
This is very odd because litterate tools would fit more naturally
in Open Source world than in a closed one.
--
stefp --
check out Nemo
|
Re^3: Perl Programming Tools - (who, what, where, when, and why)
by John M. Dlugosz (Monsignor) on Oct 14, 2002 at 19:22 UTC
|
Source Insight does more than "just" lexical parsing to highlight keywords. However, it doesn't hook the Perl parsing engine. Admittedly, the concept is much more useful in a strongly-typed language like C++, where I can see a list of available members and word-completion after typing an expression thus-far, because it knows the type of that expression result and can look up the class definition.
For Perl, limited typing of lexicals are available, and simply scanning the Package lexically to find potential member names is not going to work in "fancy" frameworks.
Using Perl's parsing engine is not enough. It would need to execute the script to some point to determine what gets set up on-the-fly in the package's symbol table, and even then, you can't truely know the set of all X where $p->X is legal, because of AUTOLOAD tricks for lazy loading, generation of members on first-use from a declared template, etc.
| [reply] |
|
|
| [reply] |
|
|
I don't know if it can!
If you tie something, you are basically saying that you're implementing the interface for a built-in type, so that value can be stored in any so-typed variable.
Code is written that uses an INTEGER (In Perl6, the all-cap is the class, and the lowercase is the machine primitive, right?). You pass in a value that is really the Perl6 equivilent of Perl 5's tie feature, whatever it is called (the normal isa/implements syntax should do it, I suppose).
If assigning a value to it really has bizzare side effects, that code doesn't know it. Neither can a compiler or other tool doing static analysis of the code.
That's a property of the run-time value, not the lexical variable that holds it.
| [reply] |
|
|
