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

Re: problems with rationale & design

This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.




On Sat, 19 Jun 2004, felix wrote:

>bear wrote:
>>
>> On Fri, 18 Jun 2004, Felix Winkelmann wrote:
>>
>>
>>>For example: R5RS Scheme has `load'. Effectively that's all what we need,
>>>and `require-extension' is just a thin wrapper over it, probably doing
>>>some module-specific stuff (like an `import', or something similar).
>>
>>
>> Except that it isn't.
>>
>> Large programs (millions of lines of code plus, like an OS kernel
>> or even a large application) simply can't be managed when your
>> only interface is (load). It is silly to even think about
>> developing them interactively.
>
>a) nobody writes such large programs in Scheme (currently)

Exactly my point.  Scheme does not support large programs
currently.


>What nonsense. Nobody is talking about command-lines here.

Pardon me.  You may choose to call it an "interactive lisp prompt"
or a "Read-eval-print loop."

>> And yet others will consider it broken
>> if it's not an enclosing form, which allows definitions to be
>> made in multiple different environments in the same input
>> stream, but which can't be used from the command line because
>> you want results before you type the closing paren on the
>> enclosing form.
>
>Huh? What are you talking about?

Advocates of enclosing forms for modules believe that when
they have two different modules that require different
definitions of "foo" they should both be able to live together
in the same program, and that an enclosing form is needed to
give a proper lexical scope to the definitions of "foo" in
use.  For example, I should be able to write:

( <some expression requiring module A and defining module C>
   .... code using A's keyword foo, for module C ....
)

(  <some expression requiring module B and defining module D>
  ... code using B's procedure foo, for module D ....
)

( <some expression reqiring the definitions in modules C and D
           and defining module E>
   ... code for module E, which does not see any
       definitions for "foo" ....
)

in one file, and it should work.  If modules A and B are
available, this ought to provide modules C, D, and E,
from this source file.  And I ought, in other source
files, to be able to require module C without requiring
D or E, or get just E, without conflicts, along with
a module which provides "foo" with yet another syntactic
meaning or variable binding.


SRFI-55 is of a different family;  Although more convenient
to use at the command line, I don't think its semantics are
as clear for file-based development.

> `require-extension'
> does imply absolutely *nothing* about modules, yet it can be
> compatible with them.

if you think that this is not about modules, I suggest you
are using some other language, in which "modules" does not
mean what the rest of the community thinks it means.

				Bear