guile-devel
[Top][All Lists]
Advanced

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

Re: Recursive namespace


From: Keisuke Nishida
Subject: Re: Recursive namespace
Date: Tue, 24 Apr 2001 18:41:58 -0400
User-agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.102 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 24 Apr 2001 10:07:53 -0500,
Rob Browning wrote:
> 
> I'm still not sure what the notation your're describing is intended
> for.  Is it to be used in the intermediate language for the VM, or is
> it intended for use in normal guile code?  If the former, then why is
> any syntactic sugar needed at all?  What's wrong with something more
> explicit as others have suggested (note that without knowing the
> context this code is probably meaningless...):

I meant the latter.  The intermediate representation is like
(@ Foo bar), or #<ghil-var #<ghil-mod Foo> bar>, and there is
no need for a syntactic sugar at all as you says.  Sorry for
not being explicit.

Although I don't need any syntactic sugar at the intermediate
level, I still need an explicit concept of modules and variables.
The module system I am thinking of right now differs from the
current module system in the sense that global variables are
identified at compile time, not at loading time as being done now.

In the current module system, modules are responsible for finding
variables by means of eval closures, etc.  Global variables are
looked up in the current module at the time of loading.  I think
the compiler should identify variables instead.  In order to
support the current system, I represents all global variables as
(@ #f bar) and delays variable identification until loading time.
The compiler is certainly able to do a better job once we have
a module system that provides static interface.  I think this is
the worst lack in the current system.



reply via email to

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