This is the mail archive of the guile@sourceware.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: message primitive


re-widened to include guile list:

Maciej Stachowiak <mstachow@alum.mit.edu> writes:

> "Greg J. Badros" wrote:

<snip>

> > That would be even worse to use different escape sequences for the
> > simple format than for the more complicated one (assumming Mikael is
> > right about it being ~A and ~S, respectively.
> 
> You're right, the escape sequences should be made to match precisely.
>  
> > Also, I'm concerned about scm_display_error & backward compatibility.
> > It can't really go thru and s/%/~/g (or even more precise variants)
> > since % is a literal in the simple `format' sense.
> 
> But is should be possible to find the locations that make a call which
> ultimately results in using this formatting code. 

Yes, as long as you're okay with making people's guile code break.  (I
am, as I think it's useful to go with the standard).

> > And if we choose to leave scm_display_error (i.e., instead of rewriting
> > it in terms of scm_format/scm_simple_format), then we've lost the
> > original motivation for this change: that it's just a very useful C
> > procedure that would be nice to have access to at the Scheme level while
> > introducing almost no new overhead.
> 
> Well, it's not code overhead that's the problem, it's intellectual
> overhead
> of the language, if I may misappropriate a metaphor. We shouldn't let
> ease of
> implementation decide what a user sees.

I agree with you intellectually, but if you consider the evolution of
many free projects, in many cases the simplest implementation techniques
are used resulting in many incremental improvements at lower cost.  This
is a case where my initial idea took 2 minutes to implement (indeed, I
did it before even suggesting the idea) and provided a lot of certain
benefit.  The more complicated version has already taken 20+ minutes of
discussion effort and will result in lots of effort for people using
Guile, as well as for me to update the internal calls to use the new
version.  The marginal benefit from doing it that "better" way?
certainly non-zero, but probably not nearly as great as the initial
benefits from the original suggested change.

I'm basically making an economic argument:  it'd be great if everything
could be perfect with Guile, but it can't so we have to pick and choose
where to spend the limited developer resources to improve it.  Although
the hour+ this'll ultimately end up taking will make guile (N+epsilon)%
better, the two minutes I'd already spent would've made guile N% better, 
and freed up over an hour for me to do other things to get
bigger-than-epsilon improvements in Guile.

<snip>

Greg

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