Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #3762 > unrolled thread
| Started by | Christopher F Clark <christopher.f.clark@compiler-resources.com> |
|---|---|
| First post | 2026-09-07 23:26 +0300 |
| Last post | 2026-09-08 09:14 +0000 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.compilers
Re: A tiny self-hosting compiler used for teaching Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2026-09-07 23:26 +0300
Re: A tiny self-hosting compiler used for teaching ram@zedat.fu-berlin.de - 2026-09-08 09:14 +0000
| From | Christopher F Clark <christopher.f.clark@compiler-resources.com> |
|---|---|
| Date | 2026-09-07 23:26 +0300 |
| Subject | Re: A tiny self-hosting compiler used for teaching |
| Message-ID | <26-09-010@comp.compilers> |
While I agree with our esteemed moderator's point about aesthetics, it is worth noting that Wirth intentionally made Pascal easy to parse. Thus, the Pascal declaration notation was designed to be parsed with a one pass compiler. Thus, arguing that the syntax is easy to read and understand has some objective support. However, it is worth noting that picking up C declaration syntax is for the most part also simple and intuitive if one ignores pointers to functions where we have both a prefix and a suffix operator that need to be disambiguated as to their precedence. But C's notation does have the nice aspect that declaration syntax matches usage. And, one can get both, although it looks a bit tortured to my eyes, but it might just be that I'm not used to it, yet You follow C's convention, but put the result type where the variable goes in usage and then string the operators around it. Moreover, If all the operators are suffix operators, there is also no ambiguity over precedence.. a: int->[10] // a pointer an array of 10 ints b: int [10] -> // an array of 10 pointers to ints ****************************************************************************** Chris Clark email: christopher.f.clark@compiler-resources.com 18 Meadow Rd Web Site: http://world.std.com/~compres Bolton, MA 01740 USA voice: (508) 435-5016 ------------------------------------------------------------------------------
[toc] | [next] | [standalone]
| From | ram@zedat.fu-berlin.de |
|---|---|
| Date | 2026-09-08 09:14 +0000 |
| Message-ID | <26-09-012@comp.compilers> |
| In reply to | #3762 |
Christopher F Clark <christopher.f.clark@compiler-resources.com> wrote or quoted: >While I agree with our esteemed moderator's point about aesthetics, it >is worth noting that Wirth intentionally made Pascal easy to parse. >Thus, the Pascal declaration notation was designed to be parsed with a >one pass compiler. Wirth famously created another language that is even easier to parse, viz. "PL/0" for his 1976 book "Compilerbau", which then became "Oberon-0" for his 1996 book "Compiler Construction". > C's notation does >have the nice aspect that declaration syntax matches usage. For readers who might not know those rules: | Parsing C Declarations | | To parse any C declaration by hand, follow the "Clockwise/Spiral Rule" | (or Right-Left Rule). Always start at the identifier and move outward | using this strict operator precedence: | | Precedence Rules | | 1. Groupings: Parentheses ( . . . ) surrounding a modifier | | 2. Post-fix operators (Right): Array subscripts [] and function | parameters () | | 3. Pre-fix operators (Left): Pointer stars * | | Step-by-Step Algorithm | | 1. Locate the identifier (the variable or function name). Say: "__ is | a . . . ". When parsing an abstract declarator (e.g., inside a | cast like "(int (*)[10])" or sizeof), find the location where the | identifier would normally be placed. | | 2. Look to the right of the current position. | | - If [], say: "array of . . . " and move past it. | | - If (), say: "function returning . . . " and move past it. | | 3. Look to the left of the current position. | | - If *, say: "pointer to . . . " and move past it. | | - If a type qualifier (const, volatile), apply it to the element | to the left. | | 4. Encountering Parentheses: If you hit a closing parenthesis ) on | the right, you must consume all modifiers to the left until you | hit the matching opening parenthesis (. Then, step outside the | parentheses and repeat from Step 2. | | 5. Final Base Type: When the identifier and all modifiers are | consumed, read the leftmost base type (e.g., int, char). | | Quick Reference Table | | Operator Reading Direction Meaning | ---------- ------------------- ------------------------ | name Start here "name is a . . . " | [N] Right " . . . array of N . . . " | () Right " . . . function returning . . . " | * Left " . . . pointer to . . . " | const Left " . . . constant . . . " Lines marked with "| " come from my editing, where I start by writing prompts for the chatbot and then edit the generated texts and format them for Usenet. The chatbots might make mistakes and misrepresent or invent facts. For example, in "(int const *(*(*)( ))[ ])", we insert the "virtual identifier" "_" to get "(int const *(*(*_)())[ ])". So we now have "pointer to" and what remains is "(int const *(*_())[ ])"; this gives "function returning a pointer to", and "(int const *_[ ])" gives "array of pointers to constant ints". So it's, "pointer to function returning a pointer to an array of pointers to constant ints". From: ram@zedat.fu-berlin.de (Stefan Ram)
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compilers
csiph-web