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

Update 'definition-text-surrogate to accept lists #244

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

LeifAndersen
Copy link
Member

Before a language's get-info function was expected to return a
module-path? (or #f) for 'definitions-text-surrogate. Now a list is also
acceptable, which can be used for meta-language's that combine their
surrogate with the base language they are extending.

Before a language's get-info function was expected to return a
module-path? (or #f) for 'definitions-text-surrogate. Now a list is also
acceptable, which can be used for meta-language's that combine their
surrogate with the base language they are extending.
@LeifAndersen
Copy link
Member Author

I've updated the docs. However I can't seem to find any existing tests for 'definitions-text-surrogate.

@LeifAndersen
Copy link
Member Author

Ugg...

Thinking about it a bit more, a list can be a module-path? (Like in the case of '(submod "." hello). And with this current design, its impossible to determine if that is supposed to be one module path, or 3. :(

@rfindler
Copy link
Member

rfindler commented Dec 3, 2018 via email

This is because a list can be a valid module path, which made the
(or/c #f module-path? (listof module-path?)) contract conflict with
itself. Now DrRacket defaults to getting a list, and falls back to a
single module-path? if none is provided.
@LeifAndersen
Copy link
Member Author

@rfindler Good idea. I've pushed that.

@LeifAndersen
Copy link
Member Author

Any other comments @rfindler ?

@rfindler
Copy link
Member

Is #f different than the empty list for definitions-text-surrogate-list?

The definition of mode on line module-language-tools.rkt seems unlikely to be correct as it might be a list and there is a send just below.

The docs would be clearer if they said explicitly what order the mixins are mixed in.

This seems unlikely to be correct:

If
 @language-info-ref[definitions-text-surrogate] returns
 @racket[#f] then DrRacket tries
 @racket['definitions-text-surrogate]

The comment "Will not work with the definitions text surrogate interposition that
#lang allows. Need to deprecate that one" at the top of insulated-read-language.rkt suggests that maybe this is an ill-considered change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants