modules, 2nd try.

modules, 2nd try.

[Han-Wen Nienhuys]

After getting no response on the devel list, let me try once more,
over here. I want to move the input -identifier mechanism in LilyPond
over to Scheme. Currently, people can do


	%identifier = ... defines a variable 
	variableOne = 5.0
	\score {

	       ..music..

	       \paper  {
		       % The paper block introduces a new scope.

		       variableTwo = 5.0\cm

		       % \identifier references a variable.
		       linewidth = \variableOne * \variableTwo
	       }
	}
       % variableTwo not visible here.
	

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. In the
future, it should be possible to do

	%identifier = ... defines a variable
	variableOne = 5.0

	\score {

	       ..music..

	       \paper  {
		       variableTwo = 5.0\cm

		       %  #... introduces inline Scheme. 
		       linewidth = #(* variableOne variableTwo)
	       }
	}

In terms of code, I want to create sets of bindings. The sets should
be nested, and available to the Scheme evaluator.

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.

How do I go about this?

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Thien-Thi Nguyen]

   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

Re: modules, 2nd try.

[Han-Wen Nienhuys]

ttn@giblet.glug.org writes:
> 
> in the first frag, there is "% variableTwo not visible here." but not in
> the second frag.  could you clarify your intention?

Sorry. % is a comment; First assignment implies a definition, like
python does.

>    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?

Haven't thought of this, and I don't think I favor any choice over
another.  In our input language, I guess yes, but of course not in
pure Scheme.

>    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.

To my feeling, the way scopes work in Scheme is ok (where lambda
introduces an inner scope),

	(define variableOne 1.0)
	(define (foo x)
		(define variableTwo 5.0)
		(do-side-effect (* variableTwo variableOne))
		)


Within (foo .. ) you can define a new variable that is not visible
outside (foo ..), and variableOne (defined outside foo ), is visible
inside (foo ..)  Unfortunately, the Scheme evaluator needs to read the
entire expression before it can do the evaluation, I don't see how I
can combine that with the Yacc based parser in a simple way.

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Neil Jerram]

>>>>> "Han-Wen" == Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

    Han-Wen> After getting no response on the devel list, let me try once more,

OK, here's roughly how I think I'd do it ...

First you need a root module.

(define (next-module-name)
  ;; Procedure that generates unique module names
  ;; (lily m0), (lily m1), (lily m2), ...
  )
(define root-module (resolve-module (next-module-name)))
(beautify-user-module! root-module)

(define lily-current-module root-module)

    Han-Wen> 	%identifier = ... defines a variable 
    Han-Wen> 	variableOne = 5.0

