Perl

Perl is a scripting language written by Larry Wall and first released in 1987. If you're looking for a scripting language with more syntax than most compiled languages and none of the speed, Perl might be just the thing ;)

: As nasty and tasteless as Tcl is, it is a positive dream compared to Perl. The only conceivable way to write a correct Perl program IMHO is cutting and pasting from someone else's code. - Philip Greenspun ,The Bookshelf

Reference edit

Perl Timeline
Five great Perl programming techniques to make your life fun again ,Baron Schwartz ,2006-10-05

Critique edit

What's wrong with Perl ,Lars Marius Garshol ,2002-01-16: In particular the difficulties there seems to be with making lists of lists are interesting.

Description edit

In this day of convergence of technologies, it should not be surprising to people that there has been, for a number of years, cross-pollination of ideas between the two languages. Malcolm Beattie wrote some perl modules quite a long time ago that trying to interface to tcl and to tk. Also, Dov Grobgeld and Guenther Schreiner did likewise. Later Nick Ing-Simmons went to the extreme effort of creating a series of scripts to separate tk from tcl, and then created a Perl module that talked to the now interpreter-less graphical library. This module, aka pTk or Perl/Tk, is the most frequently used one of the four that I have seen announced. pTk installs without any Tcl libraries - the interface is done between a modified version of the Tk C API. Another approach of using Perl and Tk together is using Tcl::Tk, and this appears to be much more flexible, while remaining with same functionality and syntax.

There has been a desire by many language developers to see these modifications rolled back into the Tk source tree. The idea is that if the default Tk is agnostic about its scripting language, then all scripting languages could have equal footing in terms of their bindings. Not only that, but non-scripting languages, such as C, C++, etc. would have an easier time making use of this powerful extension.

In the past, some Tcl/Tk developers expressed concern that to do this would relegate Tcl even farther to the background of attention.

RLH: I am a Perl Monk. That said, I find that comp.lang.tcl is just as responsive and helpful. Besides Tcl Monk doesn't sound nearly as good. : )

lv: Perhaps the community would consider adding, either here or on a new page, references, helpful tips, etc. to people who know perl but who are trying to understand Tcl. In particular, if there are specific concepts which have the same name, but differing behaviors, noting those areas would be helpful.

Perl Features Desired In Tcl edit

Perhaps some people would list some of the features of Perl, either as a strict language, or from a module/package/extension point of view, that they wish would come to Tcl.

Since you ask. Sometimes I yearn for perl's terseness while other times I revel in Tcl simplicity, but these are just syntactic sugar really. What I really want in tcl is:

built in debugger: tkcon is excellent and blows away the perl console hands down and idebug is a good start, but not being able to single step is a real shortcoming. I've tried three times to get TclPro to work, the last was just last week, but I never got it to work on non-trivial programs. Plus, it blew away all my tcl path variables so I junked it.
CPAN: having one place to look for extensions, plus a very uniform way of installing them is very nice. Tcl with the ActiveState distribution (ActiveTcl) is getting better but it's still not as slick as CPAN.
perlmonks: VK a great and highly responsive support site, based on people searching and giving answers to perl questions; usually a question receives many answers within a half of an hour.

Arjen Markus: I think a built-in debugger is actually easy to create in pure Tcl. Just source a source file and in the process add debug commands that will pause the proc, or continue until a breakpoint comes along, should not be too difficult! (This would slow down the execution ...)

peterc 2008-10-06: Teapot/Teacup now implement something quite CPAN-like, as far as being a central repository for stable Tcl packages. I'd argue it actually goes one better in some respects: rather than downloading source and compiling (as in CPAN), Teacup downloads precompiled binary packages for your architecture. This can save you an awful lot of pain and effort in getting things to install and run (ask anyone who's had to install Perl's DBD::Oracle on Solaris).

RS: See for instance a minimal debugger on how to administer breakpoints in a few lines of Tcl.

Arjen Markus: Like I said. Expect comes with a similar debugger.

Perl Vs. Tcl edit

It's natural to compare Perl and Tcl. When a developer's starting a new project, which will serve him or her best? One of the propositions that often appears at this point is that, "Perl is best at string-handling." I don't subscribe to this.

First, I acknowledge that many people believe the claim. There's some sort of validity to it, just in its popularity.

Second, programmers should realize that Perl and Tcl are more alike than different, in that both make string handling far easier than it is in C, C++, or Java.

Perl does make interestingly pervasive use of regular expressions. This is characteristic of Perl. It's quite interesting, and, in the hands of an expert, it can be rather breath-taking. There are also a couple of distinct reasons to question how much it benefits developers:

First, REs are overdone. That's simply a fact. I encounter quite a bit of code that REs obfuscate, rather than streamline. Among the alternatives are simple procedural "un-rollings", and elementary string manipulations through facilities such as Tcl's string command.
Also, Perl's REs have specific problems that Larry Wall describes in [find reference].

