[ruby-talk:01637] 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()?

|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.

|OK, I can understand the bit about <obj>.<ident> is a method call, wheras
|<obj>::<ident> is a Constant retriever (not attribute retriever, since those
|are just methods in ruby), even if I don't like it :)  But my real question
|was "if '.' and '::' are used for different purposes, why does '::' work like
|'.'?"  'Foo::X' -> "Constant" vs. 'Foo::X()' -> "method" just underlines that
|question.  Does this seem a bit 'trap-like' to anyone else?  OK, I'm sure a
|perl programmer, who is used to subtle changes when you put parentheses in,
|wouldn't blink.  Ok, maybe a perl programmer would blink and be just as
|confused as the rest of us, but he'd be more inclined to accept it without
|question :)

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.

|> even in the toplevel, you are in an instance of class Object. so
|> 'defined? foo' means defined? self.foo.  you can always check what
|> method an instance has with method 'methods'.
|
|Yes, well even 'self.defined? self.foo' has to evaluate self.foo.

No, it eveluates `self' but no `self.foo', it returns true if `self'
has method named `foo'.

|> is there a way to get a list of variables that has been defined?
|
|You tell me, I'm the newbie here :)  Based on my fuzzy understanding on ruby,
|I'd say no, because defined variables are just methods of self, and there's no
|way to tell what a method will give you unless you call it.  No wait, I'm
|thinking of @attrs.
|
|> >Suppose you write "defined? foo".  defined?  has to evaluate its arguments,
|> >which makes me think it ought to throw a NameError if foo isn't defined'.
|> >I'm confused.
|> 
|> `defined?' is a kind of operator, and its argument is checked by the
|> parser.  I understand it is similar to sizeof operator in C. 
|
|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.

|Hmm, so I guess throw/catch is supposed to be a control structure, while
|exceptions are supposed to be only for errors?  And throws can only be caught
|in one place (which 1344 seems to imply)?

catch/throw can be considered as control structure, and in Ruby, some
control structures are defined using blocks like loop, catch, etc.

|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.

|That's useful information (more efficient than wrapping them in lambdas, which
|are not exactly methods anyway).  That "looks like array index, but is really
|a method call" is a bit weird, but I guess not much worse than the "looks like
|bit-shift, but is really stream-append" thing C++ loosed on the world.
|Why not provide a () method like python's __call__?

Mostly because of syntax.  In Python,

  foo

is a reference to a variable, 

  foo()

is a call of the object referred by foo in general.  In Ruby, 

  foo
  foo()

are interpreted more complexly.  The latter is a method call, the
former is a reference to a local variable or a method call without
argument depends on context.  Yes, Ruby is a far complex language than
Python.

|Or maybe smalltalk.  But that still doesn't explain the 'different behaviours
|elsewhere' bit (and the fact that nil != false).  If it were merely a case of
|"can't decide whether to type 'nil' or 'false' so I'll let people use (and the
|flip side: force people to read) both (like python != and <>), then they would
|have been exactly equivalent.

`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.

Pros:

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

Cons:

  * incompatibility
  * both nil and 0 serve as out-of-range mark, confusing

|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.

  def zip(*args)
    r = []
    args.collect{|i|i.size}.max.size.times do
      r.push args.collect{|a|a.unshift}
    end
    r
  end

							matz.