Re: Are library names data or syntax?

[Marc Nieper-Wißkirchen]

Am Mo., 22. Juli 2024 um 20:47 Uhr schrieb Maxime Devos <maximedevos@telenet.be>:

> [...]

> 

>In what kind of situation might a library name be made up of identifiers (syntax objects) that might need to carry lexical information?

 

As implied by the previous: never (in Guile, and probably most others).

 

The only exception I can think of, is if:

 

* ‘define-library’/’library’ is implemented as a macro (this is not part of RnRS, but AFAIK neither is it against the standard)

* hence, you can define a module from within another module (might be situationally useful, but comes with new difficulties for module lookup)

* there are multiple module namespaces

* to determine which module namespace to put the module in, ‘define-library’ uses lexical information

* in particular, it uses components of the name of the library for lexical information, even though there are other options like using the _whole_ name (i.e., (foo bar) itself instead of ‘foo’ or ‘bar’).

 

That’s a lot of ifs, and even then identifiers aren’t necessary, since (AFAIK) the name (foo bar) itself carries lexical information (not sure).

 

I’ve been assuming that numbers (in syntax) (say, #'3) don’t carry lexical info, but since ‘syntax numbers’ carry file name+position information, it’s not much of a stretch to potentially also include lexical information, so perhaps numbers would work just fine too! (Implementation-dependent, but ‘multiple module namespaces’ and ‘define-library as a macro’ are also implementation-dependent.)

This would need a redefinition of what a syntax object is (see the R6RS). In principle, this would be possible, but the result would be incompatible with the R6RS. In R6RS, a macro transformer is allowed to output raw numbers; this would not be allowed in a hypothetical Scheme version that assumes that numbers necessarily carry a wrap (as identifiers do in the R6RS).

Source location information is not mandatory information for the expander, so this reasoning does not apply here.

Marc