[plt-scheme] match-lambda and syntax objects

From: Ryan Culpepper (ryanc at ccs.neu.edu)
Date: Tue May 29 15:50:07 EDT 2007

On May 29, 2007, at 3:15 PM, Richard Cobbe wrote:

> On Tue, May 29, 2007 at 02:05:34PM -0400, Ryan Culpepper wrote:
>>  On May 29, 2007, at 1:06 PM, Sridhar Ratna wrote:
>>
>>> I am reading sexps from a file and parsing them using `match.ss'..
>>> something like this:
>
> <SNIP>
>
>>> Now that instead of READ I will have to use READ-SYNTAX which 
>>> returns a
>>> SYNTAX object.
>
> <SNIP>
>
>> It would be difficult to use 'match' gracefully to destructure syntax
>> objects.
>
> Oh, there are ways:   <grin>
>
>     Welcome to MzScheme v369.10 [3m], Copyright (c) 2004-2007 PLT 
> Scheme Inc.
>> (require (planet "views.ss" ("cobbe" "views.plt" 1 1)))
>> (require (lib "match.ss"))
>> (define-view Stx syntax? (syntax-object->datum))
>> (match #'(+ 3 4)
>         [(Stx ('+ x y)) (+ x y)])
>     7
>
> I don't think this approach has any real advantages over syntax-case*,
> though, and Ryan will undoubtedly point out some obscure little corner 
> of
> the syntax system that I've overlooked that means this will fail 
> horribly
> in certain cases.  (There's always at least one such weirdness, and 
> usually
> several.)

(As predicted:)

The problem with the approach above is that it strips out all of the 
source location information from subexpressions. So when you recur, you 
won't have line numbers available. In fact, you won't have a syntax 
object at all. If your syntax representation is very regular, you could 
imagine only doing limited unwrapping (something closer to 
'syntax->list' than 'syntax-object->datum'), but that seems like more 
work overall.

Ryan

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme



Posted on the users mailing list.