[R6RS] Re: strawman module syntax

[Michael Sperber]

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

Touch?.

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

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

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