On Mon, 2004-10-11 at 18:18, Austin Ziegler wrote:
> On Tue, 12 Oct 2004 09:21:16 +0900, Hal Fulton <hal9000 / hypermetrics.com> wrote:
> > Austin Ziegler wrote:
> > >>I think that you don't have to enforce any particular indentation style or
> > >>amount of space on each line - only that it is consistent between begin and
> > >>end.
> > > No, no, no, and NO!
> > :) Are you still ticked off after your system crash?
> 
> I'm annoyed that I haven't been able to do any Ruby coding for the
> last week :) But I'm also finding these "let's change Ruby into
> something else" discussions rather annoying with some of the proposed
> directions.

> 1) Ranges: I have used the fact of 1...2 including 1.99 but not 2.0 in
> the past. I don't think that this is something I want to change. I
> would like to be able to have mutable ranges (including the ability to
> make a range exclusive or inclusive after creation), but I think that
> the syntax for ranges is right and consistent for 98% of all users of
> Ruby.

     For what it's worth, I agree.  The original impetus for the "free
form operator patch" was an attempt to find a way to let people who
wanted things to work "their way" to be able to do so without relegating
them to a syntactic ghetto, in the hopes that this would reduce the
pressure for semantic changes in the core classes.  I am presently
supporting over 20,000 lines of ruby code, and changes in the core
classes can be...time consuming. 

2) Operators: I want += to be still automatically defined when I
> define +. I agree with Matz about user precedence, although I think
> that having a couple of fixed precedence values (instead of one) is
> acceptable, to allow for things like := having a reasonably high
> precedence.

     I wonder: would you find the "free form operator" idea more
palatable if it were not quite so "free form".  For example, if there
was some sort of rule imposed on user defined operators like:

        Any operator "___" not ending in '=' automatically defines a
        companion assignment operator "__=" such that "x __= y" means "x
        = x __ y"? 

     There might have to be tweaking of this rule, or codicils, to
assure consistency and backwards compatibility.  But my real question
is, in general, would more structure please you?  (And again, this is
all hypothetical--I am more interested in learning your thoughts than in
trying to sell you a feature you do not want.)

> 3) This. I don't think that what has been suggested will be all that
> useful. I have encountered a few of these missing "end" issues, and
> with the folding that is in the vim-ruby package offered by the
> community, I have rarely found that it takes me longer than five
> minutes to fix this issue.
> 
> > I sympathize with both sides. Like you, I "flush left" my debug lines
> > (fighting vim to do so, and hating the idea of coding without being
> > able to do such).
> > 
> > I typically don't leave those in long, however. YMMV.
> 
> Me, either.
> 
> I think that there are possibilities here, though, now that it's been
> explained that this is something to show up only in an error
> condition.

     I will try and make it more useful; do you by any chance have a
feeling of how/when you write flush-left code?  I am already ignoring
comment lines, since many people write them flush left.  Do you
generally only do one line this way?  Are they generally print/puts/p
statements?  

     In other words, is there anything that could be simply detected
(because I would like the code to remain small, fast, and simple) that
would let me detect what you do as "normal" and not consider it for
mention in the diagnostic message?
 
-- Markus