[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

RE: [FWP] Delayed semantical interpretation



At 02:34 PM 9/22/99 -0400, WORENKLEIN, David, GCM wrote:
>Disclaimer: I never studied compiler theory
>
>Since my s///e was nixed, how about `` (backtick)?

But that has fixed semantics: returns a scalar or a list depending on 
context.  It cannot alter anything else in the program.

I came to this question after citing the perlfaq to someone who was asking 
for a BNF for Perl.  I know that the parsing of Perl is more compliated 
than a BNF can express; I got to wondering whether there were parts of it 
whose grammatical interpretation had to wait until run-time.

I guess (flaunting my ignorance further) that there must always exist a 
compile-time grammatical interpretation of everything, it's just that some 
parts may have been interpreted at a higher level of abstraction than 
others because some interpretation is delayed until run-time (again 
$a++).  I was wondering how far that went.

How do people who know what they're talking about describe what I just 
said? :-)

>-----Original Message-----
>From: Peter Scott [mailto:Peter@PSDT.com]
>
>Disclaimer: I hated compiler theory, so my question may be rife with
>inconsistencies...
>
>Sometimes the semantics of a statement cannot be determined until run
>time.  An example would be $a++, where you don't know whether it's going to
>
>do $a = $a + 1 or the magical string postincrement until you know the value
>
>of $a.  And of course there are polymorphic O-O methods and eval.
>
>What's the most egregious construct in Perl with respect to this
>behavior?  Only a few tokens at most; I'm talking about language elements
>here, not obfuscated programs.  Something which produces the widest range
>of possible behavior that can't be narrowed until run-time.  eval doesn't
>count :-)


--
Peter Scott
Pacific Systems Design Technologies


==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe