Re: [groovy-user] Support for unless / if expressions

On Friday 05 September 2008, Russel Winder said:
> On Thu, 2008-09-04 at 21:20 -0400, Martin C. Martin wrote:
>
> [ . . . ]
>
> > def myFunMethod(int foo) {
> >    throw new RuntimeException("Arg must be positive") if (foo < 0)
> >    ...
>
> I guess we could get into the linguistics etc. here -- I am sure that if
> an experiment were done we would find that native English speakers and
> native German speakers have different views on this due to the different
> structures of sentence in their natural languages.
>
> For me though this is a throw statement so I expect the result to be
> throwing an exception.  To find that the throws statement isn't actually
> going to throw an exception, possibly most of the time, is a
> comprehension problem for me.  True, this is a personal thing, but
> without doing an experiment, we are doing advocacy decision making based
> on personal experience.
>
> I agree that some functional programming languages, and indeed
> mathematics, uses guards on the right in many contexts, however there is
> a clear and obvious structure to when they are used.  This Perl/Ruby
> style condition on the right is actually a very different sort of thing
> since it is not part of a bigger construct.
>
> [ . . . ]
>
> > Of course, it's possible to use this to write confusing code.  Any
>
> I guess this is where I lean towards Python and away from Perl and Ruby.
> Perl especially, at least reputedly, has attempted to make it a benefit
> of the language that for any algorithmic construct there are multiple,
> preferably more, ways of expressing the same thing.  Ruby, in trying to
> be a better Perl, has gone the same route.
>
> From the perspective of a C, C++, Fortran, Java, Python person, I prefer
> my Groovy simple.  True, I can avoid using constructs in my own code,
> the issue is working with other people's code.  Python often goes too
> far in the simplicity stakes, indeed there are some decisions there I
> disagree with -- cf. the conditional statement syntax which is ugly
> because of the condition on the right ordering.  However, I favour
> Pythonic simplicity over Perlesque complexity.

Absolutely - the pythonic way is beautiful.   I fully lean towards python and 
away from ruby and VERY far away from perl.

--

-- 
Card #1. Uncle Bob’s Three Laws

• Write no production code except to pass a failing test.
• Write only enough of a test to demonstrate a failure.
• Write only enough production code to pass the test.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Support for unless / if expressions

On 06/09/2008, at 7:52 PM, Charles Oliver Nutter wrote:

> unless...else is pretty much widely discouraged in the Ruby  
> community because the meaning baffles most people.

Source?

--

LD.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Support for unless / if expressions

On Fri, Sep 5, 2008 at 12:04 PM, Graeme Rocher <graeme@...> wrote:
> On Fri, Sep 5, 2008 at 12:02 PM, Martin C. Martin
> <martin@...> wrote:
>>
>>
>> Russel Winder wrote:
>>>
>>> On Thu, 2008-09-04 at 21:16 -0600, phil swenson wrote:
>>>>
>>>> I like the idea... probably because I've used Ruby quite a bit.  Let's
>>>> face it, Groovy is pretty much a java-ized Ruby.
>>>
>>> No. JRuby is a Java-ized Ruby, Groovy is a dynamicized Java.  The
>>> difference is a) not as trivial as it sounds, and b) very important.
>>>
>>> For people wanting to work with Ruby on the JVM then JRuby is about as
>>> ideal as it gets.  This is not the same thing as wanting a dynamic
>>> language that is symbiotic with Java running on the JVM.
>>
>> I think Phil's point is that Groovy's syntax is very similar to Ruby's.  You
>> can think of Groovy as starting with Ruby, and changing the syntax in minor
>> ways to make it more friendly to Java users.  For example, you can pass
>> closures by having them follow a method invocation:
>>
>> foo(23) { println it }
>>
>> rather than:
>>
>> foo(23, {println it})
>>
>> On the other hand, it delimits blocks using { and }, not "do" and "end."
>>
>> Syntactically, Groovy is far closer to Ruby than to any other language,
>> including Java.
>
> That point is highly debatable given that Groovy grammar is based off
> of the Java 5 banner. It depends whether you writing Groovy like Java
> or whether you write it in an idiomatic sense

