Re: [MacPerl] what's it look like under the hood?

[bart.lateur@skynet.be (Bart Lateur)]

On Sat, 20 Nov 99 22:58:58 +0900, Joel Rees wrote:

>Okay, I am required by my job to learn Perl so I can teach it. I am 
>considering learning it for my personal use. I want to know what 
>advantages it has over my two favorite languages, FORTH and C.

>First, would anyone dare implement Perl in Perl? 

The questions asked clearly indicate that you have a FORTH background.

IMO: no you wouldn't. Nobody in his right mind would try to rewrite such
an immensely complex beast just for the heck of it.

Perl couldn't be written in C without the help of tools such a Lex and
Yacc, or is it Flex and Bison. But that's not enough. Perl does NOT have
a context free grammar. It took quite a few very talented computer
persons to tweak the Perl interpreter into what it is today.

It is not because Perl isn't powerful enough to use to build compilers.
I think that it's better suited than C. C would be just a terrible
language to write compilers in without the help of compiler writer
tools. BTW for Perl those tools are not enough.

>This is an archaic bragging issue that turns out to have been irrelevant, 
>but I hope to get an idea of how well Perl supports parsing complex 
>grammars. It looks great for parsing e-mail generated by html forms, but 
>that's pretty straightforward stuff.

It is straightforward in Perl. It isn't in C.

I once have built a macro processing and expansion parser in Perl. The
complete source code was less than 15k.

>Second, does Perl optimize? How well? Can it reduce constant expressions?

Dunno. Don't care. Perl is fast enough for what I like. I can use it to
massage data from multiple tables with complex, conditional relations
(sometimes there's relevant data for an item in one table, but if there
isn't, then you may have to use this other table...), into a report,
text format, ready to publish a 1200 pages catalog, all in under 1/2
minute. That is 40 pages per second. Fast enough for me.

>Third, does Perl have multiple internal stacks, specifically splitting 
>the control data (return addresses) from the parameter data? (I am one of 
>those kinds of programmers with a bad habit of walking on my return 
>addresses in C.)

Not a clue. You may experiment with the built-in debugger, if you like.
the debugger is largely written in Perl, BTW.

>Fourth, what does the Perl symbol table look like? Hash table? Is nesting 
>achieved by naming games?

A hash. The common name is "stash", short for "symbol table hash".

You can even access them directly, *in Perl*. The names end with "::",
and the values are typeglobs, which are a "record" contains slots for
each and every data type available, like scalars, arrays, hashes,
filehandles, subroutines, formats, ... Try this:

	$foo = 123.456;
	@bar = qw(a b c);
	foreach (sort keys %main::) {
		local *alias = $main::{$_};
		my $string = defined $alias? "'$alias'":'undef';
        my @ary = @alias;
		print "\$$_ = $string, \@$_ = (@ary)\n";
	}

Don't be surprised by the large amount of output. But $foo and @bar are
in there.

If you're into this kind of tricks, I can only advise you to check out
the "Advanced Perl Programming" book, aka the Panther. 

Caveat: Lexical variables, those declared with "my", escape this
mechanism altogether. But that doesn't mean that if you are trying to
write a real parser/compiler/macro tool in Perl, that hashes are the
best thing that could happen to you.

All the questions together suggest to me that the Panther book might
just be up your alley.

p.s. This should really have dgone to one of the other mailing lists,
MacPerl-AnyPerl. It's not a Mac related question, after all.

I think it's a pity that the other lists are so little used compared to
the main one. What's that Linux thread doing on the main list anyway?

-- 
	Bart.

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org