[plt-scheme] Student parsing problem
On Jun 3, 2009, at 10:52 AM, Eli Barzilay wrote:
> On Jun 3, Anthony Cowley wrote:
>> On Wed, Jun 3, 2009 at 1:14 PM, Eli Barzilay<eli at barzilay.org> wrote:
>>> On Jun 3, John Clements wrote:
>>>>
>>>> On Jun 3, 2009, at 8:40 AM, Eli Barzilay wrote:
>>>>> and it works with multiple expressions too:
>>>>>
>>>>> (define (foo x)
>>>>> ;#;#;
>>>>> (printf "foo\n")
>>>>> (printf " x = ~s\n" x)
>>>>> ...)
>>>>
>>>> This is the most frightening idea I've heard today.
>>>
>>> I *seriously* don't see what would be frightening about it.
>>
>> FWIW, I reflexively looked away from the screen in horror when I saw
>> that, too. In my case, at least, it's not simply the leading
>> semicolon, but an unfamiliarity with using #; in such a manner. My
>> reaction to the ;#;#; combination is a wooks-ian aversion to opaque
>> notation whose far-reaching semantics are not immediately obvious,
>> "Oh, this is a commented out notation that, if uncommented, would
>> comment out the next two (count 'em!) S-expressions!"
>
> There are two concepts here: the use of `;' as a line comment, which
> is nothing new, and stacking `#;'s, which seems to be more, uh,
> "radical" -- to my surprise. So, ignoring `;' for now, what I'm
> saying is that stacking `#;' makes sense if you look at it in this
> light:
>
> 1. We want a convenient way to comment the next sexpr, even when not
> in an expression position.
>
> 2. Solution: `#;' does that.
I think the basic fear arises from the fact that #; textually breaks
the tree structure of the language. Put differently, imagine that
(zap) is an expression which comments out the following expression.
What would
(zap) (zap) (my-long-sexp ...) (my-next-long-sexp)
mean? Would the first zap zap the zap, or would it instead zap the
second sexpression?
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2484 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20090603/2e2a5cff/attachment.p7s>