Sorry Java 5 grammar that is. Too many hours writing the new Grails book 

>
> Cheers
>
>>
>> Best,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> G2One, Inc. Chief Technology Officer
> http://www.g2one.com
>

--

-- 
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Support for unless / if expressions

Very true, good point.  Groovy allows either Java-style or Ruby-style.

Graeme Rocher wrote:
> On Fri, Sep 5, 2008 at 12:02 PM, Martin C. Martin
> <martin@...> wrote:
>>
>> Russel Winder wrote:
>>> On Thu, 2008-09-04 at 21:16 -0600, phil swenson wrote:
>>>> I like the idea... probably because I've used Ruby quite a bit.  Let's
>>>> face it, Groovy is pretty much a java-ized Ruby.
>>> No. JRuby is a Java-ized Ruby, Groovy is a dynamicized Java.  The
>>> difference is a) not as trivial as it sounds, and b) very important.
>>>
>>> For people wanting to work with Ruby on the JVM then JRuby is about as
>>> ideal as it gets.  This is not the same thing as wanting a dynamic
>>> language that is symbiotic with Java running on the JVM.
>> I think Phil's point is that Groovy's syntax is very similar to Ruby's.  You
>> can think of Groovy as starting with Ruby, and changing the syntax in minor
>> ways to make it more friendly to Java users.  For example, you can pass
>> closures by having them follow a method invocation:
>>
>> foo(23) { println it }
>>
>> rather than:
>>
>> foo(23, {println it})
>>
>> On the other hand, it delimits blocks using { and }, not "do" and "end."
>>
>> Syntactically, Groovy is far closer to Ruby than to any other language,
>> including Java.
> 
> That point is highly debatable given that Groovy grammar is based off
> of the Java 5 banner. It depends whether you writing Groovy like Java
> or whether you write it in an idiomatic sense
> 
> Cheers
> 
>> Best,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Support for unless / if expressions

Good point, which is no doubt what inspired Ruby.  So its more general 
and less Ruby-specific than I was thinking.

Best,
Martin