My summary, then, is that I feel perfectly comfortable performing string manipulations in either Perl or Tcl (or Python, for that matter, which has yet a different style), but I know I'll use different idioms for the two (or three). Perl often is more concise. I have a personal belief that idiomatic Tcl string-handling tends to be more readable.

VK: on the other side, perl's RE engine is highly optimized: when one writes /^(...)/, the interpreter effectively eats three characters without even starting searching process. But this leads to another problem, when C code implementing such technology becomes very complicated and there is lack of RE experts on C level (true for Tcl, Perl and probably entire RE world).

Todd Coram:

Every once in the while I consider rewriting AFT in Tcl or Python. It was originally written in Awk, and I rewrote it several times in Perl since 1996. Each time I try a rewrite in something other than Perl it seems pointless. Perl is perfect for what it does. It's my own personal prejudice, but Perl just seems more natural for text munging. Tcl is too chunky and Python feels too Pascal like for the task. Maybe its the pervasive regular expressions or the Awk-like implication that you will be working with munging text files.

My brain works this way:

Perl: for text munging in short lived processes.
Python: for algorithmic programs meant to be readable. (compare w/ Pascal or Java; CL frequently calls Python the single most widely applicable language)
Tcl: for everything else ;-) guis, daemons, glue, lego-like toys

anonymous coward:

This is an extremely insightful commentary(above) IMO. Recently I have seen how the event loop really lends itself to *nixish daemon type processes for little things like honeypots, user process and command history monitoring, and other clandestine but basically sound processes. I have to wonder though about the python reference for algorithms. Is it only because it's OO that he feels this way? Using python procedurally doesn't improve on anything(again IMO).

jrw32982: Perl has references, which are like pointers in C. Tcl doesn't have references, only names. In perl, when the reference count of a data item becomes zero, the data item is garbage collected. In tcl, because there are no references, you have to write your own garbage collection code.

For example, assume you have a tcl array whose values are objects (itcl objects, for example). When you replace the object associated with some index with a different object, how do you know if the object previously associated with that index should be destroyed? If the only "reference" to the object is from that index in the array, then the object should be destroyed when the it is replaced. Otherwise, it shouldn't. If you fail to destroy an object which is no longer referenced, then you have a memory leak in your program. If you destroy an object which is referred to from another place in your program, then you have a potential major bug. An automatic garbage collection mechanism would solve this problem for you.

Clarification: when I say memory leak, I don't mean that Tcl is leaking memory. As far as I know, Tcl has no memory leaks. I mean that your program is leaking memory. In the scenario I described, you have created many objects (using some OOP extension to Tcl) but have lost track of their handles. They are inaccessible because you have lost their handles, but the memory associated with them has not been recycled since you haven't destroyed them. If that continues, you will eventually run out of memory.

Addendum Jan 2014: I notice that Jim has references.

AMG: Brush also proposes references, though Brush references are fundamentally different than Jim references.

Lars H 2006-07-04: It could be argued that this isn't as big a problem in Tcl as it would be in many other languages, because in languages with references it is often necessary to use them to build complex data structures. In Tcl (and as long as it is data you're juggling with, as opposed to data + some other resource) it is typically possible to pass around very large data structures as easily as one passes around numbers in other languages, and then everything is cleared up automatically.

Clif Flynt: I learned Perl first. Wrote an application I can no longer read, and then tried to fix someone else's code. That's why I became a Tcl advocate.

