Re: Semi-OT: Good compiler book?
At 04:38 PM 8/8/2001 +, Brian J. Kifiak wrote: > > Unfortunately all the references I have for > > alternatives really require what the Dragon Book teaches as a > > foundation. > >What are the references? Since several people have asked already... There are two I've been using. I think they're on the book list, but in case they're not: Advanced Compiler Design & Implementation Steven S. Muchnick Morgan Kaufmann ISBN 1-55860-320-4 Building an Optimizing Compiler Robert Morgan Digital Press ISBN 1-8-179-X I like the first better--it's a more comfortable read. (If you can consider any of this stuff comfortable... :) It probably wouldn't hurt to drag out a book on Linear Algebra while you're at it, but I don't have a reference to one of those handy. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Semi-OT: Good compiler book?
On Tue, 7 Aug 2001 16:03:56 -0700, Brent Dax wrote: >I'm going on vacation soon, and I'd like to get a good book on writing >compilers--hopefully one that will help me when we actually start coding >Perl 6. Any suggestions? I have no formal education on compilers, and >I only know C, C++ and Perl (duh). Unless you get a kick out of mathematical proofs, you probably won't get too much out of the dragon book. It ain't very practical. I would look out for a book that gives a *practical* introduction to compiler design, i.e. one that builds a working compiler on the side. Although I've really only browsed in them, I think I'd rather look into "Crafting a Compiler" by C. Fisher and R. Leblanc, or "A retargetable C compiler", by D. Hanson and C. Fraser, which forms the basis for lcc (one shoot-off is lcc-win32, an excellent, freely available C compiler with IDE, for Win32). Both books get good reviews. -- Bart.
Re: Semi-OT: Good compiler book?
or, cheaper still, used: http://www.amazon.com/exec/obidos/ASIN/0201100886/ -asdlfjasfey On Tuesday, August 7, 2001, at 06:11 PM, Mark Koopman wrote: > > > >> The official title is: >> Compilers : Principles, Techniques, and Tools >>by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) >> ISBN: 0201100886 >> >> You can get it from Fatbrain: >> >> http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201100886&vm= >> > or cheaper at Bookpool > > http://www.bookpool.com/.x/6jipibmev1/sm/0201100886 > > -- -mark koopman > > WebSideStory 10182 Telesis Court > San Diego CA 92121 858-546-1182 ext 318 > > > -- -mark koopman > > WebSideStory 10182 Telesis Court > San Diego CA 92121 858-546-1182 ext 318 > > >
Re: properties, revisited
On Thu, Aug 09, 2001 at 03:37:42AM +1000, Damian Conway wrote: > Scott wrote: >> What happens to C within stand-alone C statements? Do >> C statements never stand alone? > > That's correct. I'd expect: > > die "Ungoverned 'when' statement (where's the 'given'???)" That's weird. I guess no more weird than "Can't "next" outside a loop block" or an ifless else error. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: properties, revisited
> My personal preference would be for all such properties (traits?) to be > reserved across all types - eg using 'prompt' on a hash gives a > compile/run time error. This allows the compiler to catch certain types > of typo and thinko, and also allows us to expand in future - eg when > some P6Per comes up with a bright idea on how prompts can be made > applicable to hashes, we dont have the familar argument "but we can't > do that, it may break code that defines a user property called > 'prompt'". I could imagine the same types of warnings on all-lowercase traits/properties as on lowercase barewords. That is: let them be, by convention, reserved for (future) built-ins. > PS - I *really* like the traits proposal. Me too :-) Damian
Re: properties, revisited
Scott wrote:
> Hmm. C seems to be synonymous with C (almost)
>
>when ($foo) { ... } # Does this mean if ($_ eq $foo)?
> if ($foo) { ... }
A C is an whose "other half" is specified by a surrounding C.
> However ...
>
> > A C within a C's block causes control to jump to the next
> > statement in the innermost surrounding 's block.
>
> What happens to C within stand-alone C statements? Do
> C statements never stand alone?
That's correct. I'd expect:
die "Ungoverned 'when' statement (where's the 'given'???)"
I think C and C are no more synonymous than C and C
and I doubt people will have much difficulty keeping them straight.
Damian
Re: properties, revisited
On Wed, Aug 08, 2001 at 08:25:57AM +1000, Damian Conway wrote:
>> More questions regarding the new 'given when' construct.
>> [ LABEL: ] given ( expr_1 ) {
>>[ when expr_2 : block ...]
>>expr_n [;]
>> }
>
> Not required. It's:
>
> [ LABEL: ] given ( expr_1 ) {
> [statement ; ...]
> [statement]
> }
>
> A C statement is just a particular kind of statement.
Hmm. C seems to be synonymous with C (almost)
when ($foo) { ... } # Does this mean if ($_ eq $foo)?
if ($foo) { ... }
However ...
> A C within a C's block causes control to jump to the next
> statement in the innermost surrounding 's block.
What happens to C within stand-alone C statements? Do
C statements never stand alone? And if C and C are
mostly synonymous, the differing behavious of C within them would
be confusing.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: new syntax idea: eval "..."o;
> On Tue, 7 Aug 2001 09:27:43 -0400, John Porter wrote:
>
> >David L. Nicol wrote:
> >> eval ${code}o;
> >
> >Another brilliant idea from David Nicol!
>
> Not really.
>
> What I would like is an option to just *compile* a piece of perl code,
> without executing it. This kinda works:
>
>$coderef = eval "sub { $code }";
>
> and currently (5.6.0) even if $code contains sub definitions; but it's
> still just a hack.
How about having an EVAL object-type ? (somewhat analogous to the
relationship between INT and int)
my $compiled=new EVAL($code);
$compiled.execute;
The constructor just compiles and the execute method just executes.
-- Marc --
Re: properties, revisited
Damian Conway <[EMAIL PROTECTED]> wrote: >> There are a number of properties "built into" Perl 6. Nearly all of these >> properties don't make sense across the board - eg, a scalar won't have a >> dimension, a hash won't prompt, etc. >> >> So given the two different sets that you must consider (variable versus >> value, and hash versus array versus scalar versus filehandle), are >> properties that are meaningless for some section usable by the user? > > I would expect so, but Larry's MMV. My personal preference would be for all such properties (traits?) to be reserved across all types - eg using 'prompt' on a hash gives a compile/run time error. This allows the compiler to catch certain types of typo and thinko, and also allows us to expand in future - eg when some P6Per comes up with a bright idea on how prompts can be made applicable to hashes, we dont have the familar argument "but we can't do that, it may break code that defines a user property called 'prompt'". PS - I *really* like the traits proposal.
