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

Re: problems with rationale & design

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



campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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