PSE: I had exactly the same experience as Clif. I felt encouraged by the Perl community at the time (1997) to make free use of Perl's idiotic pre-defined default variables (with cute names like $' $` $, $.), and could not maintain any program over 20 lines long that made use of them!!

LES: I really dislike that argument. If those variables cause you trouble, don't use them! Perl treats us like adults. If you like terseness, bask in all its terseness. If you like very clear and organized code, especially when you intend to share it, write your own very clear and organized code and be happy. That free attitude will not protect you from someone else's terseness, but forcing people to use "very clear and organized code" even when they don't want to is not the best way. Educate them, but don't force them. Whenever I think of Python's use of indents as part of the syntax, I think: this soup nazi hates terse code and thus created a language that would make it compulsory for everyone to write in the style that *he* prefers. Despite it all, I, for one, can find terseness in practically any language. Whenever someone uses lots of single-character variables in anything with more than half a dozen lines, I find it very hard to read. Keeping tabs on what $a, $b, $c, $i, $j and $r mean to read and understand a function or class is very annoying. But they are all free to use their obscure variables. And more sensible programmers will give their variables more meaningful names, so you always know exactly what is going on without unnecessary effort. Free choice is the best ultimate judge. When a language allows for both terseness and tidiness, it is fair and generous. If the language removes either, it shows it is made for one specific tribe and is not afraid to disregard diversity in writing preferences.

Tcl Analogues of Perl Functionality edit

Recently on comp.lang.tcl, someone asked, yet again, what the tcl equivalence to Perl's pack function is.

I thought I recalled, somewhere in the past, some site having a table that showed correspondence between perl functionality and tcl functionality.

Anyone reading this recall such a thing - if you still know where it is, could you insert it on this page?

-- Take a look at the binary command.

Yes, the binary command answers the specific question. But it doesn't help in the general case - where someone either converting some perl code to tcl, or who knows perl and is trying to learn tcl, wants to find equivalents.

-- Sorry, I didn't read the question through. The BOOK Programming Language Examples Alike Cookbook does this to some extent, but I'm not sure a simple functionality equivalence table would be very useful, because of the differences on other levels. Also, what functionality is equivalent, anyway? For instance, Perl has no (exact) equivalent to, say, [puts]...

-- Well, Perl's print is similar functionality, though one has to explicitly specify newlines, whereas in tcl one has to explicityly specify no newlines.

Has anyone compared the Perl functionality from the perl source distribution to see what functionality would need to be written for Tcl and added to Tcllib (or perhaps to Activetcl) so that they had closer to the same level of functionality?

VK: In my understanding those are (incomplete list, please add/remove items):

Config module; one can check configuration variables at run-time of module; in Tcl this could be tricky. (to answer questions like: where is my perl.h, perl.lib, so to rely on those probably versioned parameters; wheter current binary is threaded; tclConfig.sh is very different and can't be used directly from Tcl and either requires shell or some parsing)
-e switch to write tiny script from oneliner has proven useful: its not always possible to do echo ... | perl for small programs, and its very handy to write perl -MConfig -we 'print $Config{usethreads}'
built-in debugger, console-based, which then could be extended to GUI debugger from CPAN
bigint/bigrat: a command perl -Mbigint -we 'print 2**10000' just works; in Tcl bignumbers arithmetics isn't in the core distribution, but (DKF: Planned for 8.5; KBK is working on it.)

From the other side, it is obvious that Perl lacks GUI in its source distribution.

Question: do the urls http://www.perldoc.com/perl5.8.6/pod/perlfunc.html

and http://www.perldoc.com/perl5.8.6/pod/perlmodlib.html

provide the full list of perl functionality out of the box?

Indeed, yes, this is a good approach to dig. Commands perldoc perlfunc and perldoc perlmodlib should provide same information. BTW keep in mind that mostly those modules in perlmodlib have relations to perl internals (not for users) and B::* and O::* considered not in shape for using those...

<> In Tcl edit

RS: If you want to bring some Perl brevity (and mystic) to Tcl, you can start from here:

proc <> {} {expr [uplevel 1 gets stdin _]+1}
proc print args {
    if {![llength $args]} {
        set fd stdout; set s $::_
    } elseif {[llength $args] == 1} {
        set fd stdout; set s [lindex $args 0]
    } else {
        set fd [lindex $args 0]
        set s [join [lrange $args 1 end]]
    }
    puts $fd $s
} ;# dkf
while {[<>]} {print}

dkf: Here's a version that gets a bit closer in some ways, though Perl fanatics would hate it.

proc print {{fd <stdout>} args} {
    if {[string match <*> $fd]} {
        set fd [string range $fd 1 end-1]
        if {![llength $args]} {
            set args [list $::_]
        }
    } else {
        set args [linsert $args 0 $fd]
        set fd stdout
    }
    puts $fd [join $args]
}

The real problem is that perl's filehandles are completely distinct from the strings it can output.

[CL wants to sharpen the expression of that last observation. He thinks it is something like this: Perl filehandles are distinguished syntactically, so it is feasible for the Perl parser to disambiguate different forms in which such a filehandle can appear (or be implicit).]

There's a bug in your code up there, in that <> uses uplevel 1 on the code that sets $_, while print just accesses the variable at the global scope. I'm not sure which is wrong, though.

RS: Truly global appears more perlish to me, so make that

proc <> {} {
    expr [gets stdin ::_]+1
}

The bug went unnoticed by sloppy testing, just one call stack level deep, where uplevel 1 happens to point to the global namespace...

glennj: If you really want a perl-like print, don't forget to use the -nonewline option to puts...

Perl chop in Tcl edit

RS saw perldoc -f chop: "chop Chops off the last character of a string and returns the character chopped. It is much more efficient than "s/.$//s". So here it is in Tcl (see K for more):

proc chop _s {
    upvar 1 $_s s
    K [string index $s end] [set s [string range $s 0 end-1]]
}
proc K {a b} {set a}

Testing:

% set try hello
hello
% chop try
o
% set try
hell

LV So, does this perform better than the regular expression or other techniques? Because its form is pretty obscure...

Version strings edit

RS 2006-07-03: Perl has a way of specifying strings (especially for version numbers) by decimal character values, separated by periods. Here's how to do that in Tcl:

proc vstring str {
    set res {} 
    foreach part [split $str .] {append res [format %c $part]}
    set res
}
% vstring 89.111.44.32.80.101.114.108.33
Yo, Perl!