nanopass doesn't (accept|work with) syntax objects

[dented42]

Syntax objects in Racket have lots of lovely properties, it would be nice at some point for nanopass to be able to parse syntax objects.

Another goal that seems like a nice thing to have would be to have passes themselves be able to preserve the syntax scope and location information that syntax objects use throughout compilation. This would let the final compiled result be a syntax object that knows it's history.

I'm unsure how out-of-scope such a goal is with regards to the current road map. It does, however, seem to me like the following should, at some point in the future, work.

#lang nanopass

(define (nat-zero? x)
  (eq? x 'Z))

(define-language nats
  (terminals
   [nat-zero (Z)])
  (Nat (nat)
       Z
       (S nat)))

(define-parser parse-nats nats)

(parse-nats 'Z)
(parse-nats '(S (S Z)))

(parse-nats #'Z)
(parse-nats #'(S (S Z)))

[soegaard]

Here is an example of parsing a syntax-object using nanopass. https://github.com/soegaard/urlang/blob/master/compiler-rjs/compiler.rkt#L328 /Jens Axel 2017-10-25 22:51 GMT+02:00 dented42 <[email protected]>:

…

Syntax objects in Racket have lots of lovely properties, it would be nice at some point for nanopass to be able to parse syntax objects. Another goal that seems like a nice thing to have would be to have passes themselves be able to preserve the syntax scope and location information that syntax objects use throughout compilation. This would let the final compiled result be a syntax object that knows it's history. I'm unsure how out-of-scope such a goal is with regards to the current road map. It does, however, seem to me like the following should, at some point in the future, work. #lang nanopass (define (nat-zero? x) (eq? x 'Z)) (define-language nats (terminals [nat-zero (Z)]) (Nat (nat) Z (S nat))) (define-parser parse-nats nats) (parse-nats 'Z) (parse-nats '(S (S Z))) (parse-nats #'Z) (parse-nats #'(S (S Z))) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcLxSKHVP4ryRS1janHhjeRNUQfBSRPks5sv59MgaJpZM4QGpE3> .

-- -- Jens Axel Søgaard

[dented42]

Does the take into account and preserve source location information? I can't quite tell from reading it.

[soegaard]

Yes it does.

Consider how variables are represented:

 Representation of variables during compilation.

(struct variable (id) #:transparent)

(define (unparse-variable x)
  (syntax->datum (variable-id x)))

The id held by a variable struct is a syntax object representing a symbol.
In order to get nice printout, we need to use a "prettifier" in the language specification.

This looks like:

(define-language LFE    ; FE = Fully Expanded
  (entry TopLevelForm)
  (terminals
   ((variable    (x xd)) . => . unparse-variable)
   etc