Comments on:
Kelsey, R., Clinger, W., and Rees, J. (Eds). (1998).
Revised5 Report on the Algorithmic Language Scheme.
Section 7.1
Comments from:
Peter Brown,
Michael Claveria,
Davis Hart,
Alex Leach (*),
Brad Miller,
Angeline Namai,
Mark Nettling,
Dave Ventresca (late).
No Comments from:
Dimitar Tasev (x).
I was unable to make much sense of section 7 beyond what I already
understand Scheme's syntax, maybe its just my brain being fried right
now, but I feel like I should have been able to get more out of it,
but its not coming.
I think I understood most of 7.1.1 except for the number representations
(The @ sign in the def for <complex R> for example, was confusing) 7.1.3
was less clear to me, specifically the section on <derived expression>'s
I have no idea what the <macro block> at the end of section 7.1.3 is
talking about. I would also appreciate some guidance on section 7.1.4
Can you go over the scheme representation of complex numbers. The rest
of the reading was basically just a grammar of lefthand->righthand
rules for scheme and mostly fit to my understanding of the language.
I actually found this reading more enjoyable than I thought I might
because we are going over context-free languages right now in CSC
341. It's neat to see the theory put into practice in designing a
language. The sections on Quasiquotations was a little unclear to
me though. Where exactly do quasiquotations fit into the "scheme" of
things? The auxillary functions were a little dense, are they describing
functions syntatically/mathematically, essentially?
In the expression <number> -> <num 2> | <num 8> | <num 10> | <num 16>, what is the significance of the integers 2,8,10 and 16? I know that binary, octal, hexidecimal and decimal numerical notation is conventional, but why not have 4 or 32?
What is <ellipsis> -> <the identifier..> in section 7.1.5? What does any of those symbols on page 41 mean? My head hurts just looking at them. Could you go over one of those little sections so I could maybe understand a little.
The Scheme grammar looks similar to all of the other one grammar I have ever seen before - that one being for Rebelsky's STUPID language. I was surprised to see such informal rules like
<comment> -> ;<a; subsequent characters up to a line break>
which, while clear in their meaning, omit some of the formalism I expected to see in a grammar. I am also interested by the fact that the designers included a number of the built-in procedure names such as 'set!'. I expected to see control structures such as conditionals, but not procedures which do not have special format or significance, like 'set!'.
The reading was pretty straightforward. One thing I noticed is that it had real, unsigned real, and unsigned int, but there was no signed int. Is there a reason for this? Also, if sequence is just 0 or more instances of command followed by an expression, and command is just an expression, why isn't sequence just defined by expression*? Or command*? Does <statement>* just imply that the statements are the same, since <statement> could imply any of many different things?
Questions:
I don't really understand how the quasiquotation syntax works. I think I understand _what_ quasiquoting is but the syntax is confusing.
Why are there #'s in the numbers rules?
I am not sure what comments to give, especially since the section is
mainly about grammar rules. It's like trying to explain the reason behind
the structure of a spoken language such as English. I suppose Scheme's
syntax supports as many grammar rules as possible in order to provide a
solution to computable programming problems. However, even after reading
this section, I do not understand why we are required to take a course
in formal languages. Some claim that a grammar is useful for those who
are trying to learn the syntax of a language, but Grinnell CS majors
learn the syntax of three languages with no profound understanding of
grammars. Aside from linguists, theoreticians, and the designers of
compilers and interpreters, I wonder whether any programmers apply most
of what they have learnt from a course like CS341. Aren't there other
branches of computing that do not require a semester's-worth knowledge
of formal languages and grammars? I guess I am puzzled as to why CS341
is a core requirement for the major. Then again, I may not have clearly
understood the power of formal languages.
;
Check with Bobby