Jochen Theodorou wrote:
> Martin C. Martin schrieb:
> [...]
>>  For example, you can pass closures by having them follow a method 
>> invocation:
>>
>> foo(23) { println it }
>>
>> rather than:
>>
>> foo(23, {println it})
> 
> in Java we have for example:
> 
> synchronized(foo) {bar();}
> 
> which very much looks like the first form. If you think about it, then 
> syntactically a for- or while-loop do like that too. The simple if 
> without else fits here in too. So let us see these as of the structure 
> "method arguments". then there is for example if-else...
> 
> if (condition) {
>   ...
> } else {
>   ...
> }
> 
> which would be "method arguments else arguments" or probably: 
> "method(arguments,method(arguments))" it could be thought that the else 
> is executed first, without actually executing the block, but building 
> another argument for the if method call. But how is that method 
> detected? If else where a symbol it would be "method arguments", where 
> one of the arguments would be the else symbol and the if method would 
> have to find that symbol... throw-catch could be explained like this as 
> well.... but unless...
> 
> foo() unless bar()
> 
> that is like "method arguments unless method arguments". If we go the 
> symbol way, then foo() would be in fact: foo('unless,bar()), with unless 
> being a symbol and {bar()} a block to be executed if the symbol is part 
> of the arguments... but that is not what we want. We don't want foo() to 
> handle any symbol that does not exist anyway. We don't want foo to 
> handle any block/Closure that is returned by the method call "unless 
> bar()". foo() should remain untouched.
> 
> But that means we reverse the usual ordering of things....
> 
> foo() unless bar()
> 
> becomes
> 
> if (bar()) {
> } else {
>   foo()
> }
> 
> eben if we say unless is "methodcall unless condition", and say we have 
> a structure consisting of three parts and look at other such structure 
> like if-else: "methodcall else methodcall" then we still have a 
> different order, because the first method call in if-else is executed 
> first and the second only if the condition is not true. In case of 
> unless the second method call is executed first and the first method 
> call is executed only if the condition is met. Other 3-part structures 
> could bee try-catch, but again, the first part here is executed first. 
> And even in do-while we have this.
> 
> What I want to say in short: This kind of evaluation order is nowhere to 
> be found in the existing language... it would be an alien element.
> 
> If it stays the only such element, then I am against adding it. If we 
> intend to add multiple such elements (where the evaluation order is 
> reversed) then it is something to discuss again.
> 
> The Ada was named... from 
> http://en.wikibooks.org/wiki/Ada_Programming/Control
> 
>> Exit_Loop :
>>    loop
>>       X := Calculate_Something;
>>       exit Exit_Loop when X > 5;
>>       Do_Something (X);
>>    end loop  Exit_Loop;
> 
> the same in Groovy would be:
> 
> Exit_Loop: while (true) {
>   def X = Calculate_Something()
>   if (X>5) break Exit_Loop
>   Do_Something (X)
> }
> 
> not only do we start with a keyword here, this construct is also special 
> to loops and labels. That is far from the semantics of "unless"
> 
> The suggested
> 
> do foo() unless bar()
> 
> would be much more fitting for Groovy, because it fits the structure 
> "method arguments", where foo(), the symbol unless and bar() are the 
> arguments to the method do. The matter that we don't support symbols is 
> not important here, important is that this fact is an implementation 
> detail and hidden by the "do"-method.
> 
> bye blackdrag
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Support for unless / if expressions

The Ada was named...

I mentioned Ada because I replied about loop with condition in the middle

It's clear to me that "postfix" if/unless is not consistent with Groovy at all. I only thought it would be nice to have for internal DSLs created in Groovy. All that said, I believe everybody can live without it.

LT

RE: [groovy-user] Support for unless / if expressions

We should be aware that  "if not a is greater than b, than do that"
is a very formal speech.

What is ok in a programmer's context, as for us a PL code is a formal
specification of a program.

But what about DSL's ?
I can imagine that in some domain contexts it could indeed be 
useful to have the 'guard' style.

And: I have used trailing conditions and unless indeed in my Ruby code,
somehow like this:

     doSomething()
     doAnotherThing() unless isPreviewMode()
     doLastThing()

So the emphasis is on the job steps, which will *normally be done*
in this order, not on the condition, which *sometimes* will change the 
processing flow.
Pre or post condition is therefore a matter of relation between 
"typical" and "exception".

I'm always annoyed reading code like this:

  doSomething()
  if noError()
     doAnotherThing()
  if successfull()
     doLastThing()         

It breaks the reading of the standard process flow, which will be
"no error" and "successful" and put too much emphasis on the exceptional
cases.

And for natural languages:

Russel Winder wrote:

> I guess we could get into the linguistics etc. here -- 
> I am sure that if an experiment were done we would find 
> that native English speakers and native German speakers have 
> different views on this due to the different structures of 
> sentence in their natural languages.

I think that is not true for where to put conditionals.
The only difference may be, that we Germans don't have such 
a clear single word. 
(dict.leo.org:   unless =>
 .  außer dass
 .  es sei denn, dass
 .  sofern nicht
 .  wenn nicht )

Jochen Theodorou wrote:
> But "unless" is not common. I don't know about the English native 
> speakers, but I use unless rarely. In my mother language 
> too.... If I use it, then because I had an idea in the middle 
> of the sentence ;)

I must admit that in spoken language I use it often enough,
as it changes the emphasis.

A: "We never gonna survive!"
B: "Yes, we never gonna survive unless we're a little crazy"
(Remind: Seal 1990  )

In a naturally spoken context, a leading "unless" feels uncommon 
and formal for me, and trailing conditions seem very common:
"I will come tomorrow if I will get a cheap ticket" a.s.o. 

Example: Quote from the GPL:
-----
You may make, run and propagate covered works that you do not 
convey, without conditions so long as your license otherwise 
remains in force. You may convey covered works to others for 
the sole purpose of having them make modifications exclusively 
for you, or provide you with facilities for running those works, 
provided that you comply with the terms of this License in conveying 
all material for which you do not control copyright. 
------

Replace "so long as" and "provided that" with the simple "if"
and you have trailing conditions.

RESULT:  I would second 'unless' as well as trailing conditions
as they make things more flexible and readable in some groovy contexts.
(I would not cry if it would be dropped).

KR
Det

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email