xxxxxx@autodrip.bloodandcoffee.net wrote:
>>
>>Because we think that SRFI-7 is not simple enough and not straightforward
>>enough to be really useful.
>
>
> Come _on_.  It's a _simple_configuration_langauge_.  It's not like you
> have to relearn Scheme all over again or anything.  It's hardly more
> complicated than learning a new special REQUIRE-EXTENSION form.
>

I agree it's really not hard to learn, but it's unneccessarily cumbersome
(IMHO).

>>
>>This is mainly about making it easier for users. You put too much
>>emphasis on implementors.
>
>
> Excuse me?  This is a Scheme Request for Implementation.  There won't
> _be_ users if it can't be implemented, or certain Schemes will be
> _alienated_ due to _your_ personal taste!

SRFI-55 can't be implemented? How come? (and please don't make the mistake
of judging from a _single_ implementation)

>
> You have given me a vague, hand-wavy sentence about Schemes with very
> rudimentary module systems

PLT? rudimentary?

> and your aesthetic tastes.  That is not an adequate answer.

Yeah, sure. How about your aesthetic tastes?

>
>>Technically, I don't see a problem with both SRFI-0 and SRFI-55.
>
>
> You are rather blind, then.  Please, _READ_ the SRFI 0 discussion
> archive, and notice that Feeley _never_ even _responded_ to the last
> few arguments against his proposal and for a separate configuration
> language!

So, then I'm blind. Thank you!

So Feeley never responded. What does that change? Does that fact alone
make SRFI-0 useless? Why are so many Schemes implementing it, then?
Are all those implementors blind too?

>
> You're using the same argument as is used in SRFI 50, Felix: 'if your
> Scheme is simple enough and has this pre-determined architecture, you
> can use this SRFI.'

This is in fact wrong. `require-extension' isn't necessarily simple, it's
just easy to use. See the PLT documentation about `require' how it can
be done inside a very powerful module system.

(it's amazing to see how this fact is stubbornly ignored)

>  This is _NOT_ the right way to specify SRFIs.

So what it the right way? - tell me.

 > SRFI 7
> can be implemented to expand to code that uses REQUIRE-EXTENSION if
> your Scheme fits into that category of pre-determined architectures
> with either overly simplistic or no module systems, but it can also be
> implemented in terms of a much more sophisticated module system like
> that of Scheme48's -- where REQUIRE-EXTENSION does _NOT_ work --, or it
> could expand to a PLT module -- in which more information can be
> encoded than with just a sequence of bare S-expressions --.  But you
> are arbitrarily choosing to alienate certain implementations because of
> your personal taste!

I think not. See above and all previous e-mails. Scheme48 may not be able
to implement it, which I personally find unfortunate. Chicken will not
be able to implement SRFI-21, but I don't feel alienated at all.

>
> Do you really think fracturing it more is going to help?  One of the
> main goals of SRFIs is to _mend_ these fractures!
>

I think SRFI-55 could standardize a common form for several similar,
already existing forms (which *do* exist).

>
> We have SRFI 7 because the author of SRFI 0, just like you, obstinately
> continued with his SRFI even with strong arguments against it.  Seven
> SRFIs later, the problem was _fixed_ with a configuration language that
> _avoided_ all sorts of problems.  Forty-eight SRFIs after that, you're
> trying to _break_ it again!

Ahem, nobody is using SRFI-7, at least, I haven't heard or seen about anybody
doing so, being a regular follower of c.l.s and #scheme. Moreover, the number
of implementations supporting it is rather small, compared to the number
of implementations supporting SRFI-0. I see a tendency here. Why are you
ignoring this fact?

>
>
> How many quick scripts do you write to be portable across multiple
> Scheme implementations?  I sincerely doubt that you write _any_, and so
> it's _not_worth_it_ to try to standardize what will keep you from
> writing a couple keystrokes in quick scripts that will be used for only
> one particular implementation.  For those quick scripts that are
> implementation-specific, you can still use whatever mechanism you find
> to have fewer keystrokes, but please, don't base SRFIs off of these
> saved keystrokes for programs that are going to implementation-specific
> anyways.

No, I don't write many portable scripts. Yet, in writing non-portable
scripts, I like to have convenience at my fingertips. Is this so
undesirable? Am I completely alone on this planet, who likes easy
coding? Do I have to learn Python or Perl do have the right to like
things easy?

>
> Aesthetic pleasantry is _not_ at issue here.  Again, you're using the
> _same_ argument tactics as were used to defend SRFI 50: 'Pika-style or
> JNI-style conventions might be technically superior, but SRFI 50
> conventions meet our tastes better'; 'SRFI 0-style & SRFI 55-style
> feature requirement/conditional forms meet Felix's taste better.'

Yes, you are repeating yourself somewhat...

>
>>Anyway, all this doesn't convince me at all. If you don't like SRFI-55,
>>ignore it. If you are afraid this proposal will further fracture the
>>Scheme community, then I think this small "fracturing" is acceptable,
>>since we are not talking about a fundamental interface which will
>>influence a large body of code (like, say, SRFI-50...).
>
>
> Gee, you don't think _feature_requirement_ will be used in large bodies
> of code?

So I'll have a couple of lines containing
`require-extension' (or whatever) forms. That's quite a difference to, say,
a complete GTK2 wrapper library written according to SRFI-50.
I can change the former easily, I can't do that with the latter.

>
>
>>I just wonder why it already exists and is heavily used (albeit disguised
>>as `require', 'use', or various combinations of `load' and 'import').
>>That is what surprises me.
>
>
> SRFI 50-style conventions are also pretty widely used.  Stop using the
> tactics that are used to defend SRFI 50, Felix, if you're going to
> complain about those same tactics just in the context of SRFI 50.

If you read what I wrote above, you might see the difference between those
two SRFIs, and the amount of "damage" they could cause.

You cleverly avoid answering the fundamental question:

"How come others can do it?"

cheers,
felix