[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fundamental design issues (long message)
- To: srfi-83@xxxxxxxxxxxxxxxxx
- Subject: Re: fundamental design issues (long message)
- From: Jim Blandy <jimb@xxxxxxxxxxxx>
- Date: Mon, 12 Dec 2005 00:15:28 -0800
- Delivered-to: srfi-83@xxxxxxxxxxxxxxxxx
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cP0EAHKqsmMnWzI5fmqUWtEXNCnso8MukYXQNr1qOILsuvDfm9p0fvtptP6YeHudvXCn7RD2UJTqtC8APTJFljWnSE3ArNxCvojpY7Ke4YsO2ZYEAbtk2XrY8yNJlcOOxlryKJC5o8xnUMhM5+myIkT2orqs8BifZNfzEON3Hxg=
- Sender: jimblandy@xxxxxxxxx
Bear wrote:
> I want to be sure that a module system for scheme should
> be *at least* that useful in resolving dependencies and
> supporting separated compilation.
When some library A is compiled, the compiler could include all sorts
of interesting annotations about the exported identifiers in the
compiled form. Then, when compiling a library B that imports A, the
compiler must visit A, and thus gets a chance to pick up that groovy
information.
In other words, the fact that libraries may export macros requires a
tight enough binding between one compilation and the next that the
compiler can also silently pass whatever static information it likes
about a library's exports to libraries that import it.
(I think. It's late.)