From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: guile-user@gnu.org
Subject: Re: modules, 2nd try.
Date: Wed, 18 Sep 2002 11:56:49 -0700 [thread overview]
Message-ID: <E17rk0H-00027M-00@giblet> (raw)
In-Reply-To: <15751.43551.895093.230090@blauw.xs4all.nl> (message from Han-Wen Nienhuys on Wed, 18 Sep 2002 00:18:07 +0200)
From: Han-Wen Nienhuys <hanwen@cs.uu.nl>
Date: Wed, 18 Sep 2002 00:18:07 +0200
I want to move this to Scheme to get more flexibility, without having
to bother with programming language design: identifiers should become
Scheme variables, and should be available in Scheme functions.
well it seems to me programming language design is unavoidable and is in
fact exactly what we're doing! (that's not a bad thing per se.) that
is, when the change in question is modifying the processing style from
"specialized eval" (global var lookup and interpolation) to or towards
"general eval" (inline Scheme), there's no way of side-stepping the
requirement of precisely defining how the non-Scheme parts and the
Scheme parts should interact.
[first frag showing status quo]
In the future, it should be possible to do
%identifier = ... defines a variable
below you introduce `variableTwo'. will that be required to be included
in the %identifier line? the answer to this gives us a hint on how to
implement the scoping behavior you describe.
variableOne = 5.0
\score {
..music..
\paper {
variableTwo = 5.0\cm
% #... introduces inline Scheme.
linewidth = #(* variableOne variableTwo)
}
}
in the first frag, there is "% variableTwo not visible here." but not in
the second frag. could you clarify your intention?
In terms of code, I want to create sets of bindings. The sets should
be nested, and available to the Scheme evaluator.
should inner bindings shadow outer bindings?
How do I do this? I tried mucking about with modules, but I can't
even get the basic functionality working, and they seem a bad match
with my wishes, since definitions in modules are private by default,
and the name spaces are not nested.
probably if we can refine your wishes to more precise specification, an
approach will suggest itself.
thi
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2002-09-18 18:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-17 22:18 modules, 2nd try Han-Wen Nienhuys
2002-09-18 18:56 ` Thien-Thi Nguyen [this message]
2002-09-18 19:19 ` Han-Wen Nienhuys
2002-09-19 21:14 ` Neil Jerram
2002-09-20 9:25 ` Han-Wen Nienhuys
2002-09-20 18:42 ` Neil Jerram
2002-09-21 11:15 ` Han-Wen Nienhuys
2002-09-21 11:22 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E17rk0H-00027M-00@giblet \
--to=ttn@giblet.glug.org \
--cc=guile-user@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).