Re: retry semantics changed

Charles Oliver Nutter schrieb:
> Yukihiro Matsumoto wrote:
>> Perhaps.  I just wanted to know what he meant in the word "dangerous".
> By dangerous I mean "undetectable and unexpected side effects".

I was plying a little bit with both usages of "retry" (block and
"begin-end"). I must admit that I didn't use "retry" before, because
I didn't need it until now.

The result of my playing surprized me a little bit. I'm not sure
if there are interesting usages of "retry" inside a block, but it may
be possible for some embedded DSLs to have an additional alternate
syntax possibility.

The question "is this a dangerous construct if allowed in blocks too?"
is not easy to answer for me. Long ago I was responsible for adaption
and maintenance of the SPSS statistic software from IBM systems to
german Telefunken systems for several universities and the government.
It was Fortran and Assembler, and in parts very difficult to understand, 
although we had very special tools.

If I'm confronted as a person responsible for software adaption with
a code like the following...

a = [[]]
count = 0
begin
   (
     (a[-1] ||= []) << (count += 1)
     a
   )
   .flatten
   .tap{|x|retry if x.length.remainder(4)!=0; raise}
rescue
   (a << []; retry) if a.length <= 2
end
p a # => [[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]]

..., it might be possible, that I will go to the next Whisky bar
instead of doing my job... ;-)

I would like to have "retry" in blocks in the future, because it may
give additional possibilities, but we must be aware, that this is a
construct that may really confuse readers of code, written by third
persons.

Wolfgang N叩dasi-Donner