Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.alt.net!news.kjsl.com!usenet.stanford.edu!news.iecc.com!nerds-end From: "[Linux Magazine]" Newsgroups: comp.compilers Subject: Re: How to handle qualified identifiers such as x.y in a Pascal-like language Date: Fri, 24 Jun 2011 13:58:23 +0200 Organization: Compilers Central Lines: 32 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-06-044@comp.compilers> References: <11-06-037@comp.compilers> <11-06-040@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1308963620 51984 64.57.183.58 (25 Jun 2011 01:00:20 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 25 Jun 2011 01:00:20 +0000 (UTC) Keywords: symbols, storage Posted-Date: 24 Jun 2011 21:00:20 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:170 A follow up to the discussion on displays and linked list of stack frames. Many languages allow for storing references to procedures in variables, or passing procedures as parameters. One example is the GNU variant of C and C++ implemented in GCC, which allows for both AND nested procedures. If thread starters language include storing references to procedures and/or passing procedures as parameters, then thread starter needs to consider, how to store references to procedures, and he better consider it now. When using linked lists of stack frames, the normal way of storing references to procedures is to store a reference to the start of the code implementing the procedure and a reference to the start of the linked list of stack frames. Thus you have a record with two fields. When using displays you have the problem of storing the display somewhere. In some cases GCC uses something like trapezes for storing references to procedures without having a record with two fields. Unfortunately that involves storing code in writable storage, and that is a big no no for security reasons. Storing code in writable storage makes life so much easier for hackers. In practice people do not write procedures in procedures that much, and procedures in procedures in procedures are rare. This also means that you need efficient access to global variables and variables local to the procedure currently being executed. Further the access to variables declared in the directly surrounding scope should be fairly efficient. The rest just needs to work. You will do fine with an implementation where all procedures have direct access to its own variables and global variables, and variables declared in surrounding procedures may be more difficult to access.