[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6678] Re: printing/accessing arrays and hashes

From: raja@... (Raja S.)
Date: 2000-11-30 15:10:02 UTC
List: ruby-talk #6678
>Actually, what happens is that when you concatenate something to an
>existing string, if that something isn't already a string, its to_str
>method is called.

aha!  So it's not really #joins behavior but that of concatenation (akin to
Java's 'toString' method behavior).  
Thanks for the clarification!

>Before you do that, though, can I suggest an experiment?
>Do nothing. Just try it as it is, and see what happens. See how often
>you get bitten by this. Perhaps adjust your coding style slightly to
>adapt to a new language.

Indeed.  My intent wasn't conveyed properly in my earlier wording.  I didn't
mean to imply that it had been "accidentally" left out.  No doubt it was a
conscious much thought about design choice.  (But of course, "much thought
about" is isn't necessarily the same as "well thought out" :-) )

Going from your comment and your extensive experience I'm inclined to say it
isn't much of a problem in Ruby.  As I alluded to earlier, the extensive
iterators of ruby should alleviate this problem.  I personally can't recall
it being a problem in Common Lisp though, needless to say, is a pain in C.
I guess I was thinking along the lines that several recent languages (Java,
Python) and (if I recall right older ones as Ada and Eiffel) raise such out
of bound exceptions.  (As an educator I'm well aware that its a very common
mistake that trips beginning students.  But, that may be because most
earlier languages didn't have a good collection of iterators.)

In relation to your "looking for horses rather than zebras" analogy I prefer
to right the "main" code first and wrap the boundary cases in exception
handlers.  With ruby's good exception handling mechanisms that is still
possible.  But if array/hash access needs to pre-checked it would violate
the "separation of concerns" policy.  Let me see how it goes. :-)

				     *

On a related note.  I've several (non-academic) years exposure to
C/Scheme/Common Lisp/Java/Python and 24 hours exposure to ruby :-)

In trying to personally experience Ruby's "Principle of least surprise" I've
tried to intuitively guess how things "should be" and am comparing it with
"how things are".  For what it may be worth, following are my notes that
I've jotted down for my self.  These are NOT meant to be a "call to arms" to
the designers to change the language :-).  The problem/fix/comment s just
reflect where my intuitions/expectations went awry.  The "shouldn't" that
you see below are just -my- intuitions and where I was surprised at ruby's
behavior.  Of course, as I've always felt: "everything is intuitive once you
understand it" :-).

These are just a snap shot of my "huh? -> aha!" transition as I learn more
about the ruby way of thinking.  

Raja

				     *
---------------------------------------------------------------------------

Problem:  Array/hash access via #[] (i.e.m a[i], h[i]) does not raise an
          exception for out of range indices/keys.  

Fix:      Hash#fetch raises an exception but unfortunately nothing equivalent
          for arrays. 

Comment:  Perhaps this is a non-issue with Ruby's iterators.
          Is it too late to include?

          Note that this need not outlaw assigning to out-of-bound array
          indices. 

          a = [1,2,3]
          a[5] = 100    #-> [1, 2, 3, nil, nil, 100]

          could still be valid.

          Out of bound access would raise an exception while assignment
          could be still be valid.  Assigning to an out-bounds array index
          could be viewed as the equivalent to creating a new entry in a
          hash. 

---------------------------------------------------------------------------

Quirk:    Printing hash literals as the first argument to print causes
          syntax problems: 

          print {'a'=>1, 'b'=>2}

Fix:      Precede by an empty string.
          print "", {'a'=>1, 'b'=>2}

Comment:  One can say:

             print [1,2,3]

          so one may equivalently expect:

             print {'a'=>1, 'b'=>2}

          But print seems to treat the hash as a block.

          Not a major problem but interesting asymmetry between arrays and
          hashes.  

---------------------------------------------------------------------------

Problem:  Default printing behavior (i.e., #to_s) of arrays/hashes doesn't
          show structure

Fix:      Using #inspect

          Can also define define our own Array#to_s, Hash#to_s to show
          structure during #print:
              
             class Array
               def to_s
                  inspect
               end
             end

          Or write your own print routine:

             def Rprint (*args)
               for x in [*args]
                   print x.inspect, " "
               end
               print "\n"
             end

          will give behavior similar to Python's 'print'


Comment:  irb shows the structure when evaluating arrays/hashes

          Shouldn't this be the default printing behavior of ruby?  i.e.,
          shouldn't the default #to_s of arrays and hashes show their
          structure?

---------------------------------------------------------------------------

Problem:  Array#join flattens a nested array.

          [[1,2], [3,4]] . join(", ")   #-> "[1, 2, 3, 4]"
          instead of                        "[[1,2], [3,4]]"

Fix:      Use [[1,2], [3,4]] . inspect  #->  "[[1,2], [3,4]]"

          During printing of nested arrays either redefine Array#to_s
          or use the before mentioned #Rprint

Comment:  [based on Dave's explanation] When concatenating objects that are
          not strings #to_str is called. 

          Shouldn't 

          [[1,2], [3,4]] . join(", ")   #-> "[[1,2], [3,4]]"

          be the preferred behavior 

          and use,

          [[1,2], [3,4]].flatten.join(", ")  #-> "[1, 2, 3, 4]"
    
          to get the current behavior?
          
          Again, if we redefine Array#to_s to be equivalent to #inspect
          this automatic flattening won't happen.

---------------------------------------------------------------------------

Problem;  a[i..j / i...j / i,cnt] returns nil instead of [] for non-existing
          segments.

          Creates a problem for iterators as #each isn't defined for nil.

Fix:      Don't know of a clean one.

Comment:  Either #each needs to be defined for nil [Doesn't feel right]

          Or a[i..j / i...j / i,cnt] should return the empty array, [], for out
          out of bounds segments. [This feels right] 

---------------------------------------------------------------------------


In This Thread