drracket icon indicating copy to clipboard operation
drracket copied to clipboard

Update 'definition-text-surrogate to accept lists

Open LeifAndersen opened this issue 7 years ago • 6 comments

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 avatar Dec 03 '18 20:12 LeifAndersen

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

LeifAndersen avatar Dec 03 '18 20:12 LeifAndersen

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. :(

LeifAndersen avatar Dec 03 '18 21:12 LeifAndersen

Make a new key that drr will prefer that is always a list.

rfindler avatar Dec 03 '18 21:12 rfindler

@rfindler Good idea. I've pushed that.

LeifAndersen avatar Dec 04 '18 18:12 LeifAndersen

Any other comments @rfindler ?

LeifAndersen avatar Dec 11 '18 20:12 LeifAndersen

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.

rfindler avatar Dec 11 '18 21:12 rfindler