[ruby-talk:01723] Re: ruby <=> python

> In message "[ruby-talk:01633] Re: ruby <=> python"
>     on 00/02/28, Quinn Dunkan <[e-mail]> writes:
> 
> |The other languages approaches seem more intuitive.
> |For example, in the haskell prelude:
> |type String = [Char]    -- strings are lists of characters
> 
> String is actually a Byte String.  Since I didn't prepare indent class
> for 0..255 integer, bytes are represented by Fixnums.
> 
> Strings are used to represent character strings, and sometimes packed
> structure using pack().  Have you ever used Perl's pack()?

They are in most other languages too, it's just a question of what comes out
when you throw a [] method at them (most other languages give you a byte, but
ruby doesn't).

> |So why doesn't ruby have a Char class?
> 
> I, as a Japanese, have to deal with several thousands Japanese
> characters daily.  We have to encode a character in multibyte
> sequence.  In that circumstance, a character is a sequence of bytes.
> We even have several encoding schemes.
> 
> So, it is far harder to define what is a character than you expected,
> with I18N in mind.
> 
> Unicode may help us in the future, but
> 
>   * Unicode 2.0 is also encoding with mutibyte sequence.
>   * Unicode 3.0 is not widely used yet, and not a absolute solution.
>   * I don't have enough editor/tools to treat Unicode.
>   * We have handreds of gigabytes of data in old encoding, I just
>     can't abandon separation between byte sequences and character
>     representation without better solution.
> 
> I hope I can define I18N (or M17N) character system in the future.
> Until then, I'd want String serves as byte string.

Hmm, well, I would define a character as "whatever you get when you pull one
element out of a string."  In ruby, this means a character is a Fixnum.  In
all the (non-unicode, ascii-oriented) languages I know, a character is an
8-bit value.  But it's not a number unless you convert it to one, because even
if you are pulling apart binary data, bytes aren't numbers, what they are
depends on how you parse them.  I can't claim to have the understanding of
character encoding that you do, but I *agree* with you that the language
shouldn't try to be extra clever about what a character is, it should just
give you a byte.  But ruby *doesn't* give you a byte!  It gives you a signed
int!

> Because I felt using `::' to access class method was a good idea,
> e.g. foo = SomeClass::new().  It denotes something (`new' in this
> case) belongs to the class.

But it doesn't, it works for instance methods too.  And `.' works for `class
methods' like new.  I know I'm not going to get far arguing with the creator
of the language :), but what's the rationale for `::' being a good idea?  I'm
not even sure about the Constant part: the user already knows he's accessing a
constant because of capitalization, right?  Now he has to remember to use a
different operator as well.  And if `::' can be used in all situations where
`.' would be, it doesn't help much from a `make different kinds of access
visually different' point of view.

> |Ah, this makes more sense, defined? isn't a method at all.  I thought
> |everything was a message send in ruby? :)  It *could* be "just another
> |message send" if you spelled it 'defined? :foo' or 'defined? "foo"'.  So
> |why not?
> 
> No it isn't.  It's a control structure.  No everything is a message
> send in Ruby, e.g. control structures, variables, blocks are not
> objects.  `defined? ' is among these things.
> 
> `defined?' shows
> 
>   * if a global variable is defined
>   * if a local variable is defined
>   * if a instance variable is defined
>   * if a constant is defined
>   * if a method is defined
>   * if a block is supplyed
>   * if a method of same name in superclass is defined
> 
> all of which is not accomplished by a method.

Ok, this makes sense to me.

> |I think this just means that || binds too tightly.  So the question is "why,
> |then, do you need '||'?"
> 
> Maybe just because it is already there.  `||' is far older than `or'
> in Ruby.  Removing things from the language may cause serious
> compatibility problem.

Ah, hysterical raisons.  I'm not a big fan of them, but, practically speaking,
there they are :)

> `false' is a boolean value, `nil' is a out-of-range value.  You know I mean?
> I'm considering make 0 false, but not positively.

Uh oh, does that mean only -0 is false?  My head hurts.

> Pros:
> 
>   * easier to adopted by C programmers
>   * easier to adopted by C libraries (e.g. by SWIG)

I don't consider these pros: ruby is already different enough from C that
similarities might just confuse them more.  And don't forget not everyone's a
C programmer (but then many other languages say 0 == false, but anyone who
knows more than a few will know to not take this for granted).

I personally have no problem writing if a.length == 0, and I think that's
actually more intuitive to newbies (who are not preprogrammed with a different
language), because they see if a.length and think "if a.length what?".  But on
the other hand, ruby makes a problem here by silently accepting if a.length,
and changing that would probably break a lot of code.  So maybe 0 == false is
a good idea.  I dunno.  I personally prefer the haskell-style "only accept
booleans", which is more clear and mistake-resistant, but would only annoy
quick-hack people who don't want to have to type too much.

> Cons:
...
>   * both nil and 0 serve as out-of-range mark, confusing

Does it have to?  Pardon me if I misunderstand, but everything that returns
nil now can still return nil in the future, ne?  I think it would be more
confusing (in a certain way) because then there would be 3 false values
instead of just 2, and it would give the impression that 0.0, '', [], etc.
ought to also be false.  And then you'd have to supply a false? method like
python's __nonzero__ :)

> |And, finally, here's a real ruby question:
> |What's the general idiom for parallel iteration in ruby?
> 
> There's no such idiom yet.  Although I've never met that situation,
> but I'd do pop (or unshift) from each arrays.

Err, but that modifies the arrays.  I almost never want to modify things, and
even if it doesn't matter it makes me very nervous.  Maybe just my functional
background..