[R6RS] Re: strawman module syntax
Sat Jul 10 06:44:35 EDT 2004
>>>>> "Matthew" == Matthew Flatt <mflatt at cs.utah.edu> writes:
Matthew> At Fri, 09 Jul 2004 17:59:19 +0200, Michael Sperber wrote:
>> Yes, but I'm not trying to solve the component problem here. In the
>> same sense as ld, MzScheme modules aren't good enough to solve the
>> component problem---in fact, they're worse because they tie each
>> import to a specific implementation, which I can't really replace
>> within the framework.
Matthew> MzScheme modules are also very bad at solving the "object"
Matthew> problem, the "procedure" problem, or the "number"
Matthew> problem. They are not intended to address any of those.
Matthew> You're not suggesting that every library needs a different script to
Matthew> load it into different implementations, right?
While, like you, I would like the "script" to be the same, I don't
think this is very realistic. There's just too much variety in the
way Scheme systems work---an interactive environment, to-C compilers,
incremental compilers, what have you.
Matthew> I consider makefiles and project files to be the root of all evil when
Matthew> it comes to sharing code. For example, I cringe whenever I have to add
Matthew> a source file to MrEd, because I know that it's going to be very
Matthew> painful to update the Visual Studio project files in a way that leaves
Matthew> them usable by others.
Hm. Even though I don't share this experience (despite working with
Visual Studio a lot these days), I'll accept that.
Matthew> As we've discussed, I think that we can work toward a
Matthew> component language that everyone will use by default, much as
Matthew> PLT Scheme programmers use the `mzscheme' language by
Matthew> I don't think we have it now, but I don't think we should
Matthew> wait for it, either. [...]
Matthew> I agree that the problem is serious, even if it seems to
Matthew> happen less in practice that I believed in 1998.
Matthew> But, of course it can be solved with MzScheme-style modules,
Matthew> because you can define any language through a module. In
Matthew> particular, if there exists a component language for everyone
Matthew> to use, then you can define it as a module-based language.
Would you think we could formulate that as a goal for R6RS? (Even if
that requires a novel design.) If so, I think I would probably be
much more flexible about this. (And, I think I'd be enthusiastic
about working on it.)
Matthew> I believe that we can find a generalization to arbitrary
Matthew> first-order data that will be perfect for Scheme --- but that
Matthew> takes us into research, and far afield of a standard module
Side issue: Does this mean the component system you envision will be
about data only, not syntax?
Also, there are other aspects about the proposal I posted---could you
comment on those?
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
More information about the R6RS