[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Marius Vollmer
Subject: Re: New syntax: (: MODULE-NAME VARIABLE-NAME)
Date: Sat, 15 Nov 2003 16:10:31 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Mikael Djurfeldt <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
>> what about making the changes below?  The only unclean thing is that
>> we would need to change the interpretation of a single ':'.
> But isn't that pretty darn unclean?  It changes the lexical structure
> of the language.

Hmm, yes and no.  With the change, ':' remains a variable identifier
and the new syntax is actually a macro:

    (define-macro (: mod-name var-name)
      (let ((var (module-variable (resolve-interface mod-name) var-name)))
        (if (not var)
            (error "no such public variable" (list ': mod-name var-name)))

That part is clean, I think, and doesn't change the lexical structure.
It only depends on an implementational detail and does something
officially that you can't do in Standard Scheme.  However, Standard
Scheme doesn't have a module system either, and from that point of
view 'use-modules' etc already has changed the lexical structure

> Note that we currently have an option which controls
> whether the reader conforms to R5RS ("Extended alphabetic characters
> may be used within identifiers as if they were letters.") or whether
> colon is marking a keyword, and that this option is defaulted to R5RS.

The reader is unchanged in the R5RS mode, only the non-R5RS mode now
treats an isolated colon differently:

    ;; R5RS
    guile> (symbol? ':)
    guile> (keyword? '#:)

    ;; non-R5RS with the change
    guile> (read-set! keywords 'prefix)
    guile> (symbol? ':)
    guile> (keyword? '#:)

    ;; non-R5RS without the change
    guile> (read-set! keywords 'prefix)
    guile> (symbol? ':)
    guile> (keyword? ':)

> I vote for using some syntax which is compatible with R5RS and would
> urge you strongly to at least keep the possibility to be compatible
> (=> new option controlling the interpretation of colon).

Given that the syntax is compatible, do you think we still need an
option for making (keyword ':) true again?

Here are the ChangeLog entries for the actual changes:

2003-10-24  Marius Vollmer  <address@hidden>

        * read.c (scm_lreadr): Treat a single ':' always a symbol,
        never as an empty keyword.

2003-10-23  Marius Vollmer  <address@hidden>

        * eval.c (scm_m_generalized_set_x): Macroexpand the target when it
        is a list.  This allows (: ...) to work with set!.

        * script.c (scm_compile_shell_switches): Use scm_c_read_string for
        the "-e" option instead of scm_str2symbol.  This allows things
        like (: ...) to be specified for the entry point.

GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

reply via email to

[Prev in Thread] Current Thread [Next in Thread]