This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Suggestion: New Guile mailing list


> From: Mikael Djurfeldt <mdj@nada.kth.se>
> 
> People don't like when we discuss Guile development internally.
> But people don't like when we discuss on the guile list either,
> because such discussions can generate a lot of traffic.
> What about creating a new public list `guile-devel'?

Oh, oh.  I thought I had been mis-understood and composed a long
explanation.  Then I decided it didn't matter much if I was understood
and did not send it.  Maybe I should.

Executive summary:
  Don't make a new list.  Don't think I'm a stupid whiner.
  Still prefer SETF! to SET! for extended semantics,
    still want a module, not another hack in eval.c.

------------- kwright explains himself: ----------

kwright> Quite a relief, I think, after that heavy load of
 Object-Oriented Setf! messages.

mdj> It is a good thing to be able to discuss a new feature with others.

Discussion is Good.  Note: I am not complaining, I like to know
what is happening, but I reserve the right not to read every word.

mdj> Personally, I'd prefer to discuss things on the other list, since
 I'd like to put more time into writing code instead of talking.

Coding is Good.  I don't know why the time required for discussion
should depend upon the list---unless you are saying the core developers
already had a complete plan for Object-Oriented SET! extensions, and
that whole discussion was just know-nothings arguing over moot points.
In that case I am more glad I did not follow every word.

Jim Blandy has not had anything to say about SETF!, and without that
it is hard to tell who is saying how it will be done, and who is
just opinionating.  Hence my question as to the final result of
the SETF! discussion.

kwright> and I really don't care.

mdj> That is OK, but then, please don't expect people to listen.

Maybe I should clarify.  I don't much care about O-O extensions
to Scheme, because I think it works fine without them, and because they
are a subject of much obscure argument with no theorem at the end.
I do care about Guile, and would hate to see it crufted up.

mdj> I would very much like Guile to be a Scheme interpreter + useful
 libraries.  I'm much more afraid of language bloat than of code bloat.
mdj> I'd also like the Guile language (whatever that will finally be)
 to be easy to compile to efficient code.
mdj> I don't think the new set! syntax is useful enough to motivate
 the added complexity to the language and the new constraints for new
 Guile interpreters and compilers.

I am agreeing with all this.  Did the discussion finally result in
consensus on a plan that meets these goals? ...

mdj> It's a bit sad that I'm the only one that previously tried to protect
the simplicity of the language.

... Or did the advocates of complicated cruft beat you down?

kwright> (1) Whatever it is, don't call [setf!] SET!,
   that name is taken by RnRS.

bothner> We're talking about a *compatible* and logical extension to RnRS,
and I believe SET! is the right name.

I know that.  But there are many possible mutually-incompatible compatible
extensions (as proven by the whole previous discussion).  If they have
different names, or come from different modules, then you can pick the
one (if any) you like and say
  (define-syntax set! (syntax-rules '() ((set! N X) (setf! N X))))
But if one of them grabs the name SET! then you like it or else.

bothner> This especially makes sense if you want to provide a
  different infix "surface syntax", where A := B is syntactic
  sugar for (set! A B).

It could as well be syntax for (setf! A B).

bothner> Kawa uses SET!, and that's not going to change.

So does Kawa's extended SET! have the same semantics as the
new consensus Guile extended SET! ?  If not, that's a problem,
and a reason _not_ to use the same name.

-- 
     --Keith

This mail message sent by GNU emacs and Linux.
Food, Shelter, Source code.