srfi names
Alex Shinn
Am I the only one who thinks referring to srfi's by number is silly?
Sure, though they were Greek to me initially I now know srfi-1, srf-2,
srfi-13 and several others by number because I use them all the time.
But then I find myself trying to remember what srfi-31 and srfi-32 are,
and I realize this is the process we ask every beginner to go through
for even the common srfi's. And it's just going to get worse, because
there are a lot of useful srfi's still waiting to happen.
Apparently I'm not the only one of this opinion. In srfi-1 there is the
note:
In a Scheme system that has a module or package system, these
procedures should be contained in a module named "list-lib".
and a similar note exists in srfi-13. However, at a quick sampling of
Schemes with module systems and srfi support we see
(require 'srfi-1) ;; slib
(use-modules (srfi srfi-1)) ;; guile
(use srfi-1) ;; gauche
and they probably aren't alone in this. I suspect it's because for all
intents and purposes, the official name of that particular library
really is srfi-1, not list-lib, and all references to it and links off
the srfi site call it such.
So maybe it would be a good idea that one of the finalizing processes of
every srfi be to choose a reasonable module name for it, which will then
be the official name of the srfi and the actual number used during it's
discussion become a footnote in its history?
--
Alex
Michael Sperber [Mr. Preprocessor]
Alex> So maybe it would be a good idea that one of the finalizing processes of
Alex> every srfi be to choose a reasonable module name for it, which will then
Alex> be the official name of the srfi and the actual number used during it's
Alex> discussion become a footnote in its history?
We thought about this long and hard and abandoned the idea. The
problem is that there may be several SRFIs claiming the same name.
Just put a comment in your code.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Jussi Piitulainen
> We thought about this long and hard and abandoned the idea. The
> problem is that there may be several SRFIs claiming the same name.
> Just put a comment in your code.
When you mention an srfi-* in a discussion, just add a comment there,
too. Like, srfi-13 (error) or srfi-102 (window system). Need not be
formal, just something to help the reader guess what you are about.
--
Jussi
Alex Shinn
>>>>> "Alex" == Alex Shinn <fo...@synthcode.com> writes:
Alex> So maybe it would be a good idea that one of the finalizing
Alex> processes of every srfi be to choose a reasonable module name
Alex> for it, which will then be the official name of the srfi and
Alex> the actual number used during it's discussion become a
Alex> footnote in its history?
Mike> We thought about this long and hard and abandoned the idea.
Mike> The problem is that there may be several SRFIs claiming the
Mike> same name.
Hmmmm.... I didn't say it would be simple... choosing good names is
hard. But do you really think that another general-purpose list library
would be proposed and finalized? Wouldn't it be solving a slightly
different problem, and be better named sort-lib, or set-lib, or maybe
just list-aux-lib for some extra procedures? If it really was meant as
a replacement, isn't list-lib-2 better than srfi-78?
Mike> Just put a comment in your code.
Where? I wasn't suggesting the read-problem, where people don't know
what (require srfi-1) means (though that is a problem). I was
suggesting the write-problem, where you can remember the names of one or
more procedures in a srfi but not the number of the srfi itself. I
don't want to have program with a green-card.
--
Alex
Michael Sperber [Mr. Preprocessor]
>>>>> "Mike" == Michael Sperber [Mr Preprocessor] <spe...@informatik.uni-tuebingen.de> writes:
>>>>> "Alex" == Alex Shinn <fo...@synthcode.com> writes:
Alex> So maybe it would be a good idea that one of the finalizing
Alex> processes of every srfi be to choose a reasonable module name
Alex> for it, which will then be the official name of the srfi and
Alex> the actual number used during it's discussion become a
Alex> footnote in its history?
Mike> We thought about this long and hard and abandoned the idea.
Mike> The problem is that there may be several SRFIs claiming the
Mike> same name.
Alex> Hmmmm.... I didn't say it would be simple... choosing good names is
Alex> hard. But do you really think that another general-purpose list library
Alex> would be proposed and finalized?
Yes.
Sander Vesik
>
> Hmmmm.... I didn't say it would be simple... choosing good names is
> hard. But do you really think that another general-purpose list library
> would be proposed and finalized? Wouldn't it be solving a slightly
yes. it would be very nice to see a list library that treated lists
as opaque objects and not chains of cons cells so that implememnations
optimised to teh architecure, system and garbage collector at hand
could be provided. Writing a generic, plug-in your cahce line size,
compacted list library is not too hard.
--
Sander
+++ Out of cheese error +++
Ray Blaak
> Mike> We thought about this long and hard and abandoned the idea.
> Mike> The problem is that there may be several SRFIs claiming the
> Mike> same name.
Give an srfi prefix to the names, to show that they are officially
sanctioned. Several SRFIs cannot claim the same name, just like they cannot
claim the same number.
Names are better since we can remember them better.
E.g. srfi-lists, srfi-records
Another compromise is to put the number and name, allowing for versioning
srfi-23-lists vs srfi-78-lists
(the numbers are made up here)
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Brian Harvey
>yes. it would be very nice to see a list library that treated lists
>as opaque objects and not chains of cons cells so that implememnations
>optimised to teh architecure, system and garbage collector at hand
>could be provided. Writing a generic, plug-in your cahce line size,
>compacted list library is not too hard.
It might indeed be nice to have such a library, but I hope that the data
type it implements would be given a name other than "list"! In the context
of Lisp programming, recycling the name "list" for something that doesn't
at least look like linked pairs above its abstraction barrier would be
very confusing. And if your abstraction *doeS* look like pairs to its user,
then you can call the library srfi-cdr-coded-lists and nobody will confuse
it with srfi-lists.
Sander Vesik
>
> It might indeed be nice to have such a library, but I hope that the data
> type it implements would be given a name other than "list"! In the context
> of Lisp programming, recycling the name "list" for something that doesn't
> at least look like linked pairs above its abstraction barrier would be
But looking like a chain of piars *is* the problem part with lists! The problem
is that scheme does not have a list datatype and instead uses a horrible subsitute
in which trivial operations like 'list?', 'length', (cadddr (cddddr x)) have
mind-boggling cmplexities instead of being simple constant time operations.
Knowledge of and reliance on internal implementation details is both evil and
inhibits optimisations.
> very confusing. And if your abstraction *doeS* look like pairs to its user,
> then you can call the library srfi-cdr-coded-lists and nobody will confuse
> it with srfi-lists.
I don't think srfi-names is the right approach - inventing a name for r5rs plus
a set of commonly implemented srfi-s sounds like a much better approach.
felix
>
> I don't think srfi-names is the right approach - inventing a name for r5rs plus
> a set of commonly implemented srfi-s sounds like a much better approach.
I'm pretty sure the lack of proper SRFI-names will become unbearable
in the future. I already end up mixing up srfi-numbers, which gets
annoying if you use an implementation that supports many of them.
(this is just a splendid example of the way things work in the so-called
"scheme community": because everybody rather does nothing than agree on
something even slightly suboptimal, nothing will happen. ;-)
I propose a "meta-SRFI", a registry that maps proper names to finalized
SRFIs. The SRFI author (and the discussion list) decides on a name,
which,
after finalization can not be changed.
The document for this meta-SRFI should be regularly updated, either
by the SRFI-editors or by the author. Proper names should follow
a simple official naming scheme ("xxx-lib" for large libraries, for
example,
or the name of a special form or procedure, like "receive"), which of
course is just a recommendation, the name can be anything the author
likes.
Adding a section to the SRFI-template would also be a good idea.
Scheme's providing a module-system are encouraged but not required
to use the proper names for modules that correspond to SRFIs.
And if there comes up the (very rare, IMHO) situation of two SRFIs that
might have colliding names, then, for Christs sake:
Agree on *something* and get going!
cheers,
felix
David Rush
> Hmmmm.... I didn't say it would be simple... choosing good names is
> hard. But do you really think that another general-purpose list library
> would be proposed and finalized?
Yes, absolutely. And I would hope that it will be Olin who writes it, too.
> Wouldn't it be solving a slightly
> different problem, and be better named sort-lib, or set-lib, or maybe
> just list-aux-lib for some extra procedures? If it really was meant as
> a replacement, isn't list-lib-2 better than srfi-78?
Maybe, maybe not. It works for RFCs and it has the advantages of being
simple and politically neutral. I think those are more important than
working out a complex naming-and-version system.
david rush
--
Thtrap it to the bench and put a good thick bolt of lightning through
it, that'th our motto.
-- Igor (in _Thief of Time_)
Thien-Thi Nguyen
> Agree on *something* and get going!
using NUMBER-SHORT-NAME, we have (off the top of my head):
1-list-lib
...
13-string-lib
14-charset-lib
...
99-bottles-of-beer-on-the-wall
srfi authors choose the SHORT-NAME, editors choose the NUMBER. the result is
unambiguous and amenable to tools. what's the big hairy deal? editors (or
whoever decides the process) just need to say "ok". do it now and require a
few retroactive annotations, or do it later and watch everyone implement some
variant of essentially the same theme (w/ the still-required retroactive
annotations unshared by the implementations, good grief).
thi
Jeffrey Siegal
> I don't think srfi-names is the right approach - inventing a name for r5rs plus
> a set of commonly implemented srfi-s sounds like a much better approach.
I'm pretty sure I agree with this. Numbers seem fine for individual
topics, as with RFCs. However, at some point it does make sense for
someone to take a high level view and decide on a group of SRFIs that
are useful together as a framework for some family of applications.
Of course, this might well depend on the applications. For example, a
system intended for implementing enterprise applications might include
data management, a transaction monitor, messaging service, etc. In
Java, we call this J2EE, although each of the components has its own
name and development path, and none are part of the core language itself.
Jeffrey Siegal
> Give an srfi prefix to the names, to show that they are officially
> sanctioned. Several SRFIs cannot claim the same name, just like they cannot
SRFIs are not "officially sanctioned." Cataloged might be a better verb.
Alex Shinn
David> Alex Shinn <fo...@synthcode.com> writes:
>> Wouldn't it be solving a slightly different problem, and be
>> better named sort-lib, or set-lib, or maybe just list-aux-lib for
>> some extra procedures? If it really was meant as a replacement,
>> isn't list-lib-2 better than srfi-78?
David> Maybe, maybe not. It works for RFCs and it has the advantages
David> of being simple and politically neutral. I think those are
David> more important than working out a complex naming-and-version
David> system.
I don't think RFC numbers help at all except to make those who quote
them sound intelligent, people in the know of some deep-magic. RFC-XXXX
means nothing to me, but if you say RFC-IRC I can get an idea what
you're talking about even if I've never read the thing. And if you say
RFC-IRC-2, then I know you're talking about a successor or alternate to
the original RFC, which actually provides quite a lot of information.
Thankfully we don't have to include a bunch of RFC's at the top of every
program we write. I recently wrote a (still incomplete) IRC server in
Scheme that was mostly cut&paste&emacs-macros of the actual RFC text,
and for all the time I spent on it I can't for the life of me remember
what number the RFC was.
I already have cut&paste viruses running through my code where I just
include all the srfi's used in one module in all related modules because
I forget what they refer to :) For the simplest of srfi's, it must've
taken me 20 runtime errors before I could remember that and-let* comes
from srfi-2.
I agree wholeheartedly with Felix's suggestion of a separate registry of
names, since that's probably the only way of getting anything done about
this. Should the meta-srfi not just be written as a new srfi itself?
Were you volunteering to do that, Felix? :)
--
Alex
Shriram Krishnamurthi
> So how do you actually feel about a reverse index?
I confess I have been following this thread very poorly. Having
issued that disclaimer, I wonder: someone proposed the naming scheme
srfi-<number>-<name>
eg, srfi-89-exceptions or srfi-4335-modules (he's dreaming, folks) --
<name> could be required to be a Scheme symbol.
What was the argument against that? I rather liked it. It addressed
all of the following problems:
- no need for additional complexity like a reverse index
- easier to remember which SRFI does what
- no need for global consensus about functionality and names
- allows for overlapping functionality across SRFIs
- slightly improves searching
etc
Shriram
Jeffrey M. Vinocur
Shriram Krishnamurthi <s...@cs.brown.edu> wrote:
>
> srfi-<number>-<name>
>
>What was the argument against that? I rather liked it.
It didn't solve the original problem, which was people disliked
needing to memorize the numbers (for use when coding).
(Has anybody proposed srfi-<name>-<index>, where index is used to
disambiguate multiple SRFIs wanting the same name -- that is,
index is 00 for the first SRFI requesting/being assigned a given
name.)
--
Jeffrey M. Vinocur * jm...@cornell.edu
http://www.people.cornell.edu/pages/jmv16/
Thien-Thi Nguyen
> It didn't solve the original problem, which was people disliked
> needing to memorize the numbers (for use when coding).
if you don't like to memorize, you must naturally prefer to look up. if you
look up something that requires further lookup, either you have to memorize
the second (and subsequent) mapping(s) or you have to look that up, too...
if you are lazy (like me), you jam everything into the key, do a dired on your
key/file/module/chunk space, bury the buffer, and use M-/ to get to cruising
altitude. 227 buffers -> almost zero lossage.
hence, NUMBER-SHORT-NAME (or the also flavorful srfi-NUMBER-SHORT-NAME).
people are lazy in different ways, i am learning.
thi
Jens Axel Søgaard
> eg, srfi-89-exceptions or srfi-4335-modules
> (he's dreaming, folks)
Yeah - it is more likely we reach srfi-4335 than getting
a srfi-modules :-)
--
Jens Axel Søgaard
Sander Vesik
> David Rush <ku...@bellsouth.net> writes:
>
>> So how do you actually feel about a reverse index?
>
> I confess I have been following this thread very poorly. Having
> issued that disclaimer, I wonder: someone proposed the naming scheme
>
> srfi-<number>-<name>
>
> eg, srfi-89-exceptions or srfi-4335-modules (he's dreaming, folks) --
> <name> could be required to be a Scheme symbol.
Well, the next srfi would be what, 35? so nothing really keeps us from
having say srfi-37-modules which just might be followed by a couple of
dozen more srfi-nn-modules srfi-s. You can replace 'modules' with
any other convininet landgrab term. In fact, I think srfi-0 deserves to
be called srfi-0-modules as it does descirbe one way of having a module
system. An there is of course also srfi-7
And it relies on it being possible to condense the essence of the
srfi down to a word which may not be always possible.
>
> What was the argument against that? I rather liked it. It addressed
> all of the following problems:
>
> - no need for additional complexity like a reverse index
> - easier to remember which SRFI does what
> - no need for global consensus about functionality and names
> - allows for overlapping functionality across SRFIs
> - slightly improves searching
> etc
>
> Shriram
--
Sander Vesik
> In article <w7d3ctm...@cs.brown.edu>,
> Shriram Krishnamurthi <s...@cs.brown.edu> wrote:
>>
>> srfi-<number>-<name>
>>
>>What was the argument against that? I rather liked it.
>
> It didn't solve the original problem, which was people disliked
> needing to memorize the numbers (for use when coding).
>
> (Has anybody proposed srfi-<name>-<index>, where index is used to
> disambiguate multiple SRFIs wanting the same name -- that is,
> index is 00 for the first SRFI requesting/being assigned a given
> name.)
>
Yes - and the problem theer will be that people will assume that
srfi-name-m, superceedes srfi-name-n, where m > n
Ulrich Kaufmann
> Ulrich Kaufmann <babba...@liamtoh.moc> writes:
>
>>As a Java developer and currently a Scheme outsider, I'm glad that
>>opinion appears to be converging towards something potentially at
>>least equivalent to what I use every day.
>
>
> I highly doubt that. I suspect (from the sequel) that you haven't
> understood the question.
>
>
>>1. I don't see the requirement to rationalize SRFI naming as a
>>separate activity from creating a module system.
>
>
> The big problem is how do you define "module system". In Scheme, this
> means (almost entirely) just a namespace management
> system. Hmmm...we've already got one of those, it's called lexical
> scoping of first-class functions. Oh, you want this to work at the
> toplevel, too? That's a *lot* trickier problem, the top level is
> poorly defined for such shenanigans. There are several different
> solutions to this problem out there in the Scheme world and no-one has
> yet come up with an obviously superior solution.
>
> <flame-bait>
> My personal opinion is that the whole issue is a complete red
> herring. SML's functors point the way, but xScheme doesn't actually
> need such a complex construct because it is dynamically typed. And
> don't even start talking about separate compilation: R5RS pretty
> clearly view program semantics in whole-program terms.
> </flame-bait>
>
> Naming SRFIs is an entirely different problem, which is political in
> nature, not technical. This is why the SRFI process is completely
> silent on the topic. The process is meant to be blind to alternate
> specifications of similiar functionality. Using numbers is the only
> neutral solution.
>
I find it a little surprising to learn that in Scheme the problem of
developing and composing large systems is essentially a namespace
problem. In non-Scheme systems, I would expect to encounter discussion
of at least the following:
1. Modules referenced explicitly, e.g. by function name
2. Modules referenced implicitly, e.g. a MOP, CORBA-style RPC, security
system etc.
3. Versioning and evolution of systems
4. Ownership (e.g. certification or distribution) of modules and
compositions of modules
5. Compatibility of modules - types, versions etc.
6. Packaging and representation of modules (source, intermediate,
compiled...)
You mention naming in the context of SRFI naming as being an entirely
distinct problem. I find this a rather puzzling statement as clearly at
least the first 5 aspects above apply to SRFIs as much as to any other
Scheme artifacts. Their 'political' nature is arguably merely an
ownership problem - the same problem one might have in managing teams in
any large organization. If SRFI means anything it should mean a process
of rationalization and consensus building, and on that basis the
allocation of an agreed name is no more or less challenging that
reaching a level of consensus in the first place. After all, if naming
by purpose and function is insufficient to differentiate between modules
then the owners/sponsors of those modules must be distinguishing, by
definition. Thus the ibm.xml.Element vs. apache.xml.Element distinctions
we encounter every day with Java.
>
>>2. The module system is obviously a priority in that it helps manage
>>all large systems based on Scheme.
>
>
> See my above rant on the module-nature.
>
>
>>4. J2EE can serve as both a positive and negative example of module
>>naming.
>
>
> I think it's a completely irrelevant example. SRFIs are not
> modules. Some of them have no user-land implementable
> functions. Either the implementation provides them or it doesn't.
>
> Now R5RS Scheme is so flexible that a huge variety of things that
> would normally be excluded from user-land are expressible as
> libraries, but don't let that fool you into thinking that SRFIs are
> any more than what the FAQ says they are: Requests For
> Implementation (features).
>
SRFIs are not modules, but modularity is required for different Scheme
implementations to still be called Scheme.
Modularity should apply to user level functions as well as to system
functions, e.g. plug-compatible implementations of JAAS in the Java world.
>
>
>>5. I'm not clear from Al Petrovsky's post whether his numbers are
>>intended to indicate versions of the same package or alternate
>>implementations of the same concept. My guess is that the latter would
>>be hopelessly confusing and that a Java-style ownership prefix is a
>>better way of disambiguating modules with similar functions.
>
>
> It is the latter and there is no ownership in the J2EE sense. SRFI
> numbers just happen to work really well given the semantics of the
> SRFI concept. We fully expect there to be multiple SRFIs for very
> similiar concepts (OOP and modules are two *immediately* obvious
> candidates).
>
I have trouble accepting this assertion at face value. Are you saying
that alternate implementations are not distinguishable by
owner/sponsor/fan club? "SRFI semantics" appear to be idiosyncratic, to
say the least.
Ulrich Kaufmann
Quite. And this, coupled with the obviously 'randomized identifier'
nature of the SRFI number should be quite sufficient raw material from
which to deduce this naming concept is irrevocably flawed.
There are sufficient inherent distinguishing features between modules
for them to be named distinctly, it is not necessary to throw in funny
numbers. The Java package model of (roughly) Function, Owner.Function or
Owner.Project.Function is perfectly adequate for naming SRFIs,
regardless of its merits in various coding scenarios.
Ulrich Kaufmann
...
> And it relies on it being possible to condense the essence of the
> srfi down to a word which may not be always possible.
A single word might indeed be pushing it, but an inability to come up
with a name of any kind, as we all know, is an indication of a deeper
problem with what is being attempted.
Ray Blaak
The srfi-<number>-name thing was from me, or at least I had also posted it.
Condensing to a single word should not need to be requirement. There should be
nothing inherently wrong with srfi-666-really-cool-beasts.
It would be a matter of "engineering judgement" for the proper balance between
brevity and descriptiveness.
The advantage of srfi-<srfi-id>-whatever vs srfi-whatever-<whatever-id> is
that the former gives a guaranteed unique prefix, whereas the latter requires
one to know about the "whatever" situation(s) in particular.
In general, I don't mind being forced to know the number. I will have to read
the srfi anyway if I am at all interested in its details.
However, srfi-NN by itself, especially in code, does not tell me a hell of a
lot. srfi-NN-neat-feature gives me an immediately idea of what things are
about. In the usual case, it would be enough to jog the memory.
The advantage of the "srfi-" prefix is to clearly indicate that the feature(s)
came from the srfi process, and thus has available discussions, documentation,
sample implementations, etc.
Ulrich Kaufmann
> Ulrich Kaufmann <babba...@hotmail.com> writes:
>
>>Sander Vesik wrote:
>>...
>>
>>>And it relies on it being possible to condense the essence of the
>>>srfi down to a word which may not be always possible.
>>
>>A single word might indeed be pushing it, but an inability to come up
>>with a name of any kind, as we all know, is an indication of a deeper
>>problem with what is being attempted.
>
>
> The srfi-<number>-name thing was from me, or at least I had also posted it.
>
> Condensing to a single word should not need to be requirement. There should be
> nothing inherently wrong with srfi-666-really-cool-beasts.
Apart from the meaningless number, of course.
>
> It would be a matter of "engineering judgement" for the proper balance between
> brevity and descriptiveness.
>
> The advantage of srfi-<srfi-id>-whatever vs srfi-whatever-<whatever-id> is
> that the former gives a guaranteed unique prefix, whereas the latter requires
> one to know about the "whatever" situation(s) in particular.
>
If the SRFI process is capable of anything, it must be capable of
generating a memorable (i.e. not random) prefix. The SRFI will have
sufficient information to hand to create a name that has meaning and is
therefore memorable (sponsor of the proposal, purpose, functional
elements, version...).
> In general, I don't mind being forced to know the number. I will have to read
> the srfi anyway if I am at all interested in its details.
>
It is ludicrous to expect users of the language to remember a
potentially large set of numbers and their correspondence to useful
concepts, you might as well encourage them to remember opcodes.
> However, srfi-NN by itself, especially in code, does not tell me a hell of a
> lot. srfi-NN-neat-feature gives me an immediately idea of what things are
> about. In the usual case, it would be enough to jog the memory.
>
So we agree that the neat-feature part of srfi-NN-neat-feature is useful
when reading, this leaves the problem of the NN component being obscure
when writing.
> The advantage of the "srfi-" prefix is to clearly indicate that the feature(s)
> came from the srfi process, and thus has available discussions, documentation,
> sample implementations, etc.
Right, this context is essential.
I suppose there would be advantages in formalizing the component
separator in names - the equivalent of / in URIs. Of course, there's
precedent for using URIs themselves as the XML DTD reference if anyone
wants to go there...
David Rush
> David Rush wrote:
> > Ulrich Kaufmann <babba...@liamtoh.moc> writes:
> > The big problem is how do you define "module system". In Scheme, this
> > means (almost entirely) just a namespace management
>
> developing and composing large systems is essentially a namespace
> problem. In non-Scheme systems, I would expect to encounter discussion
> of at least the following:
>
> 1. Modules referenced explicitly, e.g. by function name
> 2. Modules referenced implicitly, e.g. a MOP, CORBA-style RPC,
> 4. Ownership (e.g. certification or distribution) of modules and
> 6. Packaging and representation of modules (source, intermediate,
> compiled...)
1,2,3 & 5b (versioning) are all namespace management. 4 is something
else altogether, and a research problem in its own right. 5a (types)
is (intentionally) poorly addressed in Scheme because it is
dynamically-typed. Packaging is an entirely implementation issue.
> If SRFI means anything it should mean a
> process of rationalization and consensus building,
Sorry, that's not what it means. SRFI is a process of feature
formalization, nothing more. We have been fortunate in that many of
the early ones have addressed well-known holes with well-thought-out
solutions. Past performance is no guarantee of future returns...
> the allocation of an agreed name is no more or less challenging that
> reaching a level of consensus in the first place.
There is *no* consensus required for a SRFI to reach final state. It
can be posted, with all comments ignored, and after 60 days the author
may ask to have it finalized. That's it. No consensus. No authority,
The only authority that exists is being The Right Solution (tm). There
is none in the SRFI process.
david rush
--
The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right.
-- M A Jackson, 1975
David Rush
> Ray Blaak wrote:
> > nothing inherently wrong with srfi-666-really-cool-beasts.
>
> Apart from the meaningless number, of course.
The number gives it rigor.
> > In general, I don't mind being forced to know the number. I will have to read
> > the srfi anyway if I am at all interested in its details.
As Ray Blaak knows.
> It is ludicrous to expect users of the language to remember a
> potentially large set of numbers and their correspondence to useful
> concepts, you might as well encourage them to remember opcodes.
I expect them to RTFM.
> So we agree that the neat-feature part of srfi-NN-neat-feature is
> useful when reading, this leaves the problem of the NN component being
> obscure when writing.
Consider it a (non-sequential) version number. It is still important.
david rush
--
The truth may be out there, but lies are inside your head.
-- Terry Pratchett, in _Hogfather_
Ulrich Kaufmann
> Ulrich Kaufmann <babba...@hotmail.com> writes:
>
>>Ray Blaak wrote:
>>
>>>nothing inherently wrong with srfi-666-really-cool-beasts.
>>
>>Apart from the meaningless number, of course.
>
>
> The number gives it rigor.
On the contrary, it indicates an inability to name a concept.
>
>
>>>In general, I don't mind being forced to know the number. I will have to read
>>>the srfi anyway if I am at all interested in its details.
>>
>
> As Ray Blaak knows.
>
>
>>It is ludicrous to expect users of the language to remember a
>>potentially large set of numbers and their correspondence to useful
>>concepts, you might as well encourage them to remember opcodes.
>
>
> I expect them to RTFM.
>
This is a circular argument. If you can present a rationale for adding
random numbers to names then clearly they have value and should be kept,
documented and considered required reading. If not, they are merely
cabbalistic nonsense and serve merely to alienate potential users of the
language.
>
>>So we agree that the neat-feature part of srfi-NN-neat-feature is
>>useful when reading, this leaves the problem of the NN component being
>>obscure when writing.
>
>
> Consider it a (non-sequential) version number. It is still important.
>
Are you seriously asking us to consider this new and entirely
unsupported proposal at this stage? Are we to regard the concepts of
version, alternative and synonym as somehow interchangable?
If there is a discussion of these issues and an explanation of how
throwing in a magic number is the answer to resolving all their
associated naming issues I would appreciate a reference to it. If not, I
respectfully suggest that you consider formulating such a rationale
rather than dispensing trite one-liners.
Thien-Thi Nguyen
> On the contrary, it indicates an inability to name a concept.
if the concept is unique, you're right. if the concept is part of a larger
concept (in this case, the srfi process and promise, so to speak), you need
to keep in mind the wider requirements of the naming act.
example: BLUE <-- perfect name for the concept "blue" right?
now, i'm coding up sim-usenet-denizens and i need one of those BLUE people.
damn, does that mean this sim-poster will have skin tone of deepest azzure,
or will this sim-poster lie in a desultory funk all day listening to brain-
melting pop music and newz (ick)? viddy the horrshow confuso, me droogies.
sure, "32-blue" vs "57-blue" is no piece of pure elegance, but it is elegant
in the engineering sense of striking a compromise at the right place so that
sim-usenet-denizens, its third-party expansion packs (wherein "blue" denotes
entanglement w/ law-enforcement), and other simulations (like life) can roll
on. (your path may be beautifully paved, but the rocks underlying are never
perfect spheres.)
thi
Ulrich Kaufmann
> Ulrich Kaufmann <babba...@hotmail.com> writes:
>
>>David Rush wrote:
>>
>>>Ulrich Kaufmann <babba...@liamtoh.moc> writes:
>>>The big problem is how do you define "module system". In Scheme, this
>>>means (almost entirely) just a namespace management
>>
>>I find it a little surprising to learn that in Scheme the problem of
>>developing and composing large systems is essentially a namespace
>>problem. In non-Scheme systems, I would expect to encounter discussion
>>of at least the following:
>>
>>1. Modules referenced explicitly, e.g. by function name
>>2. Modules referenced implicitly, e.g. a MOP, CORBA-style RPC,
>>3. Versioning and evolution of systems
>>4. Ownership (e.g. certification or distribution) of modules and
>>5. Compatibility of modules - types, versions etc.
>>6. Packaging and representation of modules (source, intermediate,
>>compiled...)
>
>
> 1,2,3 & 5b (versioning) are all namespace management. 4 is something
> else altogether, and a research problem in its own right. 5a (types)
> is (intentionally) poorly addressed in Scheme because it is
> dynamically-typed. Packaging is an entirely implementation issue.
>
All 'namespace management'? Well I have to confess that this is nothing
short of a revelation to me. Have you attempted to communicate this
extraordinary insight to the Java or Dotnet platform designers? I would
be most interested to see their response. I can imagine that their
appreciation would be practically unbounded, given that you have managed
to reduce such a pervasive, complex and frequently conflicting set of
requirements not merely to one language or mechanism, but to just two
words! Why, in one fell swoop we could dispense with the notions of
packages, assemblies, class paths, implicit and explicit versions,
composition descriptors, class loader hierarchies, platform plugins,
schema evolution... in fact, given the astonishing range of problems to
which your namespaces proposal (if I may be so bold as to call it that)
is to be applied, one is obliged to feel some disappointment at your
reticence in choosing not to offer it to us as the complete solution for
the ownership, trust and typing issues at this time.
Of course, there will be those arguing that these groups have chanced
upon some serviceable hacks in these last areas - interfaces, signed
code and package prefixes, for example - but I, for one, look forward to
the day when these ungainly excrescences can be discarded in favour of
the profound and universal solution that Scheme will offer, a
development contingent presumably only on channelling sufficient time
from leading visionaries such as yourself and possibly (though this
should be considered very much icing on the cake) some experience gained
from managing projects with more than one developer.
>
>>If SRFI means anything it should mean a
>>process of rationalization and consensus building,
>
>
> Sorry, that's not what it means. SRFI is a process of feature
> formalization, nothing more. We have been fortunate in that many of
> the early ones have addressed well-known holes with well-thought-out
> solutions. Past performance is no guarantee of future returns...
>
>
>>the allocation of an agreed name is no more or less challenging that
>>reaching a level of consensus in the first place.
>
>
> There is *no* consensus required for a SRFI to reach final state. It
> can be posted, with all comments ignored, and after 60 days the author
> may ask to have it finalized. That's it. No consensus. No authority,
> The only authority that exists is being The Right Solution (tm). There
> is none in the SRFI process.
>
I was led to believe by some well-meaning but unfortunately probably
misguided people on this group that the SRFI process is an informal
standardization process. One should therefore probably ascribe to naive
idealism statements in the SRFI FAQ such as following:
"When the [external] discussions have coalesced to the point where an
implementation strategy is apparent, then it is time to write up a SRFI
proposal."
I now understand that is is unreasonable to expect any consensus to
arise as a result of this activity, certainly one going so far as to
assign a meaningful *name* to it. I have to say that if someone had the
temerity to to suggest that some SRFI of mine were to be called, for the
sake of argument, the KaufmannProposal, I would object strongly on the
grounds of copyright, liability and possibly invasion of privacy. And I
would recommend that others do the same. After all, if we were to have
the names of individuals, companies or projects polluting our namespace
otherwise we might as well give up now and call it Java with parentheses.
Ulrich Kaufmann
If I divine your meaning correctly, you are proposing the disambiguation
of homonyms through the addion of a random numeric prefix.
Given that this would be a common requirement in many walks of life,
perhaps there are some examples of the successful application of your
idea outside the realm of computer science?
Ulrich Kaufmann
for distinguishing multiple SRFIs which are functionally similar. For
this, the sponsor or project ID can be employed, e.g. gnome-ui, kde-ui,
palm-ui.
One awaits its fate with interest.
Thien-Thi Nguyen
> If I divine your meaning correctly, you are proposing the disambiguation
> of homonyms through the addion of a random numeric prefix.
except for the random part, yes. it is not random because the srfi editors
assign some number which so far seems to be serial in nature.
> Given that this would be a common requirement in many walks of life,
> perhaps there are some examples of the successful application of your
> idea outside the realm of computer science?
my mail and my neighbor's mail usually don't mix. the mail carrier doesn't
have a compsci background, although her name is blaise... she doesn't need to
memorize my life details (those that i share in conversation) to get the mail
to me. instead, she understands the name in the context of the namespace, as
do i, my snail mail correspondants, the post office system in general, and
(unfortunately) the junk mailers. this name has a (slightly) arbitrary number
as its prefix, and no one is annoyed by it.
in your other (recent) post you point out that (global / bit-rot resistent)
addressing is indeed a hairy concern, not to be swept under the rug. what we
are facing here is whether or not the guardians of this one level of the
namespace hierarchy (the srfi process designers) can figure out how to do a
good hash job so as to ease later composition w/ the other levels. can they
back off from the desire to solve the global problem? what kinds of
attachment/detachment will be practiced? certainly, one answer (status quo)
is that the number alone is sufficient. but everyone loves good hash...
IMHO predicating srfi naming on "module system" definition is an interesting
problem in that all bootstrap problems are interesting (at least, the first
time ;-). however, i'm impatient and not getting younger.
ok, that's all i have to spew about this.
thi
Ulrich Kaufmann
> Ulrich Kaufmann <babba...@hotmail.com> writes:
>
>
>>If I divine your meaning correctly, you are proposing the disambiguation
>>of homonyms through the addion of a random numeric prefix.
>
>
> except for the random part, yes. it is not random because the srfi editors
> assign some number which so far seems to be serial in nature.
>
Not quite random then. I sense that it would be churlish not to accord
the SRFI editors due recognition for confining the SRFI numbers to a
tractable range of the positive integers.
>
>>Given that this would be a common requirement in many walks of life,
>>perhaps there are some examples of the successful application of your
>>idea outside the realm of computer science?
>
>
> my mail and my neighbor's mail usually don't mix. the mail carrier doesn't
> have a compsci background, although her name is blaise... she doesn't need to
> memorize my life details (those that i share in conversation) to get the mail
> to me. instead, she understands the name in the context of the namespace, as
> do i, my snail mail correspondants, the post office system in general, and
> (unfortunately) the junk mailers. this name has a (slightly) arbitrary number
> as its prefix, and no one is annoyed by it.
>
> in your other (recent) post you point out that (global / bit-rot resistent)
> addressing is indeed a hairy concern, not to be swept under the rug. what we
> are facing here is whether or not the guardians of this one level of the
> namespace hierarchy (the srfi process designers) can figure out how to do a
> good hash job so as to ease later composition w/ the other levels. can they
> back off from the desire to solve the global problem? what kinds of
> attachment/detachment will be practiced? certainly, one answer (status quo)
> is that the number alone is sufficient. but everyone loves good hash...
>
> IMHO predicating srfi naming on "module system" definition is an interesting
> problem in that all bootstrap problems are interesting (at least, the first
> time ;-). however, i'm impatient and not getting younger.
>
> ok, that's all i have to spew about this.
>
As in Pascal? Descendents of renaissance philosphers are indeed
lamentably thin on the ground among the ISP management fraternity.
I venture to suggest that disambiguation for email names is problematic
because we are all assigned essentially random identifiers from our
beloved parents from a rather small 'naming domain' (name set). In the
earlier times, we might identify somebody as King Harald Bluetooth
basing the name on a real characteristic, in this case real evidence of
the regrettable lack of attention to dental hygiene among Viking
warlords. Today, the identifying attributes obvious in that period
shortly after birth, when names are ascribed, tend to be rather
transient - I would probably resent being named Ulrich Suckthumb, for
example.
Fortunately, such considerations do not apply to SRFIs.
First of all, such artifacts can be identified by their purpose - user
interface, workflow, security etc. - second by perhaps by their
implementation - database, file, LDAP directory etc. - and, failing
everything else, by their sponsoring group, project or owner. This last
is a bit like the situation that would arise if all members of the
Nguyen or Kaufmann clans were obliged to get together to decide on a
naming scheme for their progeny - you can be fairly sure that they would
avoid resorting to names like Thien-Thi67 or Ulrich76.
The question is, as you say, whether the SRFI process designers have the
wherewithal to assign a distinguishing name to the SRFI. From the above
it would seem that they have, but if any controversy should arise then
they can delegate the problem to the DNS namespace as Java does, and so
avoid solving the 'global problem'.
I concur absolutely that the resolution of SRFI naming is interesting,
indeed, it is practically a litmus test of the ability of this group to
converge upon an adequate solution for what is a fundamental
requirement. We await developments with interest.
David Rush
> David Rush wrote:
> > Ulrich Kaufmann <babba...@hotmail.com> writes:
> >>David Rush wrote:
> >>>The big problem is how do you define "module system". In Scheme, this
> >>>means (almost entirely) just a namespace management
>
> nothing short of a revelation to me. Have you attempted to communicate
> this extraordinary insight to the Java or Dotnet platform designers? I
> would be most interested to see their response. I can imagine that
> their appreciation would be practically unbounded, given that you have
> managed to reduce such a pervasive, complex and frequently conflicting
> set of requirements not merely to one language or mechanism, but to
> just two words! Why, in one fell swoop we could dispense with the
> notions of packages, assemblies, class paths, implicit and explicit
> versions, composition descriptors, class loader hierarchies, platform
> plugins, schema evolution... in fact, given the astonishing range of
> problems to which your namespaces proposal (if I may be so bold as to
> call it that) is to be applied, one is obliged to feel some
> disappointment at your reticence in choosing not to offer it to us as
> the complete solution for the ownership, trust and typing issues at
> this time.
That's the beauty of Scheme (modulo trust and type issues which I
never said were namespace issues) . Try out the concept of functors
someday, OK?
Of course, I also prefer instance-based OO ;)
> some experience
> gained from managing projects with more than one developer.
I've actually done a bit of this in 20 years of professional
programming. I like Scheme.
> I was led to believe by some well-meaning but unfortunately probably
> misguided people on this group that the SRFI process is an informal
> standardization process.
Indeed. *Informal* is exactly what it is. You persistently
misunderstand what's going on here. Just because something goes to
final SRFI has no bearing on the quality or desirability of that
feature. I, personally, think that SRFI-17 is one of the worst ideas
to ever be suggested for inclusion in Scheme implementations (there
are those who disagree), but in spite of much more formidable
opposition than I can provide, it still progressed to final. All I can
do now is hope that no-one implements it. Failing that, I hope that
no-one actually *uses* it.
> One should therefore probably ascribe to
> naive idealism statements in the SRFI FAQ such as following:
>
> "When the [external] discussions have coalesced to the point where an
> implementation strategy is apparent, then it is time to write up a
> SRFI proposal."
No. That is accurate. The SRFI process is not what you think it
is. Until, you understand what it actually *is*, you will continue to
be frustrated.
david rush
--
Scheme: Because closures are cool.
-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)
David Rush
> last is a bit like the situation that would arise if all members of
> the Nguyen or Kaufmann clans were obliged to get together to decide on
> a naming scheme for their progeny - you can be fairly sure that they
> would avoid resorting to names like Thien-Thi67 or Ulrich76.
This is an unproven assertion that is arguably incorrect. Certainly in
America (and certain European aristocratic families) we *do* use a
combinatino of alphabetic name + numeric suffix to disambiguate names
common across generations.
david rush
--
Don't you think it would be a useful item to add to your intellectual
tookit to be capable of saying, when a ton of wet steaming bullshit
lands on your head, "My goodness, this appears to be bullshit?"
-- Douglas MacArthur Shaftoe, in_Cryptonomicon_
David Rush
> I concur absolutely that the resolution of SRFI naming is interesting,
> indeed, it is practically a litmus test of the ability of this group
> to converge upon an adequate solution for what is a fundamental
> requirement. We await developments with interest.
We have a solution: sequential numbering. It has the advantage of
being both uniform and value-neutral. There are other valid approaches
(as Shriram and Al* have suggested) that might be useful. The question
is, given that we only have 30-odd SRFIs, do we need a new solution
*right now*? Clearly opinions on this question may differ.
david rush
--
Do not ask how. Ask rather why. Once you know your reason,
your method will be obvious.
-- The book of Bears (zen scheme, ch 1 verse 22)
Lauri Alanko
> There are sufficient inherent distinguishing features between modules
> for them to be named distinctly, it is not necessary to throw in funny
> numbers. The Java package model of (roughly) Function, Owner.Function or
> Owner.Project.Function is perfectly adequate for naming SRFIs,
> regardless of its merits in various coding scenarios.
Seconded. Even the Haskell world, earlier constrained to a single module
namespace, is moving towards a hierarchical naming system. The Java
package system _works_, though admittedly it is about the only thing
about Java that works. :)
But if we really want simple unique identifiers for each SRFI, I have a
proposal for a naming policy: obscureness. The danger of naming
conflicts comes mainly because we fear a duplication of _concepts_
between SRFI:s. It is possible that there will be SRFIs for many
different object systems, list libraries and module systems, and hence
simply "objects" won't do for a name.
Therefore names must _not_ be general descriptions, though they may of
course be acronyms of descriptive phrases. For example, "yasos" and
"meroon" sound like perfect names with little danger of accidental
duplication. Names like "slib" and "tinyclos" are a bit less safe, but
should still be quite acceptable.
Of course this would again mean that we need to memorize the names, but
now they are _names_ and not numbers, and humans are much better at
remembering those. And this is the way that things are done everywhere
else, too: every software project or library gets quirky enough a name
so as not to get confused with anything else.
Somehow we even manage to name all the zillions of scheme
implementations differently even though they all provide the same basic
functionality. And we even manage to _remember_ those names even though
none of them is simply "scheme".
Lauri Alanko
l...@iki.fi
Unknown
Namespace management AND functors? Oh dear, I can picture now the
crestfallen faces among those readers who a moment ago trusted that
namespaces alone were the answer to everything.
I fear that, after some further questioning from we the initiates, consuming
at a guess a modest 200 messages or so on the newsgroup given our present
rate of progress, that at some point the master will reveal that the concept
of Independently Developed Unit of Software *is* actually required in large
Scheme systems.
One trembles in imagining the treachous and uncharted waters that we would
then be forced to navigate, The denizens of Scheme World can, I suppose,
derive some consolation from the fact that this is all probably far off
enough for its consequences to only impact later generations.
>
>Of course, I also prefer instance-based OO ;)
>
>> some experience
>> gained from managing projects with more than one developer.
>
>I've actually done a bit of this in 20 years of professional
>programming. I like Scheme.
A most encouraging conclusion, and presumably one shared by the other
members of the projects you participated in. There were other members,
weren't there?
>
>> I was led to believe by some well-meaning but unfortunately probably
>> misguided people on this group that the SRFI process is an informal
>> standardization process.
>
>Indeed. *Informal* is exactly what it is. You persistently
>misunderstand what's going on here. Just because something goes to
>final SRFI has no bearing on the quality or desirability of that
>feature. I, personally, think that SRFI-17 is one of the worst ideas
>to ever be suggested for inclusion in Scheme implementations (there
>are those who disagree), but in spite of much more formidable
>opposition than I can provide, it still progressed to final. All I can
>do now is hope that no-one implements it. Failing that, I hope that
>no-one actually *uses* it.
Alas, your misunderstanding is of an altogether more fundamental nature.
Consensus on a name of something does not imply any consensus on its value.
I happen not to like the Apache JDOM API, but that doesn't mean that I think
it should be called something else. Were 'apache.jdom' to be suggested as
the name of an SRFI I would have no objection.
The bottom line is that envisioning an SRFI process so anarchic that it
cannot even agree on a practlcal name for a proposal is absurdly nihilistic.
More to the point, were such contrariness to be indulged it would inflict an
awkward and mystifying system on the rest of us.
I hold that, if the Java World can agree on a namespace that includes ms.wfc
and sun.swing then there is no reason that the Scheme World cannot employ
equally meaningful terms.
>
>> One should therefore probably ascribe to
>> naive idealism statements in the SRFI FAQ such as following:
>>
>> "When the [external] discussions have coalesced to the point where an
>> implementation strategy is apparent, then it is time to write up a
>> SRFI proposal."
>
>No. That is accurate. The SRFI process is not what you think it
>is. Until, you understand what it actually *is*, you will continue to
>be frustrated.
>
I appreciate your concern. However, the inherent characteristics of SRFIs
and the relatively trivial process of naming them from these characteristics
are by now so well rehearsed that no one could be in any doubt of what is
desirable and what is feasible. Indeed I suspect that most readers feel that
they have seen quite sufficient debate on this topic and are now looking for
the best solution to be progressed. Your own comprehension and attitude are
entirely a matter for you - I see no reason for progress to be obstructed
generally by repeated assertions of little relevance and less substance.
Ulrich Kaufmann
>Ulrich Kaufmann <babba...@hotmail.com> quoth:
>> There are sufficient inherent distinguishing features between modules
>> for them to be named distinctly, it is not necessary to throw in funny
>> numbers. The Java package model of (roughly) Function, Owner.Function or
>> Owner.Project.Function is perfectly adequate for naming SRFIs,
>> regardless of its merits in various coding scenarios.
>
>Seconded. Even the Haskell world, earlier constrained to a single module
>namespace, is moving towards a hierarchical naming system. The Java
>package system _works_, though admittedly it is about the only thing
>about Java that works. :)
>
>But if we really want simple unique identifiers for each SRFI, I have a
>proposal for a naming policy: obscureness. The danger of naming
>conflicts comes mainly because we fear a duplication of _concepts_
>between SRFI:s. It is possible that there will be SRFIs for many
>different object systems, list libraries and module systems, and hence
>simply "objects" won't do for a name.
And indeed this happens all the time in Java. For example, there are many
alternative implementations of XML DOM functions - org.apache.dom, org.jdom,
org.dom4j, weblogic.dom....
The important thing to note is that functional concepts are not the only
concepts that are employed - the company, sponsor or project producing the
software or specification can also be used to name it.
There's no requirement that I'm aware of for an SRFI proposal about OO to be
named "objects". In fact given the SRFI process as described it should be
expressly prohibited, A prefix based on project or sponsor should be used
instead, giving "sisc.objects", "drscheme.objects" etc.
>
>Therefore names must _not_ be general descriptions, though they may of
>course be acronyms of descriptive phrases. For example, "yasos" and
>"meroon" sound like perfect names with little danger of accidental
>duplication. Names like "slib" and "tinyclos" are a bit less safe, but
>should still be quite acceptable.
Your missing the fact that names can be descriptive if they are compound. It
would hardly be progress if random number names were to be replaced by
random letter ones. Yes, the product or project components of a name can be
fanciful, such as Java Swing, but as you say, even these have mnemonic value
that random identifiers do not.
Ulrich Kaufmann
>Ulrich Kaufmann <babba...@hotmail.com> writes:
>> last is a bit like the situation that would arise if all members of
>> the Nguyen or Kaufmann clans were obliged to get together to decide on
>> a naming scheme for their progeny - you can be fairly sure that they
>> would avoid resorting to names like Thien-Thi67 or Ulrich76.
>
>This is an unproven assertion that is arguably incorrect. Certainly in
>America (and certain European aristocratic families) we *do* use a
>combinatino of alphabetic name + numeric suffix to disambiguate names
>common across generations.
>
Yes, this happens. But the whole analogy of individual names for people
modelling those for software specifications is rather ridiculous to start
with.
If you're proposing that successful models of naming in software should not
be employed for Scheme on the grounds that they wouldn't suffice at
distinguishing generations of aristocrats then I think we can fairly
conclude that you are grasping at straws.
Ulrich Kaufmann
>Ulrich Kaufmann <babba...@hotmail.com> writes:
>> I concur absolutely that the resolution of SRFI naming is interesting,
>> indeed, it is practically a litmus test of the ability of this group
>> to converge upon an adequate solution for what is a fundamental
>> requirement. We await developments with interest.
>
>We have a solution: sequential numbering. It has the advantage of
>being both uniform and value-neutral. There are other valid approaches
>(as Shriram and Al* have suggested) that might be useful. The question
>is, given that we only have 30-odd SRFIs, do we need a new solution
>*right now*? Clearly opinions on this question may differ.
>
Is anyone *not* aware of the current solution?
Is there anyone still reading who is not aware that alternatives exist
elsewhere in IT that do not rely on arbitrary numbers?
Does anyone think that a debate comprising, at the last count, 62 messages
constitutes anything less than a difference of opinion?
Well, I hesitate to jump to conclusions, but I think we may be in a position
to congratulate ourselves on having explored a possible strategy.
Ben Goetter
> Does anyone think that a debate comprising, at the last count, 62 messages
Debate? I don't see any debate. I see one Java(tm) programmer who
replies to every message in this thread.
Elsewhere, I see an overall consensus: We Need Modules.
Thien-Thi Nguyen
> Yes, this happens. But the whole analogy of individual names for
> people modelling those for software specifications is rather
> ridiculous to start with.
it may be ridiculous to start with but here we are so let's use it: i
expect someday when my cousins have children those kids will call me
"uncle 2" (if they call me at all) because the reference convenience
trumps the aesthetic authorship of my parents. this is no big deal for
me, and indeed for many cultures were blood-line fan-out is large --
some people are practical like that (and impractical in other ways).
likewise, the demand here is from users, and the process designers who
do not listen to them will in turn have their refcounts drop to 0 (when
it comes to future process design opportunities). don't let this
happen, o apolitical ones, lest you indirectly foment the "unofficial
SRFI project"! oh no, some dissenters w/ webspace might be working on
that already! using curly braces! gahhh!
thi
David Rush
> On 13 Aug 2002 09:28:32 +0100, David Rush <ku...@bellsouth.net> wrote:
> >That's the beauty of Scheme (modulo trust and type issues which I
> >never said were namespace issues) . Try out the concept of functors
> >someday, OK?
>
> Namespace management AND functors? Oh dear, I can picture now the
> crestfallen faces among those readers who a moment ago trusted that
> namespaces alone were the answer to everything.
You really don't understand the language, do you? What does a functor
look like in Scheme, hmmm? How do you manage namespaces in Scheme,
hmmm? (And for those with a clue, I'm not talking about the toplevel).
david rush
--
An elephant is like a building with 4 pillars.
An elephant is warm and squishy.
-- Bill Richter (on comp.lang.scheme)
David Rush
> On 13 Aug 2002 09:34:54 +0100, David Rush <ku...@bellsouth.net> wrote:
> >Ulrich Kaufmann <babba...@hotmail.com> writes:
> >> last is a bit like the situation that would arise if all members of
> >> the Nguyen or Kaufmann clans were obliged to get together to decide on
> >> a naming scheme for their progeny - you can be fairly sure that they
> >> would avoid resorting to names like Thien-Thi67 or Ulrich76.
> >
> >This is an unproven assertion that is arguably incorrect. Certainly in
> >America (and certain European aristocratic families) we *do* use a
> >combinatino of alphabetic name + numeric suffix to disambiguate names
> >common across generations.
> If you're proposing that successful models of naming in software should not
> be employed for Scheme on the grounds that they wouldn't suffice at
> distinguishing generations of aristocrats then I think we can fairly
> conclude that you are grasping at straws.
Or knocking over your straw-man.
david rush
--
X-Windows: It was hard to write; it should be hard to use.
-- Jamie Zawinski
J L Russell
news:okfn0rr...@bellsouth.net...
> Ulrich Kaufmann <babba...@hotmail.com> writes:
> > last is a bit like the situation that would arise if all members of
> > the Nguyen or Kaufmann clans were obliged to get together to decide on
> > a naming scheme for their progeny - you can be fairly sure that they
> > would avoid resorting to names like Thien-Thi67 or Ulrich76.
>
> This is an unproven assertion that is arguably incorrect. Certainly in
> America (and certain European aristocratic families) we *do* use a
> combinatino of alphabetic name + numeric suffix to disambiguate names
> common across generations.
>
In particular, the German noble family Reuss has named pretty much every
single male member of the family Heinrich, for about the last 700 years or
so.
They seem to number them consecutively across all branches of the family.
They get up to LXXXV or so and then start over from I.
Ulrich Kaufmann
the messages you would discover that a proper module system is precisely
what is being advocated by this Java programmer.
A not altogether surprising position, given that a module system is
precisely what he benefits from every day in Java and finds noticably
lacking in Scheme.
On the other side of the debate, we have umpteen magisterially vacuous
restatements of the bizarre status quo in SRFI naming. When basic
requirements for modularity are brought up in this context, they are
dismissed by airy references to namespaces and functors as though these mere
concepts, entirely undeveloped, were to be taken as somehow providing an
equivalent to the sophisticated mechanisms available in commercial
platforms.
Progress is clearly difficult in these circumstances, but I think it's clear
from which side it is likely to come.
Ulrich Kaufmann
package-style SRFI naming, i.e. a name composed generally of sponsor and
function without arbitrary numbering.
Alex Shinn
discussion ]
>>>>> "Ben" == Ben Goetter <goe...@mazama.net.xyz> writes:
Ben> Quoth Ulrich Kaufmann:
>> Does anyone think that a debate comprising, at the last count, 62
>> messages
Ben> Debate? I don't see any debate. I see one Java(tm) programmer
Ben> who replies to every message in this thread.
Well, there's also at least a Perl programmer (hopefully that doesn't
discredit me too much on this list :)
Ben> Elsewhere, I see an overall consensus: We Need Modules.
Most definitely. That is probably the single biggest problem facing
Scheme right now... until we get a module system, the average Scheme
script will never work on more than one Scheme, no matter how similar
the Schemes in question. It limits our ability to share code - anything
from one Scheme always requires munging to work with another. That's
just sad... I know of no other language with a formal standard for which
that is the case.
However, naming is a different issue. As has already been pointed out,
SRFI-0 and SRFI-7 both refer to "feature identifiers" and SRFI-0
specifically mentions there will probably be the need for aliases for
these identifiers. Ideally these identifiers would also be used in a
module system, and likely in general discussions/comparisons/changelogs
of Schemes to give a more meaningful description than some number.
The only real argument that has turned up against names is that numbers
are less ambiguous. This is true. And assembly is less ambiguous than
higher-level languages, and machine code even less so. Sound
frequencies are less ambiguous than musical notation. Latitude and
longitude are less ambiguous than the name of a city. But it's easier
to work with names. Consider the recent discussion of the "begin" form,
where the appropriateness of the name was called into question because
the form serves two purposes. Nobody proposed resolving the ambiguity
by renaming it "primitive-1". We agree sometimes we'll get names wrong,
and are willing to revisit and change names at times, but nobody
actually programs by number.
So I don't think at this point anyone is actually arguing against
descriptive names, the question is really what naming process we use.
Specifically, how do we address naming conflicts when two SRFI's
introduce the same idea? For many things this is not an
issue... "list-lib" defines basic list operations that haven't changed
in decades and aren't likely to be superceded by another SRFI. Rather,
new SRFI's might define additional operations on lists, for example
"sort-lib." But other concepts like "objects" or (alas) "modules"
aren't so simple and may well have many different SRFI's.
One proposal is to suffix conflicting SRFI's with a "serial" number
(optionally always requiring a serial number). This is very easy for
people to remember but can be misleading... objects-2 could be either an
improvement over objects (maybe by the same author) or it could be an
alternate proposal that doesn't even use the same style. If such an
approach were taken people would simply have to remember that these
numbers indicate historical order, not necessarily version or relation.
Another proposal is to require a sponsor prefix. In Java this is
formalized with a domain name convention, in Scheme this could just be
the sponsor or project, e.g. "meroon.objects," "smalltalk.objects," or
"clos.objects". Examples were given of all the various GUI systems,
where you might have "gtk.ui," "kde.ui," or "ncurses.ui". The problem
here is it can be cumbersome when you really don't think the sponsor
prefix is warranted... for the aforementioned list-list, "olin.list-lib"
seems a little wordy.
Yet another option is to do what CPAN does (I don't know of any other
public code repository as large or successful), which is to let the
authors decide what they think is best. The CPAN maintainers do have
veto ability... they can refuse if you want to create a module called
"Regexp," or "Objects" but in general people *want* their names to be
descriptive, and people know that those names aren't very helpful to
users. It is mostly self-regulating. Of course, SRFI's are not a "code
repository" but the naming issue is the same.
In summary: we need names that are easy to remember, but we're not yet
sure what those names should be. There is still room for debate.
--
Alex
Stephen J. Bevan
> Ben> Elsewhere, I see an overall consensus: We Need Modules.
>
> Most definitely. That is probably the single biggest problem facing
> Scheme right now... until we get a module system, the average Scheme
> script will never work on more than one Scheme, no matter how similar
> the Schemes in question. It limits our ability to share code - anything
> from one Scheme always requires munging to work with another. That's
> just sad... I know of no other language with a formal standard for which
> that is the case.
It isn't clear to me why the lack of a module system causes all these
problems. C doesn't have a module system worth the name but that
hasn't stopped people writing some rather large programs in it and/or
sharing code. That is not to say that I object to Scheme having a
module system -- hierarchical names and (higher order) functors would be
nice -- but I don't think it is necessary to solve the code sharing
problem. For example there is nothing stopping people using names
like foo:bar:baz right now to emulate a hierarchical namespace. If
the name gets a bit long in a given context then a shorter name can be
used e.g. (let ((baz foo:bar:baz)) ...).
Alex Shinn
Steve> Alex Shinn <fo...@synthcode.com> writes:
Ben> Elsewhere, I see an overall consensus: We Need Modules.
>>
>> Most definitely. That is probably the single biggest problem
>> facing Scheme right now... until we get a module system, the
>> average Scheme script will never work on more than one Scheme, no
>> matter how similar the Schemes in question. It limits our
>> ability to share code - anything from one Scheme always requires
>> munging to work with another. That's just sad... I know of no
>> other language with a formal standard for which that is the case.
Steve> It isn't clear to me why the lack of a module system causes
Steve> all these problems. C doesn't have a module system worth the
Steve> name but that hasn't stopped people writing some rather large
Steve> programs in it and/or sharing code.
Yes, C's module system is pretty awful, but there's a huge difference
between no module system and a bad one. In C you can #include <foo.h>,
you have no such equivalent in Scheme. "load" will not work in any
remotely portable manner, you need at the very least a search path.
--
Alex
Stephen J. Bevan
> Yes, C's module system is pretty awful, but there's a huge difference
> between no module system and a bad one. In C you can #include <foo.h>,
> you have no such equivalent in Scheme. "load" will not work in any
> remotely portable manner, you need at the very least a search path.
All the search path stuff in C is outside of the language spec. and is
a function of the compiler. In Scheme I just list all the files that
make up the program in a file and totally order them according to any
internal dependencies they might have e.g.
$ cat files
a.scm
b.scm
c.scm
$
A semi-portable way to load the files is then to use a function that
opens this file, reads each line and then calls load on the line.
I used to have a more complicated system whereby the file could
contain load-path and a line could refer to another file which
contained lines of Scheme files (or another file ... etc.) I
eventually gave it up since the complexity just wasn't worth it for
the size of programs I was writing (few thousand lines).
David Rush
> >>>>> "Ben" == Ben Goetter <goe...@mazama.net.xyz> writes:
> Ben> Elsewhere, I see an overall consensus: We Need Modules.
>
> Most definitely. That is probably the single biggest problem facing
> Scheme right now... until we get a module system, the average Scheme
> script will never work on more than one Scheme, no matter how similar
> the Schemes in question. It limits our ability to share code - anything
> from one Scheme always requires munging to work with another. That's
> just sad... I know of no other language with a formal standard for which
> that is the case.
I don't think it's the single biggest problem, and I regularly write
(and reuse 3party code) among 4 or 5 different impls. The real
limiting factor is the *library differences* between Scheme
implementations. Having said that, modularization practices *can* ease
portability issues. But then you have to ask what is meant by 'module
system'.
In Scheme, because of dynamic typing and in the absence of macros,
modularization boils down to namespace management, or, IOW, lexical
scoping. However, most people also want an algebra defined on modules,
and AFAICT, there really isn't any algebra of closures in
Scheme. There are various ways to create one (by carefully structuring
closure interfaces), but there are no operations in the language that
enable a module algebra using closures. You only have access to
the bindings in a closure from inside that closure.
This is not a huge problem:
(define (fib-functor f0 f1 abstract-0 abstract-unit
abstract+ abstract- abstract<=?
body)
(define (fib n)
(cond ((abstract<=? n abstract-0) f0)
((abstract<=? n abstract-unit) f1)
(else
(let* ((n-1 (abstract- n abstract-unit))
(n-2 (abstract- n-1 abstract-unit)))
(abstract+ (fib n-1) (fib n-2))))
))
(body fib))
Now I've chosen horrible names to make what I'm doing painfully clear,
but the above allows you to implement the fibonacci function using all
kinds of wacky representations of numbers. Unfortunately, the only
place where the defined function is accessible is inside the 'body'
function. You can export it to the top-level easily enough:
(define f (fib-functor 1 1 0 1 + - <= (lambda (x) x)))
but that doesn't address the desire of many users for a module
algebra. A nicer (bot not very nice) interface might look a little
bit like:
(define f (fib-functor funny-numeric-structure (lambda (x) x)))
I can think of several ways to implement such a thing (in R5RS), but
they all incur run-time penalties. These could be implemented more
efficiently by the compiler/runtime system, but fundamentally they are
all isomorphic to the verbose solution above.
david rush
--
From the start, when it was the instrument of the wood-god Pan, the
flute has been associated with pure (some might say impure)
energy. Its sound releases something naturally untamed, as if a
squirrel were let loose in a church." --Seamus Heaney
David Rush
> Alex Shinn <fo...@synthcode.com> writes:
> > Ben> Elsewhere, I see an overall consensus: We Need Modules.
> >
> > Most definitely. That is probably the single biggest problem facing
> > Scheme right now...
>
> like foo:bar:baz right now to emulate a hierarchical namespace. If
> the name gets a bit long in a given context then a shorter name can be
> used e.g. (let ((baz foo:bar:baz)) ...).
Indeed, SLIB and others do this already...
david rush
--
... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS.
-- Erik Naggum
David Rush
'#include' isn't very close in semantics to 'load'. Or rather it is,
but I wouldn't have said that either of them has much to do with a
module system. The standard C module system is provided by the
linker. RnRS implicitly takes a whole-program view of Scheme
code. That said, the same namespace segmentation capability is present
through lexical scoping.
david rush
--
Charlie don't surf!
-- Colonel Kilgore in _Apocalypse Now_
Jim Bender
of
papers on related to modules for Scheme (from my Scheme bibliography site):
http://library.readscheme.org/page5.html
Jim Bender
system is really not the primary barrier to re-use of code written for other
Schemes. I use PLT Scheme exclusively, after having been a MacGambit
user for a long time. For me, the easiest step is to wrap a "foreign"
library
in a PLT module. The harder problem is the use of functions or syntax
specific to another Scheme implementation.
And like the RFC's from the IETF, the use of "SRFI-nn" does not really
upset me. Where I am a user of a SRFI, I know it's #, in some other cases,
there is the "threads" SRFI. (And the "real-time threads" SRFI.) This
exactly
mirrors how I deal with RFC's. There are some RFC's for which I know there
number, even though I have never known the precise name of the RFC. In other
cases a particular example is just the "LDAP" RFC. Those who object to
"srfi-nn"
should remember well that the IETF has worked quite well with RFC nnnn for
a long time. And very successfully thank you. We Schemers are not likely to
acheive SRFI-1000 for a long time, but if we can't manage 3 dozen SRFI
numbers,
that is our problem as individual programmers-- not a problem with the SRFI
process.
All of this said, sure, it would be nice to have a standardized module
system, and
for the various SRFI's to make use of this module system in their reference
implementations. But the bigger issue is for more people to work on SRFI's
for well understood, stable pieces of functionality. It's not clear to me
that modules
are there yet.
And I am selfish- w.r.t. module systems, the real questions are whether the
PLT
module system is now stable, and whether other implementers are willing to
adopt
this module system. Given that, for example, Chez Scheme's module system
supports both "first class" modules and "mutually recursive" modules, I
would
guess that the answer to both questions should be "no".
Jim
"David Rush" <ku...@bellsouth.net> wrote in message
news:okf4rdw71...@bellsouth.net...
Ray Blaak
> All of this said, sure, it would be nice to have a standardized module
> system
yes!
> But the bigger issue is for more people to work on SRFI's for well
> understood, stable pieces of functionality. It's not clear to me that
> modules are there yet.
Why not? Why is it so hard for Scheme? Other languages seem to do it just fine.
> And I am selfish- w.r.t. module systems, the real questions are whether the
> PLT module system is now stable, and whether other implementers are willing
> to adopt this module system. Given that, for example, Chez Scheme's module
> system supports both "first class" modules and "mutually recursive" modules,
> I would guess that the answer to both questions should be "no".
Both of these systems seem fine. Scheme48's is quite workable too, though I
prefer to have the module constructs be part of the language proper, mainly
because I want to be able to declare modules anywhere, to nest them,
etc. Modules to me are primarily static namespaces with exported items that
aid in program decomposition whereever needed. They are secondarily units
that aid in library construction.
I also prefer the option of Chez's "always available" qualified names,
e.g. (from M a) to get at binding "a" in module "M", as opposed to systems
that always require explicit imports, prefix specifiers, etc.
But I could live any of them, just as long as there was a standard one.
Here is a proposal for srfi-modules:
Abstract: a basic scheme module system
Rationale: Scheme doesn't have one and that sucks.
Spec: Do it like Chez or PLT Scheme.
Implementation: see Chez or PLT Scheme.
It doesn't really matter about the exact system, just pick one!
Issue: given that every implementation seems to have its own module system,
having (module M ...) should be able to work in conjunction with the
implementation's own module system, since it is unlikely that implementations
will pick up such an srfi if they otherwise have to ditch their own module
systems, at least initially.
One can either standardize with unusual names, e.g., (scope M ...) that
would unlikely interfere with existing module systems, or use controlled
imports to indicate which module system is in effect. I prefer the latter
approach. E.g.
(module M1 ...) ;; a native or implementation-specific module
(require srfi-modules)
(module M2 ...) ;; a portable (srfi) module
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Ray Blaak
If you put a gun to my head and force me to choose between Chez and PLT Scheme
module systems, I pick Chez's.
Why? Because after looking things over, the Chez module system is simple yet
only a few short macros away from making abstract modules and implementors,
mutually-recursive modules, qualified names, etc.
Such an approach seems to be in the spirit of Scheme: elegant yet powerful
building blocks.
Now some PLT Scheme freak can show me that its module system is elegant too,
and I won't disagree, but Chez's seemed to me to be more fundamental and
simpler.
For a proper opinion of course, I should use both seriously, and then report
back on the experience. The one that was the most practical, easiest to use,
powerful, etc. would be the winner.
Ray Blaak
> In article <w7d3ctm...@cs.brown.edu>,
> Shriram Krishnamurthi <s...@cs.brown.edu> wrote:
> >
> > srfi-<number>-<name>
> >
> >What was the argument against that? I rather liked it.
>
> It didn't solve the original problem, which was people disliked
> needing to memorize the numbers (for use when coding).
There are two problems. Reading srfi-NN in code gives no clue what it is
about. Reading srfi-NN-name does.
On the other hand, *writing* srfi-NN or srfi-NN-name still requires one to
know the number.
> (Has anybody proposed srfi-<name>-<index>, where index is used to
> disambiguate multiple SRFIs wanting the same name -- that is,
> index is 00 for the first SRFI requesting/being assigned a given
> name.)
Yes. The problem is that the index is again a number to remember.
A small variation is to make -<index> optional, with encouragement to use
distinct names in preference over tacking on version numbers. That way for
most SRFI's one doesn't have to know the indices either, since there usually
wouldn't be one. E.g.
srfi-simple-objects ;; e.g. a Java-like OO system
srfi-multi-objects ;; e.g. a CLOS-like OO system
When needed, an index/version # could still be used if really necessary, but
in that case it is really just part of the (unique) name:
srfi-simple-objects-2 ;; OOPs! a better version
Matthew Flatt
> If you put a gun to my head and force me to choose between Chez and PLT Scheme
> module systems, I pick Chez's.
>
> Why? Because after looking things over, the Chez module system is simple yet
> only a few short macros away from making abstract modules and implementors,
> mutually-recursive modules, qualified names, etc.
If you have a few minutes before someone finds a gun, please see
http://www.cs.utah.edu/plt/publications/macromod.pdf
That's a paper to appear at this year's ICFP. It explains the motivation
behind the PLT macro+module system.
Although the paper doesn't address the point directly, hopefully it also
gives a sense of why no macro should ever expand to a use of `module' ---
at least with the kind of `module' that we're aiming for.
In other words, PLT's `module' is for just namespace and compilation
management. Abstraction is provided through a different kind of form (which
is implemented by a macro within some `module').
In yet other words, Chez's `module' and PLT Scheme's `module' solve
different problems. I think Chez's `module' would be a useful form
to have within the body of a PLT Scheme `module'. But I also think
that PLT's `module' is the one that solves the portability problem. The
evidence I have is that it solved the portability problem among the
PLT family of tools --- problems that had become quite severe as of
v103, but are resolved in v200.
Matthew
Perry E. Metzger
Ray Blaak <bl...@telus.net> writes:
> But I could live any of them, just as long as there was a standard one.
Somebody say "amen"....
The "modules aren't there yet" concept only makes working in scheme
that much harder.
Perry
Ray Blaak
> If you have a few minutes before someone finds a gun, please see
>
> http://www.cs.utah.edu/plt/publications/macromod.pdf
>
> That's a paper to appear at this year's ICFP. It explains the motivation
> behind the PLT macro+module system.
If I understand correctly, the key point is that the PLT module system
supports separate compilation properly, and that's really really important.
Great. I am all for it.
Can we all agree to standardize on it or something like it?
Matthias Radestock
> mfl...@cs.utah.edu (Matthew Flatt) writes:
>>
>>That's a paper to appear at this year's ICFP. It explains the motivation
>>behind the PLT macro+module system.
>
I doubt that's going to happen. In SISC (http://sisc.sourceforge.net) we
use Chez's module system for the following reasons:
* in terms of functionality it's pretty close to what we were looking
for; it's not perfect though
* there is a "portable" implementation that only has very few, clearly
identified non-standard hooks that need to be provided in order to get
it to work in any Scheme system
* the module system comes as part of the portable syntax-case expander
which we were using anyway
I'd love to use PLT's system, or, even better, PLT + some of the
features of Scheme48's module system. However, the only available
implementations for PLT's and Scheme48's module system have many
intricate dependencies on the underlying Scheme system (i.e. PLT and
Scheme48 respectively).
A specific module system is only going to receive widespread support if
there is a "reasonably portable" implementation for it.
Matthias.
felix
>
> A specific module system is only going to receive widespread support if
> there is a "reasonably portable" implementation for it.
Absolutely. But since most Schemers expect the "mother of all module
systems"-
SRFI, this hasn't happened, yet... (or noone dares to propose one of the
several existing systems, because half of the Scheme users would simply
refuse to use it)
Wouldn't it be a start to build something simple, just to address basic
stuff
like namespace clashes, etc.? One could even leave macros completely out
of it. Well, just something simple, really. Future SRFI's could extend
that system, once some experience has been gained.
cheers,
felix
Shriram Krishnamurthi
> Wouldn't it be a start to build something simple, just to address basic
> stuff
> like namespace clashes, etc.? One could even leave macros completely out
> of it. Well, just something simple, really. Future SRFI's could extend
> that system, once some experience has been gained.
There's *plenty* of experience out there already -- only about twenty
years of it. I scarcely think the lack of experience has been the
problem.
Incidentally, just about every proposal that ignores macros pretty
soon runs squarely into them. This is even harder to ignore now that
macros have become a part of RnRS.
Shriram
Shriram Krishnamurthi
> I doubt that's going to happen. In SISC (http://sisc.sourceforge.net)
> we use Chez's module system for the following reasons:
> [...]
> * there is a "portable" implementation that only has very few, clearly
> * identified non-standard hooks that need to be provided in order to
> * get it to work in any Scheme system
There's an implicit principle behind Scheme, which is that the
implementors do the hard work necessary to bang out the language.
(This principle doesn't seem to be agreed upon widely -- for instance,
Python seems to have repeatedly violated it.) Does SISC share its
implementation of call/cc with Chez Scheme or any other Scheme? I
somehow doubt that, given that you are based on Java. If you can
implement continuations, why can't you implement a module system?
If you want to argue that Chez's module system is better, that's fine.
But your argument essentially boils down to the implementors not
wanting to do their job. That's pretty sad.
Shriram
Perry E. Metzger
felix <felixu...@freenet.de> writes:
> Matthias Radestock wrote:
> > A specific module system is only going to receive widespread support if
> > there is a "reasonably portable" implementation for it.
>
> Absolutely. But since most Schemers expect the "mother of all module
> systems"- SRFI, this hasn't happened, yet... (or noone dares to
> propose one of the several existing systems, because half of the
> Scheme users would simply refuse to use it)
And more fool they.
The problem is not foolish users trying to ruin the perfect Platonic
form of the scheme language by prematurely bringing in these horrible
imperfect module systems and such. The problem is people assuming you
can sit in an ivory tower and figure out what the perfect module
system might be.
Meanwhile, after a decade of discovering that the perfect module
system will not suggest itself, people continue programming in crappy
languages because they have things like standardized name space
management systems and Scheme does not. I think it is astoundingly
pathetic that I can control name spaces better in clean portable C
code than I can in clean portable scheme code.
> Wouldn't it be a start to build something simple, just to address basic
> stuff like namespace clashes, etc.? One could even leave macros
> completely out of it. Well, just something simple, really. Future
> SRFI's could extend that system, once some experience has been gained.
At this point, nearly anything would be an improvement.
--
Perry E. Metzger pe...@piermont.com
--
"Ask not what your country can force other people to do for you..."
Matthias Radestock
>
> There's an implicit principle behind Scheme, which is that the
> implementors do the hard work necessary to bang out the language.
> (This principle doesn't seem to be agreed upon widely -- for instance,
> Python seems to have repeatedly violated it.) Does SISC share its
> implementation of call/cc with Chez Scheme or any other Scheme? I
> somehow doubt that, given that you are based on Java. If you can
> implement continuations, why can't you implement a module system?
>
> If you want to argue that Chez's module system is better, that's fine.
> But your argument essentially boils down to the implementors not
> wanting to do their job. That's pretty sad.
Are you saying that it is the implementors' job to implement every
single feature from scratch? *That* would be pretty sad.
I quite clearly said that I'd love to use PLT's module system instead of
Chez's and that the main reason for not doing so is the lack of a
"reasonably portable" implementation of the former.
FYI, SISC's call/cc and dynamic-wind heavenly borrow from Scheme48's
implementation of these procedures. We generally try to re-use code from
other Schemes as much as we can, so that we can focus our resources on
the features that make SISC unique (rather than simply "different").
My main poiny is that IF you want multiple Schemes to support a
particular non-trivial feature (i.e. a module system) then you MUST
provide a reasonably portable implementation of that feature. Otherwise
implementors will not implement the feature at all, implement it in a
way that is incompatible with your implementation, or implement a
completely different solution.
Evidence of this is abundant. For instance, most SRFIs and SLIB are
reasonably portable (as well as being reasonably useful and reasonably
well implemented) and consequently have been implemented by many Schemes.
Matthias.
Shriram Krishnamurthi
> Are you saying that it is the implementors' job to implement every
> single feature from scratch?
No, I said nothing of the sort.
> My main poiny is that IF you want multiple Schemes to support a
> particular non-trivial feature (i.e. a module system) then you MUST
> provide a reasonably portable implementation of that
> feature.
And what if the feature isn't implementable in Scheme? What if the
module system requires you to export locations rather than values?
> Otherwise implementors will not implement the feature at all,
> implement it in a way that is incompatible with your implementation,
> or implement a completely different solution.
I'll go back to the same example I gave before: suppose Scheme lacked
call/cc and someone added it. There are no source-library
implementations of call/cc (indeed, there cannot be). Somehow, almost
all these different implementors have managed to implement it in a way
that is compatible, right?
> FYI, SISC's call/cc and dynamic-wind heavenly borrow from Scheme48's
> implementation of these procedures.
An amusing typo ("heavenly"), for sure. That said, I don't know what
"heavily borrow" means. Let's stick to the context at hand: Copied
code? Verbatim? So that future changes to S48's implementation can
be automatically plugged right into SISC without so much as reading
what they changed?
Shriram
felix
>
> felix <felixu...@freenet.de> writes:
>
> > Wouldn't it be a start to build something simple, just to address basic
> > stuff
> > like namespace clashes, etc.? One could even leave macros completely out
> > of it. Well, just something simple, really. Future SRFI's could extend
> > that system, once some experience has been gained.
>
> There's *plenty* of experience out there already -- only about twenty
> years of it. I scarcely think the lack of experience has been the
> problem.
You are probably right. But despite of this experience, nobody
so far is able to agree on specifics. So there is experience but no
consensus, syntactically or semantically.
>
> Incidentally, just about every proposal that ignores macros pretty
> soon runs squarely into them. This is even harder to ignore now that
> macros have become a part of RnRS.
Basically I agree, but if there is such a desperate need for a module
system, then one might have to start with a simple and *portable*
solution.
If you ignore macros, you can get going with *something*, at least.
Look at SLIB, which manages a very large code-base, just with a little
bit
of naming-discipline.
I'm not saying the simple solution is in any way optimal, but, in the
interest of making Scheme more attractive as a general-purpose,
real-world
programming language some pragmatism might be called for.
Unfortunately, pragmatism has not a very strong position in the Scheme
world.
cheers,
felix
Alexander Schmolck
> There's an implicit principle behind Scheme, which is that the
> implementors do the hard work necessary to bang out the language.
> (This principle doesn't seem to be agreed upon widely -- for instance,
> Python seems to have repeatedly violated it.) Does SISC share its
I guess this is somewhat off-topic but in what sense have the python
implementors shunned the hard work?
alex
Michael Sperber [Mr. Preprocessor]
Matthias> I'd love to use PLT's system, or, even better, PLT + some of the
Matthias> features of Scheme48's module system. However, the only available
Matthias> implementations for PLT's and Scheme48's module system have many
Matthias> intricate dependencies on the underlying Scheme system (i.e. PLT and
Matthias> Scheme48 respectively).
Actually, the module system of Scheme 48 is very portable and can be
made to run in just about any other Scheme implementation very
easily.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
felix
>
> >>>>> "Matthias" == Matthias Radestock <matt...@sorted.org> writes:
>
> Matthias> I'd love to use PLT's system, or, even better, PLT + some of the
> Matthias> features of Scheme48's module system. However, the only available
> Matthias> implementations for PLT's and Scheme48's module system have many
> Matthias> intricate dependencies on the underlying Scheme system (i.e. PLT and
> Matthias> Scheme48 respectively).
>
> Actually, the module system of Scheme 48 is very portable and can be
> made to run in just about any other Scheme implementation very
> easily.
>
How? I'm especially interested how this module system interacts
with the host's macro-system and how to approach batch-compiling
implementations.
Any links? Which source files should I look at first? Are there
any implementation-dependent hooks clearly marked?
What exactly do you mean with "just about any other Scheme" and "very
easily"?
If it's so easy, why does nobody else use it (besides the scaled down
version used in librep).
I'm genuinely interested.
cheers,
felix
Michael Sperber [Mr. Preprocessor]
felix> Any links? Which source files should I look at first? Are there
felix> any implementation-dependent hooks clearly marked?
felix> What exactly do you mean with "just about any other Scheme" and "very
felix> easily"?
Around version 0.48, I used to load the whole thing into Bigloo. Back
then, it would pretty much load into any R5RS-based Scheme. (Back
then I wrote code to spit out Bigloo module declarations equivalent to
Scheme 48. It was very painful because of the limitations of the
Bigloo module system at that time, but it worked.)
I haven't checked with more recent ones, but I don't see why that
particular aspect of the code should have changed. If you look how
bootstrapping is done, you'll see that the linker image is actually
code loaded into a near-R5RS environment within Scheme 48. More
specifically, a lot of the Scheme-48-specific support code has
portable versions living in the scheme/alt subdirectory.
felix> If it's so easy, why does nobody else use it (besides the scaled down
felix> version used in librep).
I'm the wrong person to ask that, I guess.
Shriram Krishnamurthi
> > There's *plenty* of experience out there already -- only about twenty
> > years of it. I scarcely think the lack of experience has been the
> > problem.
>
> You are probably right. But despite of this experience, nobody
> so far is able to agree on specifics. So there is experience but no
> consensus, syntactically or semantically.
I think you're talking through your hat. There is widespread
understanding amongst the people who think about these things that
there are several different uses of modules, that these uses are often
orthogonal but sometimes competing, what these uses are, and how
different module constructs affect the uses. Two major issues are
modules as a carrier of separate compilation vs modules as a vehicle
for high degrees of code reuse. This is why, for instance, PLT Scheme
has *two* module constructs in the same language.
I suspect that if you independently quizzed, say, Sperber, Serrano and
Flatt, they would all give you roughly similar answers as to what
their module systems do and why and how they relate to each others'.
They could pinpoint the semantic differences for sure, maybe even the
syntactic ones. (Actually, you could leave Serrano and Flatt free to
roam on the range and ask Sperber alone -- he's the compendium.)
Shriram
Shriram Krishnamurthi
> I guess this is somewhat off-topic but in what sense have the python
> implementors shunned the hard work?
Weak modules, poor GC, broken closures come to mind.
Shriram
Michael Sperber [Mr. Preprocessor]
Shriram> felix <felixu...@freenet.de> writes:
>> > There's *plenty* of experience out there already -- only about twenty
>> > years of it. I scarcely think the lack of experience has been the
>> > problem.
>>
>> You are probably right. But despite of this experience, nobody
>> so far is able to agree on specifics. So there is experience but no
>> consensus, syntactically or semantically.
Shriram> I think you're talking through your hat. There is widespread
Shriram> understanding amongst the people who think about these things that
Shriram> there are several different uses of modules, that these uses are often
Shriram> orthogonal but sometimes competing, what these uses are, and how
Shriram> different module constructs affect the uses. Two major issues are
Shriram> modules as a carrier of separate compilation vs modules as a vehicle
Shriram> for high degrees of code reuse. This is why, for instance, PLT Scheme
Shriram> has *two* module constructs in the same language.
Shriram's right. Several people have asked for "something" simple,
but they sure haven't stated clearly what problem they're trying to
solve. Here are some more axes along which you need to state where you
want to go:
- Do you want parametricity? If you want that, explicit or implicit?
- Do you want a static or a dynamic module system?
- Do you want your module system also to be a package system which
manages a global namespace of modules as well as how to get at them
when they are sitting somewhere on your hard drive?
Moreover, there are cross-dependencies between some of the relevant
questions. Because of macros, precious few of them are trivial to
answer.
Different implementors make different choices as to what problems they
need solved, and hence the different module systems. I suspect most
people who've been asking for "something simple" primarily want a
package system. This, I'd say, is the major difference between Chez's
system and PLT's: Chez's doesn't address the package issue at all,
PLT's does. Hence the different design decisions. Deciding between
the two on the basis of the more readily available implementation is
therefore misguided.
Perry E. Metzger
And yet, Python has succeeded, and Scheme has not yet succeeded. I
would suspect part of that is that the Python folks didn't take
decades to answer basic usability questions for their language.
Yes, I agree, there are a lot of choices in module systems,
etc. If the purpose of Scheme is to be a programming language in daily
use rather than an exercise in programming language design, then
the relevant parties should come to a (possibly broken) decision.
David Rush
> If the purpose of Scheme is to be a programming language in daily
> use rather than an exercise in programming language design,
I've used it daily (and gotten paid for it) for the last two years.
david rush
--
Both CL and Scheme have excellent pros to learn from found in either
c.l.l and c.l.s and both are not without cons. I guess you cdr saw
that one coming...
-- George Demmy (on comp.lang.scheme)
Perry E. Metzger
David Rush <ku...@bellsouth.net> writes:
> "Perry E. Metzger" <pe...@piermont.com> writes:
> > If the purpose of Scheme is to be a programming language in daily
> > use rather than an exercise in programming language design,
>
> I've used it daily (and gotten paid for it) for the last two years.
The problem is, however, that you can't write portable scheme code
because these things haven't been dealt with. As a result of this, I
can get huge amounts of portable software and software libraries out
there written for Perl, C, C++, Ruby, Python, etc., etc., but if I
want to try to write such code in Scheme I have to carefully avoid
using the vast array of constructs such as modules the implementation
I've chosen implements.
Jens Axel Søgaard
> The problem is, however, that you can't write portable
> scheme code because these things haven't been dealt with.
> As a result of this, I can get huge amounts of portable
> software and software libraries out there written for
> Perl, C, C++, Ruby, Python, etc., etc.,
Python is a bad example. There is only one (two?) implementations,
so it is easy to be portable amongs implementations.
To me portability between platforms are more important than
portability among implementations, so I picked a
implementation that runs on both Windows and Linux.
--
Jens Axel Søgaard
Stephen J. Bevan
> The problem is, however, that you can't write portable scheme code
> because these things haven't been dealt with. As a result of this, I
> can get huge amounts of portable software and software libraries out
> there written for Perl, C, C++, Ruby, Python, etc., etc., but if I
> want to try to write such code in Scheme I have to carefully avoid
> using the vast array of constructs such as modules the implementation
> I've chosen implements.
If you want your Scheme to run on multiple implementations I agree.
But if that is the case then Perl, Ruby and Python are not the best
examples since users of those languages don't really have to worry
that much about portability, they just write for a specific (usually
sole) implementation. All Scheme users have the same option.
Thomas Bushnell, BSG
> The problem is, however, that you can't write portable scheme code
> because these things haven't been dealt with. As a result of this, I
> can get huge amounts of portable software and software libraries out
> there written for Perl, C, C++, Ruby, Python, etc., etc., but if I
> want to try to write such code in Scheme I have to carefully avoid
> using the vast array of constructs such as modules the implementation
> I've chosen implements.
You've got to be kidding!
You are saying that people are using C and C++ because Scheme lacks a
module system?
Peter Keller
Well, in short, he's prolly saying people use C and C++ because it can
talk to berkely sockets, various POSIX interfaces, and well known APIs in
libraries that have been created over the years so that it becomes very
useful to use those languages. You can do a lot in a short period of time.
I'm not sure people so much as want a module implementation as
a consistant API to the world outside the language itself that works
across many different implementations. In my mind, who cares if you
declare something in some dumb module, I'd rather write all the code
somewhere and either include it directly, or use a simple chicken like
(declare (uses lib-foo)) type thing and just have access to all of the
functions provided to me. An example is that I can write a C program to
use OpenGL *no matter what compiler I use to compile it*! Scheme can't
do that, and as long as it can't people aren't going to use it.
The way it is now, some schemes have a socket interface(or any other
feature X), others don't, maybe it exists at wierd levels(super high
level, or super low level). That's the problem. There isn't "berekely
sockets" for scheme, just various peoples implementation of something
sort of similar. No compatibility, no source code reuse. Simple.
You want a module system? Here's one:
;; unless specified, everything defaults to public
(declare-module foobar
(with-files "foo.scm" "bar.scm" "thingy.scm")
;; functions out of the various files above
(private-functions func1 func2 func3)
(private-bindings *count* *stuff* *thing*))
Then to use it:
(declare (use-module foobar))
Got namespace collision between modules? The compiler or interpreter
*should tell you* and you use some simple C++ like resolution system such
as foobar::func1 to call the function worried about. (I realize :: is being
looked at for a different use, namely type annotation, but bear with me).
If you yell at me that the above doesn't solve all problems, I respond by
saying, it probably doesn't have to solve ALL of them, the the ones that
other languages seemed to have solved.
In reality, you only need a few things to have a module system,
the ability to provide public and private function and data members,
simple namespace resolution, and really, this is the kicker, _first
class macros_. The first part is easy, and a lot of people do it all
ready but argue about the syntax of it. The second is more interesting
since it could provide a way to define a macro in a module, and then be
able to use it later somewhere else after it has been compiled. Also,
get rid of non-r5rs macros, scheme just needs one form. Two forms just
make it complicated and hard and if they are not compatible, and usually
aren't, it provides yet another schism in the code people write to have it
not work together, etc.
Reduce the complexity and redundency in the extensions to the language
and more people will use it for more things since idiomatic uses will
become more widely known and useable across implementations.
My two cents.
--
-pete
E-mail address corrupted to stop spam.
Reply mail: psilord at cs dot wisc dot edu
I am responsible for what I say, noone else.
Jens Axel Søgaard
> Thomas Bushnell, BSG <tb+u...@becket.net> wrote:
>> You've got to be kidding!
>
>> You are saying that people are using C and C++ because
>> Scheme lacks a module system?
>
> Well, in short, he's prolly saying people use C and C++
> because it can talk to berkely sockets, various POSIX
> interfaces, and well known APIs in libraries that have
> been created over the years so that it becomes very
> useful to use those languages. You can do a lot in a
> short period of time.
>
> I'm not sure people so much as want a module
> implementation as a consistant API to the world outside
> the language itself that works across many different
> implementations. In my mind, who cares if you declare
> something in some dumb module, I'd rather write all the
> code somewhere and either include it directly, or use a
> simple chicken like (declare (uses lib-foo)) type thing
> and just have access to all of the functions provided to
> me. An example is that I can write a C program to use
> OpenGL *no matter what compiler I use to compile it*!
> Scheme can't do that, and as long as it can't people
> aren't going to use it.
That is indeed a problem that deserves a solution.
Lars Thomas Hansen has made a beginning in FFIGEN.
http://www.ccs.neu.edu/home/lth/ffigen/index.html
On the other hand if one make SWIG generate "portable"
code for several Schemes at once, then one could benefit
from the work done by Beazley and others.
Currently SWIG supports Guile and MzScheme103.
--
Jens Axel Søgaard
Ray Blaak
> ;; unless specified, everything defaults to public
> (declare-module foobar
> (with-files "foo.scm" "bar.scm" "thingy.scm")
> ;; functions out of the various files above
> (private-functions func1 func2 func3)
> (private-bindings *count* *stuff* *thing*))
Default to private instead. It is safer to constructively say what you are
exporting as opposed to tediously say what you are *not* exporting.
Don't refer to raw file names for importing -- too OS dependent, too little
structure. Instead, refer to module names, and rely on either a standard or
implementation defined way of mapping modules to where their sources are. That
way only proper modules can be imported as opposed to arbitrary uncontrolled
code.
> Got namespace collision between modules? The compiler or interpreter
> *should tell you* and you use some simple C++ like resolution system such
> as foobar::func1 to call the function worried about. (I realize :: is being
> looked at for a different use, namely type annotation, but bear with me).
:: is not being used for type annotation in any standard way. Maybe bigloo is
doing it, but its use is plain wierd. There is nothing wrong with (Kawa's?)
var :: <type> approach, in which :: is only special in certain situations, and
not when embedded into another symbol.
Also, qualified names need not have separators at all -- they can be
SEXPs. E.g. (foobar func1) or Chez's (from foobar func1).
> In reality, you only need a few things to have a module system [...] _first
> class macros_. [...] is more interesting since it could provide a way to
> define a macro in a module, and then be able to use it later somewhere else
> after it has been compiled.
Why do macros need to be compiled? What form would they be compiled into?
Perhaps macros can always be represented as source -- one then need not have a
complicated alternative binary representation that also has to be maintained.
Only dependencies to the source code need to be maintained. Always parsing
sources is likely to be fast enough in practice (i.e. not much slower, if at
all, than reading binary object files and reconstructing code trees from
them).
What matters in the end is to only compile only fully expanded code.
GNAT, the Gnu Ada compiler, takes such a source based approach with its
library system: generics (the Ada equivalent of Scheme macros, or C++
templates) undergo syntax and semantic checking, but their persistent form is
source code.
This has worked well for GNAT (allowing huge simplications as compared to the
traditional way of maintaining compiled Ada library repositories), and I
suspect it could work well for Scheme too.
Peter Keller
: Peter Keller <psi...@data.upl.cs.wisc.edu> writes:
:> ;; unless specified, everything defaults to public
:> (declare-module foobar
:> (with-files "foo.scm" "bar.scm" "thingy.scm")
:> ;; functions out of the various files above
:> (private-functions func1 func2 func3)
:> (private-bindings *count* *stuff* *thing*))
: Default to private instead. It is safer to constructively say what you are
: exporting as opposed to tediously say what you are *not* exporting.
Ok. I can agree with that.
: Don't refer to raw file names for importing -- too OS dependent, too little
: structure. Instead, refer to module names, and rely on either a standard or
: implementation defined way of mapping modules to where their sources are. That
: way only proper modules can be imported as opposed to arbitrary uncontrolled
: code.
Ok, this is a little bit more of an abstraction, but not so much as to be
outside of the simplicity of it. You're saying each file would contain the
above looking declaration(minus the with-files bit) to define a "compilation
unit" or some such thing. I can agree with that ( See P.S. ).
:> Got namespace collision between modules? The compiler or interpreter
:> *should tell you* and you use some simple C++ like resolution system such
:> as foobar::func1 to call the function worried about. (I realize :: is being
:> looked at for a different use, namely type annotation, but bear with me).
: :: is not being used for type annotation in any standard way. Maybe bigloo is
: doing it, but its use is plain wierd. There is nothing wrong with (Kawa's?)
: var :: <type> approach, in which :: is only special in certain situations, and
: not when embedded into another symbol.
Eh, just pick something sane and be done with it.
: Also, qualified names need not have separators at all -- they can be
: SEXPs. E.g. (foobar func1) or Chez's (from foobar func1).
This makes sense considering the look and feel of scheme. But it is
nice to have a visual resolver(like you can easily see it in the code)
for a symbol conflict between multiple libraries. This will red flag the
viewer of the code that there was a name conflict there.
: Why do macros need to be compiled? What form would they be compiled into?
: Perhaps macros can always be represented as source -- one then need not have a
: complicated alternative binary representation that also has to be maintained.
: Only dependencies to the source code need to be maintained. Always parsing
: sources is likely to be fast enough in practice (i.e. not much slower, if at
: all, than reading binary object files and reconstructing code trees from
: them).
: What matters in the end is to only compile only fully expanded code.
Ok, so store the source code to macros themselves into the compilation units
if any, but you still have to treat them as first class-like objects since you
can "export" the name of the macro out of the module to be used in other
code.
: GNAT, the Gnu Ada compiler, takes such a source based approach with its
: library system: generics (the Ada equivalent of Scheme macros, or C++
: templates) undergo syntax and semantic checking, but their persistent form is
: source code.
: This has worked well for GNAT (allowing huge simplications as compared to the
: traditional way of maintaining compiled Ada library repositories), and I
: suspect it could work well for Scheme too.
Possibly, but I don't know Ada or how it implementes this, so I can't comment.
-pete
P.S. A module system definition:
in each file, you make it a "compilation unit".
(define-unit unitname
;; all symbols are public by default, so specify private ones
(private func0 func1 var0 var1))
Then you can collect the units into a module(usually in it's own .scm file):
(define-module modulename
;; all public functions are allowed, but you can restrict this set here
;; in this example func34 and var33 were public from thier unit, but
;; I'm not going to allow it to be public when using the module itself.
(with-units unitname)
(private func34 var33)
Then, when you use the module in a scheme file:
(declare (uses modulename))
Now, there are two things we can do:
If you "use" a modulename, then that file that you used it in
automatically propogates the public symbols of said module from its
compilation unit namespace to the current namespace.
or:
Using a module will NOT propogate the public symbol names meaning you have
to use it in every file you want to use it in.
I prefer the second approach, and if I want the bindings of one library
available when I use another, I can do this:
(define-module modulename2
(with-units unitname)
(with-modules modulename)
(private func34 var33)
Now, treat macros in such a way that the use of a macro can cross
unit/module boundaries(I don't care how it is implemented, only that
the functionality exists), and boom, this is what people want...
...in my humble opinion. :)
Ray Blaak
> [...] you still have to treat [macros] as first class-like objects since you
> can "export" the name of the macro out of the module to be used in other
> code.
Absolutely.
> P.S. A module system definition:
>
> in each file, you make it a "compilation unit".
>
> (define-unit unitname ...)
[...]
> (define-module modulename ...)
Major simplification: a module *is* a unit. Everything lives in a
module. Modules can use/import other modules.
Also, really, default to private and export only the public things. Every
existing scheme module system that I know of does this, and for a good reason.
Perry E. Metzger
tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> You've got to be kidding!
>
> You are saying that people are using C and C++ because Scheme lacks a
> module system?
No. I'm saying it is sad that a language as half-assed as C has a more
cleanly standardized set of basic functionality needed for day to day
work.
David Rush
> David Rush <ku...@bellsouth.net> writes:
> > "Perry E. Metzger" <pe...@piermont.com> writes:
> > > If the purpose of Scheme is to be a programming language in daily
> > > use rather than an exercise in programming language design,
> >
> > I've used it daily (and gotten paid for it) for the last two years.
>
> The problem is, however, that you can't write portable scheme code
I regularly run on 4 different Scheme platforms (Scheme48, PLT,
Larceny, Bigloo). My code seems pretty portable. Most (80%) of it also
runs on Stalin and Gambit, which are only R4RS.
I find Scheme to be fairly portable.
david rush
--
Research is what I am doing when I don't know what I am doing."
-- Wernher von Braun
David Rush
> > You've got to be kidding!
> >
> > You are saying that people are using C and C++ because Scheme lacks a
> > module system?
>
> No. I'm saying it is sad that a language as half-assed as C has a more
> cleanly standardized set of basic functionality needed for day to day
> work.
That's because the OS was written in it. Please compare apples to apples.
david rush
--
By loudly denouncing all bad things - war and hunger and date
rape - liberals testify to their own terrific goodness.
-- P. J. O'Rourke
Stephen J. Bevan
> > You've got to be kidding!
> >
> > You are saying that people are using C and C++ because Scheme lacks a
> > module system?
>
> No. I'm saying it is sad that a language as half-assed as C has a more
> cleanly standardized set of basic functionality needed for day to day
> work.
I think it is sad that a half-assed OS such as Windows has a more cleanly
standardized interface for languages other than C than Unix does.
However, that doesn't stop me programming Unix in languages other than C.
Peter Keller
:>
:> in each file, you make it a "compilation unit".
:>
:> (define-unit unitname ...)
: [...]
:> (define-module modulename ...)
: Major simplification: a module *is* a unit. Everything lives in a
: module. Modules can use/import other modules.
Not bad. I like. :) Nice and simple.
: Also, really, default to private and export only the public things. Every
: existing scheme module system that I know of does this, and for a good reason.
What is the reason? Why do some people say have all symbols be public and
you specify the private ones, and some say the other way? I honestly think
though you are right, but since C did it this way(everything public in a
.c file unless specified otherwise), I figure follow the convention. But
I can easily see why you'd want it the other way, and I would change my
mind to have it be everything private and you specify the public stuff.
Do you think my little module thing is enough for an SRFI? I don't really
care about the politics/holy war concerning "module systems". I just
want to propose something that will work for 95% of the things people
need it for, is simple as hell, and try to get people to implement it.
If a scheme implementation already has something this simple, then we should
"standardize" it and try to get other implementors to implement it too.
Ray Blaak
> : Also, really, default to private and export only the public things. Every
> : existing scheme module system that I know of does this, and for a good reason.
>
> What is the reason?
The reasons are a) safety and b) ease of use.
Safety because with a public default it is trivially easy to accidentally make
more things public than is necessary for good encapsulation, and exposing too
many internals is usually to the detriment of maintainable bug-free software.
Ease of use because in a typical implementation, far more things are private
than they are public, so it is less work to only need to specify the public
things.
> Do you think my little module thing is enough for an SRFI? I don't really
> care about the politics/holy war concerning "module systems". I just
> want to propose something that will work for 95% of the things people
> need it for, is simple as hell, and try to get people to implement it.
I would go with an existing implementation's module system for the reasons
that a non-trivial set of Scheme programmer's are used to it, presumably many
problems have been worked out, issues thought through, etc.
> If a scheme implementation already has something this simple, then we should
> "standardize" it and try to get other implementors to implement it too.
For simplicity, I would pick Chez's system. For generality, though (and not
really that much more complexity), PLT Scheme's system seems to do separate
compilation properly (e.g. the exported macro problem). (I am trying to
convince myself that it is really a problem, though, and that Chez's module
system indeed can't handle it -- more study is required.)
Michael Sperber [Mr. Preprocessor]
Peter> Do you think my little module thing is enough for an SRFI?
There sure is a ton of specification missing at this point.
Michael Sperber [Mr. Preprocessor]
Ray> For simplicity, I would pick Chez's system. For generality, though (and not
Ray> really that much more complexity), PLT Scheme's system seems to do separate
Ray> compilation properly (e.g. the exported macro problem). (I am trying to
Ray> convince myself that it is really a problem, though, and that Chez's module
Ray> system indeed can't handle it -- more study is required.)
People really need to get it into their heads that these two systems
do different things: Chez's module system is a purely syntactic
mechanism. (The title of the original paper on it doesn't even
contain the word "module.") PLT's module system is a package
mechanism with proper separate compilation and phase separation. It
would probably be useful to have both in the same system. But as
tools, they are about like hammer and screwdriver: there's some
relationship, but you don't really want to use one when you really
need the other.
David Rush
> Ray Blaak <bl...@telus.net> wrote:
> : Peter Keller <psi...@data.upl.cs.wisc.edu> writes:
> :> P.S. A module system definition:
> Do you think my little module thing is enough for an SRFI?
Once you write an implementation of it, yes. A standalone R5RS Scheme
program that just uses read and produces a single source file would be
sufficient. This is mostly to clarify your semantics, but it will also
make it far more usable...
> I don't really
> care about the politics/holy war concerning "module systems". I just
> want to propose something that will work for 95% of the things people
> need it for, is simple as hell, and try to get people to implement
> it.
That's the difficult bit, actually. You'll need to convince
implementors (who generally already have module systems) to implement
your system in ways that are compatible with what they already
have. That's why I suggest that you build an independent
implementation. It has worked for SLIB.
> If a scheme implementation already has something this simple, then we should
> "standardize" it and try to get other implementors to implement it too.
Have you tried programming in Bigloo? What you have specified is
nearly identical to its system. If you extend it (Bigloo's system)
slightly to have multiple modules per source file, I think it is
exactly identical, but I haven't paid a lot of attention to your proposal.
david rush
--
If being bathed by ky00tness is like floating among the clouds on a
sunny day, a brisk grinchtron exposure has been compared to flying
through a thunderstorm on Io while listening to the louder bits of
Wagner at full volume. -- Dr. Lawrence Kralk (on alt.devilbunies)