For something more non-trollish, the Java rocky way towards lambdas and
closures via anonymous inner classes (eww) just might mean that if
either CICE or BGGA get promoted into the language, you could use a
stateful command-object implementing a SAM type interchangeably with a
closure, eliminating the need for a first-class (and isolated) closure
concept. Which I can’t think of what it could be good for, but then
again, noone knew what continuations were good for for a webapp until
recently either.
Isn’t this sort of torture governed by international law? smirks
On a serious note, I wonder how well closures will work out in Java.
It just seems somewhat out of place to me. Even in ruby there are
instances when blocks are a pain to work with. If you want to pass
more than one block to a method, it looses its elegant looks, IMHO:
# okay, but eh...
foo(lambda do |x|
bar
end, lambda do |y|
baz
end)
# I think the standard way is worse in this case
foo(lambda do |x|
bar
end) do |y|
baz
end
# probably the way to go
l1 = lambda {|x| bar}
l2 = lambda {|y| baz}
foo(l1,l2)
I’m not quite sure how to solve that though? Maybe this? =)
If you can’t understand what someone was responding to who are you to
talk about whether they understand compilers when you don’t even
understand the nature of the conversation to begin with? What I did
I apologize if I misunderstood your point. As I mentioned before, I’ve
taken a compilers course and am moderately conversant in a concept
called a
shift-reduce conflict during compiler/interpreter construction. What
you
are proposing would introduce a shift-reduce conflict into the language.
As
you may find if you research this topic, this isn’t necessarily a
problem as
it can be handled explicitly. However, so far, you haven’t made any
reference to a common experience in language construction.
It is interesting how often such conflicts occur in the novice’s
creation/design of a language. I myself fought many battles with them
(and
often lost!)
was reply to a comment from another person that started this line of
conversation. Then some one comes along and says that there is no
issue and everyone who thinks there is are not knowledgeable enough
about anything to even think about such a situation. I disputed this,
simply put this really had nothing to do with the technical aspects of
any programming languages period, it was and is a very philosophical
thing that was brought up by someone other than myself.
You’ve hit upon the crux of the issue. Their point, which I echoed from
an
admittedly more ignorant position than theirs, is that this is not a
purely
philosophical position, but a design decision based on technical
trade-offs
during the construction/evolution of ruby. You may wish to argue
semantics
here, but a semantic argument doesn’t invalidate the fact this was a
design
decision made by Matz (according to statements made by others in this
thread).
When I said that I felt that the else if keyword was unnessecary what
I meant was that you should be able to do the following:
if condition #stuff
else
if condition #stuff
end
As opposed to:
if condition #stuff
else
if condition #stuff
end
end?
Here’s a great book on the subject of compiler theory:
You should check it out.
My initial estimation of your education still stands as you have never
sought to address the shift-reduce conflict you wish to introduce into
the
Ruby grammar. However, in the case that you are cognizant of such
theory
and just not versed in compiler vernacular, I apologize in advance and
await
your instructive response that will elucidate my shortcomings and
ignorance.
Alternately, you could take this question to comp.compilers and watch
both
of us get lost in theory. In fact, I open my request to the list at
large,
am I on the right track with attempting to understand the design
decision
made in regards to this particular construct?
Rather than keep filling up the mailing list with off-topic posts, I’m
happy
to continue the conversation off-list.