(module-define! lily-current-module 'variableOne 5.0)
(module-export! lily-current-module 'variableOne)

    Han-Wen> 	\score {

Moving into a sub-scope, so ...

(define submodule (resolve-module (next-module-name)))
(beautify-user-module submodule)

(module-use! submodule (module-public-interface lily-current-module))

;; At this point you want to mark all the variables imported from
;; lily-current-module for re-export.  I'm not sure how you could do
;; this.  Perhaps something involving module-map or module-for-each.

(set! lily-current-module submodule)

    Han-Wen> 	       ..music..

    Han-Wen> 	       \paper  {

Another sub-scope, so same again.

    Han-Wen> 		       % The paper block introduces a new scope.

    Han-Wen> 		       variableTwo = 5.0\cm

(module-define! lily-current-module 'variableTwo 5.0)
(module-export! lily-current-module 'variableTwo)

    Han-Wen> 		       % \identifier references a variable.
    Han-Wen> 		       linewidth = \variableOne * \variableTwo

(module-define! lily-current-module 'linewidth (* variableOne variableTwo))
(module-export! lily-current-module 'linewidth)

    Han-Wen> 	       }

Ah :-) For exiting scopes, you should restore the previous
lily-current-module; so you'll need to keep a stack of
lily-current-modules.

As usual, I haven't actually tested any of this (!)  If you want to
see working examples of manual module munging code (although with
different aims from yours, kind of), look at `use-elisp-file' in
lang/elisp/interface.scm and `fset' in lang/elisp/internals/fset.scm,
both in CVS.

Hoping this helps ...

        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Han-Wen Nienhuys]

neil@ossau.uklinux.net writes:
> [..]

Thanks, I more or less came up with something alike yesterday evening
-- one of the other problems was that I didn't do scm_c_export() of
the symbols, which drove me up the walls ( "why isn't it seeing my
definitions...? ")

>     Han-Wen> 	\score {
> 
> Moving into a sub-scope, so ...
> 
> (define submodule (resolve-module (next-module-name)))
> (beautify-user-module submodule)
> 
> (module-use! submodule (module-public-interface lily-current-module))
> 
> ;; At this point you want to mark all the variables imported from
> ;; lily-current-module for re-export.  I'm not sure how you could do
> ;; this.  Perhaps something involving module-map or module-for-each.

Ah, of course, I could batch these exports. 

> lily-current-module; so you'll need to keep a stack of
> lily-current-modules.
> 
> As usual, I haven't actually tested any of this (!)  If you want to
> see working examples of manual module munging code (although with
> different aims from yours, kind of), look at `use-elisp-file' in
> lang/elisp/interface.scm and `fset' in lang/elisp/internals/fset.scm,
> both in CVS.
> 
> Hoping this helps ...

Yes, thanks. Most of the code involved is triggered from the C part of
the code, but I noticed that most of the module system actually lives
in the SCM system, so perhaps it doesn't make much of a difference?

I think you left out the part where the new scope imports the old
(nested) scopes, i.e. 

	void
	My_lily_lexer::add_scope (SCM module)
	{
	  scm_set_current_module (module);
	  for (SCM s = scopes_; gh_pair_p (s); s = gh_cdr (s))
	    {
	      SCM expr = scm_list_n (ly_symbol2scm ("module-use!"),
				     module, scm_list_n (ly_symbol2scm ("module-public-i
	nterface"),
							 gh_car (s), SCM_UNDEFINED),
				     SCM_UNDEFINED);

	      scm_primitive_eval(expr);
	    }

	  scopes_ = scm_cons (module, scopes_);


Does your suggestion to use modules mean that there is no other
natural way to implement these nested scopes?

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Neil Jerram]

>>>>> "Han-Wen" == Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

    Han-Wen> neil@ossau.uklinux.net writes:
    >> 
    >> ;; At this point you want to mark all the variables imported from
    >> ;; lily-current-module for re-export.  I'm not sure how you could do
    >> ;; this.  Perhaps something involving module-map or module-for-each.

    Han-Wen> Ah, of course, I could batch these exports. 

    [...]

    Han-Wen> I think you left out the part where the new scope imports the old
    Han-Wen> (nested) scopes, i.e. [...]

Well, if you do the re-exporting step described in the ;; section just
above, you should only need to import the immediate parent module.
But importing all the ancestor modules is a good alternative to the
re-exporting step, in fact probably nicer.

    Han-Wen> Does your suggestion to use modules mean that there is no other
    Han-Wen> natural way to implement these nested scopes?

Hmm... one to think about.  How would you change the module system
such that there was an easier way to get this behaviour?  Perhaps
there should be something like module-all-interface, like
module-public-interface but giving you all variables; we could then
dispense with all the exporting and re-exporting, and the resulting
system would be quite natural.

One caveat that just occurred to me: with either variant (yours or
mine) of this design, I'm not sure that a variable in an inner scope
will correctly shadow a variable with the same name in an outer
scope.  In your design, it depends on how the module system resolves
conflicts between multiple imports.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Han-Wen Nienhuys]

neil@ossau.uklinux.net writes:
> One caveat that just occurred to me: with either variant (yours or
> mine) of this design, I'm not sure that a variable in an inner scope
> will correctly shadow a variable with the same name in an outer
> scope.  In your design, it depends on how the module system resolves
> conflicts between multiple imports.

but variables in the current module always  get precedence, right?


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: modules, 2nd try.

[Neil Jerram]

>>>>> "Han-Wen" == Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

    Han-Wen> neil@ossau.uklinux.net writes:
    >> One caveat that just occurred to me: with either variant (yours or
    >> mine) of this design, I'm not sure that a variable in an inner scope
    >> will correctly shadow a variable with the same name in an outer
    >> scope.  In your design, it depends on how the module system resolves
    >> conflicts between multiple imports.

    Han-Wen> but variables in the current module always  get precedence, right?

Yes, I believe so.

        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user