guile-user
[Top][All Lists]
Advanced

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

Re: patch: executable modules support with "guile -e ENTRYPOINT"


From: Marius Vollmer
Subject: Re: patch: executable modules support with "guile -e ENTRYPOINT"
Date: Mon, 06 Oct 2003 01:14:17 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Thien-Thi Nguyen <address@hidden> writes:

>    From: Marius Vollmer <address@hidden>
>    Date: Sun, 05 Oct 2003 17:49:47 +0200
>
>    I think that's a very good idea.  Indeed, I think it is so good that
>    we should not reserve it for the -e option and should instead find a
>    general syntax for writing non-local names.  Your proposed syntax
>    "MODULE-NAME PROC-NAME" does not work in Scheme code, but what about
>
> it's not necessary from scheme because the module system provides enough
> lower-level procs that the user can choose whatever syntax they want to
> look at, in scheme.  see, for example, module (ttn moduleutils) where
> `@' has been doing such a thing for a few years now.

That is not exactly the same since it does not allow the evaluator to
memoize the variable reference (or a future compiler to do fancy
optimizations).  When the user writes

    ;; be sure to use the builtin car and not our own version...
    (((@ guile) 'car) lst)

he/she might not be aware that this expression will perform the lookup
each time it is executed.  Also, we need a more primitive method
anyway for a real hygienic macro system (see my answer to Neil).

But my main point is that this syntax is different from the syntax
used by your "-e" option and that there is no way to use the "-e"
option syntax in Scheme.  We should use the same syntax in both and
then why not do it right?

> if you don't like how `@' behaves, or is named or is implemented, that's
> the point; you don't have to.  it's in "user space".

Changing '@' so that it does get memoized is possible but it would be
so low-level that we shouldn't expect users to do this themselves.  We
should offer an implementation in the core.  They can then still layer
some macros/whatever on top if they want a different interface.

Only for 1.7:

    (define-macro (:: mod var)
      (module-variable (resolve-module mod) var))

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




reply via email to

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