guile-user
[Top][All Lists]
Advanced

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

Re: modules, 2nd try.


From: Thien-Thi Nguyen
Subject: Re: modules, 2nd try.
Date: Wed, 18 Sep 2002 11:56:49 -0700

   From: Han-Wen Nienhuys <address@hidden>
   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




reply via email to

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