Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unparser should take context into account. #8

Open
akeep opened this issue Apr 30, 2016 · 0 comments
Open

unparser should take context into account. #8

akeep opened this issue Apr 30, 2016 · 0 comments
Assignees
Labels

Comments

@akeep
Copy link
Member

akeep commented Apr 30, 2016

Right now the unparser simply recurs to the top-level unparser on sub-parts. This means that if more than one terminal has the same domain, e.g., if we use symbols to represent both variables and constant symbols, differentiated by context, we will see all of them printed out the same way, even if the language specifies different unparsers for these two terminals.

One caveat to note with this is that if the unparser is called directly on one of these terminals, there is no way to determine which one it is (since the only way it can differentiate these things is using the terminal predicate, and two predicates will return true for the same actual terminal.)

Originally reported by @soegaard on nanopass framework google group with the following test program (in Racket):

#lang racket
(require nanopass/base)

(define id?              identifier?)
(define (unparse-id id)  (list 'id (syntax-e id)))

(define property?            identifier?)
(define (unparse-property p) (list 'prop (syntax-e p)))

(define-language L
  (entry Foo)
  (terminals ((id       (x)) . => . unparse-id)
             ((property (p)) . => . unparse-property))
  (Foo (f)
    (foo x p)))

(unparse-L
 (with-output-language (L Foo)
   `(foo ,#'a ,#'b)))
@akeep akeep self-assigned this Apr 30, 2016
@akeep akeep added the bug label Apr 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant