Does Go support the x ? 'a' : 'b' syntax or something similar?

280 views
Skip to first unread message

Travis Reeder

unread,
May 17, 2011, 3:09:44 PM5/17/11
to golan...@googlegroups.com
eg: 

fmt.Printf("%v=%s\n", fromClient ? 'client' : 'server', buf[0:nr])


Kyle Consalus

unread,
May 17, 2011, 3:11:32 PM5/17/11
to golan...@googlegroups.com

Corey Thomasson

unread,
May 17, 2011, 3:14:47 PM5/17/11
to Kyle Consalus, golan...@googlegroups.com
The closest thing you'll get is

fmt.Printf("%s", func() string {
if condition {
return "yes"
}
return "no"
}())

(or a map[bool]string and mymap[condition])

chris dollin

unread,
May 17, 2011, 3:18:38 PM5/17/11
to Kyle Consalus, golan...@googlegroups.com

Also some relatively recent discussion on this list.

> Short answer: no.

I had the impression from the abovementioned discussion that
a properly thought through proposal would not be rejected out
of hand. (And part of my interpretation of that is that it should
include some analysis of what it would achieve if used in the
Go codebase.)

Chris

--
Chris "allusive" Dollin

Skip Tavakkolian

unread,
May 17, 2011, 5:36:06 PM5/17/11
to golan...@googlegroups.com
there isn't one; you could create one that is close enough:

package main

import "fmt"

func main() {
QC := func(c bool, a, b interface{}) interface{} {
if c {
return a
}
return b
}

fmt.Printf("the answer is %s\n", QC(true, "red", "no! blue..."));
fmt.Printf("the answer is %d\n", QC(false, 24, 42))
}

-Skip

On Tue, May 17, 2011 at 12:09 PM, Travis Reeder <tre...@gmail.com> wrote:

Arlen Cuss

unread,
May 17, 2011, 8:13:10 PM5/17/11
to Skip Tavakkolian, golan...@googlegroups.com
> QC := func(c bool, a, b interface{}) interface{} {
> if c {
> return a
> }
> return b
> }
>
> fmt.Printf("the answer is %s\n", QC(true, "red", "no! blue..."));
> fmt.Printf("the answer is %d\n", QC(false, 24, 42))
> }

Note that this won't short-circuit, i.e. QC(true, "no problems!",
panic("oh no!")) would panic, but the hypothetical ternary op. would
not.

--
Arlen Cuss
Software Engineer

Phone: +61 3 9877 9921
Email: ar...@noblesamurai.com

Noble Samurai Pty Ltd
Level 1, 234 Whitehorse Rd
Nunawading, Victoria, 3131, Australia

noblesamurai.com | arlen.co

signature.asc

Andrew Gerrand

unread,
May 17, 2011, 8:31:02 PM5/17/11
to Arlen Cuss, Skip Tavakkolian, golan...@googlegroups.com
On 18 May 2011 10:13, Arlen Cuss <ar...@noblesamurai.com> wrote:
>>       QC := func(c bool, a, b interface{}) interface{} {
>>               if c {
>>                       return a
>>               }
>>               return b
>>       }
>>
>>       fmt.Printf("the answer is %s\n", QC(true, "red", "no! blue..."));
>>       fmt.Printf("the answer is %d\n", QC(false, 24, 42))
>> }
>
> Note that this won't short-circuit, i.e. QC(true, "no problems!",
> panic("oh no!")) would panic, but the hypothetical ternary op. would
> not.

Yes. And it is because of this subtlety that Go doesn't have this kind
of syntax. Too much logic packed into a small space makes for
unreadable programs.

Andrew

Steven

unread,
May 17, 2011, 10:40:13 PM5/17/11
to Arlen Cuss, Skip Tavakkolian, golan...@googlegroups.com
On Tue, May 17, 2011 at 8:13 PM, Arlen Cuss <ar...@noblesamurai.com> wrote:
>       QC := func(c bool, a, b interface{}) interface{} {
>               if c {
>                       return a
>               }
>               return b
>       }
>
>       fmt.Printf("the answer is %s\n", QC(true, "red", "no! blue..."));
>       fmt.Printf("the answer is %d\n", QC(false, 24, 42))
> }

Note that this won't short-circuit, i.e. QC(true, "no problems!",
panic("oh no!")) would panic, but the hypothetical ternary op. would
not.

Sorry, but I had to :D

package main

import "fmt"

func Ternary() (tern func(bool) interface{}, val func(interface{}) bool) {
var value interface{}
tern = func(bool) interface{} { return val }
val =  func(v interface{}) bool { value = v; return true }
return
}

func f(n int) int { fmt.Println("called f"); return n }
func g(s string) string { fmt.Println("called g"); return s }


func main() {
tern, val := Ternary()
fmt.Println("Ternary result:", tern(true && val(f(5)) || val(g("five"))))
fmt.Println("Ternary result:", tern(false && val(f(5)) || val(g("five"))))
}

Oh God, what have I done?

Sam Fredrickson

unread,
May 17, 2011, 10:41:48 PM5/17/11
to golang-nuts
On May 17, 5:31 pm, Andrew Gerrand <a...@golang.org> wrote:
> Yes. And it is because of this subtlety that Go doesn't have this kind
> of syntax. Too much logic packed into a small space makes for
> unreadable programs.
>
> Andrew

Is the ternary operator really so subtle? I mean, programmers
regularly rely
on the short-circuit logic of the boolean operators, why should this
be any
more difficult to comprehend?

Besides, the ternary operator is just so darn useful. Dichotomous
variable initialization
is so common that it makes sense to provide a convenient shorthand for
it. I agree that
the C ternary operator syntax can be obtuse, but what about something
like the Scala
approach of making the if/else-statement an expression? Example:

fmt.Printf("%v=%s\n", if(fromClient) { "client" } else { "server" },
buf[0:nr])

Russ Cox

unread,
May 17, 2011, 10:50:39 PM5/17/11
to Sam Fredrickson, golang-nuts
There's a reason it's in the FAQ.

Skip Tavakkolian

unread,
May 17, 2011, 11:52:26 PM5/17/11
to Sam Fredrickson, golang-nuts
are you sure ?: would be "so darn useful" without the side effects of
comma expressions?

-Skip

Russ Cox

unread,
May 18, 2011, 10:53:04 AM5/18/11
to Skip Tavakkolian, Sam Fredrickson, golang-nuts
Be careful what you wish for.

CoffeeScript supports the x?a:b syntax but
it doesn't mean what you think it means.

x?y means if x then x else y, and a:b is an
object literal with a single field a with value b.
So x?a:b means if x then x else a:b.

Russ

Skip Tavakkolian

unread,
May 18, 2011, 2:29:19 PM5/18/11
to Russ Cox, Sam Fredrickson, golang-nuts
i don't miss it, nor C head-scratchers like this:

main()
{
int i, j, k;

i = 0; j = 1;
k = i ? i++, j : j++, i;
printf("%d %d %d\n", i, j, k);

i = 0; j = 1;
k = i ? (i++, j) : (j++, i);
printf("%d %d %d\n", i, j, k);
}

-Skip

chris dollin

unread,
May 18, 2011, 2:47:04 PM5/18/11
to Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On 18 May 2011 19:29, Skip Tavakkolian <skip.tav...@gmail.com> wrote:
> i don't miss it, nor C head-scratchers like this:
>
> main()
> {
>        int i, j, k;
>
>        i = 0; j = 1;
>        k = i ? i++, j : j++, i;
>        printf("%d %d %d\n", i, j, k);
>
>        i = 0; j = 1;
>        k = i ? (i++, j) : (j++, i);
>        printf("%d %d %d\n", i, j, k);
> }

Well, even if Go acquired conditional expressions you
couldn't write what you had above, so whether or not
you miss it doesn't seem to be relevant.

It's an interesting mix of comma-expressions, conditional
expressions, and increment expressions, but it's value
as evidence against the value of conditional expressions
is diminished -- I'm tempted to say, destroyed -- by it's
not having a purpose beyond exhibiting the peculiarities
of C's expression syntax.

Chris

(Yes, I did already know that conditional expressions
are more tightly binding than the comma-operator.)

--
Chris "Oscar Wilde" Dollin

Skip Tavakkolian

unread,
May 18, 2011, 3:30:09 PM5/18/11
to chris dollin, Russ Cox, Sam Fredrickson, golang-nuts
only that -- as i posited in a previous message -- even in C the
conditional operator isn't all that "useful" without the comma
operator; together they're often an attractive nuisance.

-Skip

chris dollin

unread,
May 19, 2011, 4:07:37 AM5/19/11
to Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On 18 May 2011 20:30, Skip Tavakkolian <skip.tav...@gmail.com> wrote:
> only that -- as i posited in a previous message -- even in C the
> conditional operator isn't all that "useful" without the comma
> operator; together they're often an attractive nuisance.

Java has no comma-operator, and that hasn't stopped its conditional
expression being useful. C code can use conditional expressions without
needing the comma operator to make them "useful".

What a hasty grep through the Jena sources (because they're to hand and
written by several people with different styles) suggests is that there are
two common cases and two less-common ones.

The common cases are "return Ex ? Ey : Ez" and "Type V = Ex ? Ey : Ez".
Usually the Ei are all pretty simple. Sometimes there are cascaded
conditions

return T1 ? V1
: T2 ? V2
: T3 ? V3
: V

The less common cases are assignments and arguments to function calls.
Actually I'm not sure I can see a conditional argument in this samply.
Again the Ei are not particularly complicated.

So this suggests to me that the comma operator is a red herring, and
that the mere possiblility of having horribly complicated conditional
expressions does'nt mean that conditional expressions need be horrible,
no more than plain arithmetic expressions with array subscripts and
function calls need be horrible.

chris dollin

unread,
May 19, 2011, 4:15:23 AM5/19/11
to Andrew Gerrand, Arlen Cuss, Skip Tavakkolian, golan...@googlegroups.com
On 18 May 2011 01:31, Andrew Gerrand <a...@golang.org> wrote:
> On 18 May 2011 10:13, Arlen Cuss <ar...@noblesamurai.com> wrote:
>>>       QC := func(c bool, a, b interface{}) interface{} {
>>>               if c {
>>>                       return a
>>>               }
>>>               return b
>>>       }
>>>
>>>       fmt.Printf("the answer is %s\n", QC(true, "red", "no! blue..."));
>>>       fmt.Printf("the answer is %d\n", QC(false, 24, 42))
>>> }
>>
>> Note that this won't short-circuit, i.e. QC(true, "no problems!",
>> panic("oh no!")) would panic, but the hypothetical ternary op. would
>> not.
>
> Yes. And it is because of this subtlety that Go doesn't have this kind
> of syntax.

That argument would also exclude && and ||.

> Too much logic packed into a small space makes for
> unreadable programs.

Maybe, but that doesn't tell us how much is "too much". All I can
say is that I've not found conditional expressions to cause
unreadability /of themselves/, and I've encountered uses of
ifs, loops, and breaks that were unreadable with no conditional
expressions in sight.

ceving

unread,
May 19, 2011, 5:01:58 AM5/19/11
to golang-nuts
On 19 Mai, 10:15, chris dollin <ehog.he...@googlemail.com> wrote:

> > Too much logic packed into a small space makes for
> > unreadable programs.
>
> Maybe, but that doesn't tell us how much is "too much". All I can
> say is that I've not found conditional expressions to cause
> unreadability /of themselves/, and I've encountered uses of
> ifs, loops, and breaks that were unreadable with no conditional
> expressions in sight.

It is a more fundamental problem.

In real languages you can write expression wherever you want.

(let ((a -3)
(b 2))
(display (cond ((> a b) "greater")
((> (abs a) (abs b)) "modulus greater")
(else "not greater")))
(newline))

The ternary operator in C is only a hack by placing the "if"
expression over all other expressions. But what makes the "if"
expression more important than all other expressions?

So the Go way of life "either all or nothing" is consequent. Although
I also would have preferred all to nothing. ;-)

chris dollin

unread,
May 19, 2011, 5:16:12 AM5/19/11
to ceving, golang-nuts
On 19 May 2011 10:01, ceving <cev...@gmail.com> wrote:
> On 19 Mai, 10:15, chris dollin <ehog.he...@googlemail.com> wrote:
>
>> > Too much logic packed into a small space makes for
>> > unreadable programs.
>>
>> Maybe, but that doesn't tell us how much is "too much". All I can
>> say is that I've not found conditional expressions to cause
>> unreadability /of themselves/, and I've encountered uses of
>> ifs, loops, and breaks that were unreadable with no conditional
>> expressions in sight.
>
> It is a more fundamental problem.
>
> In real languages you can write expression wherever you want.

For some definition of "real".

> (let ((a -3)
>      (b 2))
>  (display (cond ((> a b) "greater")
>                 ((> (abs a) (abs b)) "modulus greater")
>                 (else "not greater")))
>  (newline))
>
> The ternary operator in C is only a hack by placing the "if"
> expression over all other expressions.

I don't understand what you mean by "placing the "if"


expression over all other expressions."

> But what makes the "if"
> expression more important than all other expressions?

I don't know. Was anyone relying on "if" expressions being
more important than others?

Conditional expressions are distinguished from infix expressions
by (amongst other things) having three operands, not two,
just as prefix expressions are distinguished by having only one.
The number of operands is not an "importance" of an expression.

> So the Go way of life "either all or nothing" is consequent. Although
> I also would have preferred all to nothing. ;-)

"All" is a bigger universe than even I am prepared for ...

ceving

unread,
May 19, 2011, 7:11:13 AM5/19/11
to golang-nuts
On 19 Mai, 11:16, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > The ternary operator in C is only a hack by placing the "if"
> > expression over all other expressions.
>
> I don't understand what you mean by "placing the "if"
>  expression over all other expressions."
>

The ? operator in C is equivalent to an "if" expression.

a = a ? "true" : "false";

if (a) {
a = "true";
} else {
a = "false";
}

The problem in C is that you are not allowed to use the "if"
expression as an argument to a function call, because the "if"
expression has no return value. Instead of writing:

print_string ( if (a) { "true" } else { "false" } );

The C fathers invented:

print_string (a ? "true" : "false");

And this raises the question: why has a the "if" expression a special
form and the "while" expression or any other not?

chris dollin

unread,
May 19, 2011, 7:54:13 AM5/19/11
to ceving, golang-nuts
On 19 May 2011 12:11, ceving <cev...@gmail.com> wrote:
> On 19 Mai, 11:16, chris dollin <ehog.he...@googlemail.com> wrote:
>>
>> > The ternary operator in C is only a hack by placing the "if"
>> > expression over all other expressions.
>>
>> I don't understand what you mean by "placing the "if"
>>  expression over all other expressions."
>
> The ? operator in C is equivalent to an "if" expression.
>
>    a = a ? "true" : "false";
>
>    if (a) {
>        a = "true";
>    } else {
>        a = "false";
>    }
>
> The problem in C is that you are not allowed to use the "if"
> expression as an argument to a function call, because the "if"
> expression has no return value.

No, because the if /statement/ -- in common with most of C's
statements -- doesn't have a value. ?: /is/ the if-expression.

(unlike, say, Algol 68 or Bliss.)

> Instead of writing:
>
>    print_string ( if (a) { "true" } else { "false" } );
>
> The C fathers invented:
>
>    print_string (a ? "true" : "false");

Probably following on from C's ancestor BCPL, which used
`Etest => Etrue, EFalse`.

> And this raises the question: why has a the "if" expression a special
> form and the "while" expression or any other not?

Because for the other forms there isn't a clear rule determining
what the result value would be [1], nor was there significant pressure
for giving while/break/continue/goto/switch/for value-returning
forms.

[1] I mean that there isn't a natural and obvious way (for C) to
decide among the possible rules for these structures, not that
no such rules can be constructed.

Other languages may have natural and obvious rules arising
from their choices of syntax and semantics.

--
Chris "allusive" Dollin

ceving

unread,
May 19, 2011, 8:20:09 AM5/19/11
to golang-nuts
On 19 Mai, 13:54, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > And this raises the question: why has a the "if" expression a special
> > form and the "while" expression or any other not?
>
> Because for the other forms there isn't a clear rule determining
> what the result value would be [1], nor was there significant pressure
> for giving while/break/continue/goto/switch/for value-returning
> forms.
>
> [1] I mean that there isn't a natural and obvious way (for C) to
>     decide among the possible rules for these structures, not that
>    no such rules can be constructed.

What is unclear about the rule, that the last statement specifies the
return value?

chris dollin

unread,
May 19, 2011, 8:29:04 AM5/19/11
to ceving, golang-nuts

Two things: (a) it doesn't work usefully for break, continue, goto, or
switch, especially the latter; (b) as I said, I mean that there's no
clear rule /for choosing the rule to use/. There are lots of clear rules
you could apply, and you've picked on, but on what grounds?
(c) What's the value of a for/while which doesn't iterate?

Chris
--
Chris "nobody expects the spangled intromission" Dollin

ceving

unread,
May 19, 2011, 10:19:26 AM5/19/11
to golang-nuts
On 19 Mai, 14:29, chris dollin <ehog.he...@googlemail.com> wrote:
>
> Two things: (a) it doesn't work usefully for break, continue, goto, or
> switch, especially the latter;

I agree with you that a return value for a jump does not make much
sense but a "switch" should have a return value and two corresponding
statements "cond" and "case" in Scheme of course have one.

> (b) as I said, I mean that there's no
> clear rule /for choosing the rule to use/. There are lots of clear rules
> you could apply, and you've picked on, but on what grounds?

A good rule of the thumb could be "What is most practical?". And this
discussion shows: an "if" that returns a value is practical for many
people.

> (c) What's the value of a for/while which doesn't iterate?

To do something when it is useful does not make it necessary to do the
same when it is not useful.

chris dollin

unread,
May 19, 2011, 10:39:45 AM5/19/11
to ceving, golang-nuts
On 19 May 2011 15:19, ceving <cev...@gmail.com> wrote:

> A good rule of the thumb could be "What is most practical?". And this
> discussion shows: an "if" that returns a value is practical for many
> people.

As I said earlier about why `if` was privileged over `while` etc

nor was there significant pressure
for giving while/break/continue/goto/switch/for value-returning
forms.

It's about practicality (and usefulness), not completeness.

>> (c) What's the value of a for/while which doesn't iterate?
>
> To do something when it is useful does not make it necessary to do the
> same when it is not useful.

That may be true. Are you claiming that it is not useful to define the
value returned by a for loop that doesn't iterate, or that it's not useful
to define the value of a for loop at all?

Chris

(who has in his hands a language which defines the result value(s)
of a for loop, whether or not it it iterates zero times.)

--
Chris "allusive" Dollin

Gustavo Niemeyer

unread,
May 19, 2011, 11:05:58 AM5/19/11
to chris dollin, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
> So this suggests to me that the comma operator is a red herring, and
> that the mere possiblility of having horribly complicated conditional
> expressions does'nt mean that conditional expressions need be horrible,

The point is that people very often come up with horrible unreadable
logic using it, and for some reason they find that ok. It's much more
difficult to come up with a horrible unreadable 'if' version of the
same logic without it being obvious that it's horrible and unredable.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

chris dollin

unread,
May 19, 2011, 11:10:22 AM5/19/11
to Gustavo Niemeyer, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On 19 May 2011 16:05, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> So this suggests to me that the comma operator is a red herring, and
>> that the mere possiblility of having horribly complicated conditional
>> expressions does'nt mean that conditional expressions need be horrible,
>
> The point is that people very often come up with horrible unreadable
> logic using it,

BLUFF.

> and for some reason they find that ok.  It's much more
> difficult to come up with a horrible unreadable 'if' version of the
> same logic without it being obvious that it's horrible and unredable.

Well, that's what culture-building and code reviews are for.

Gustavo Niemeyer

unread,
May 19, 2011, 11:44:00 AM5/19/11
to chris dollin, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
>> The point is that people very often come up with horrible unreadable
>> logic using it,
>
> BLUFF.

http://groups.google.com/group/golang-nuts/browse_thread/thread/206a3e00e28c589c#9b886de560dbdb40

eaburns

unread,
May 19, 2011, 12:09:23 PM5/19/11
to golan...@googlegroups.com, ceving
I think that OCaml defines it to be the value 'unit':

# let a = for i = 0 to -1 do Printf.printf "hello\n" done;;
val a : unit = ()

Steven

unread,
May 19, 2011, 12:20:43 PM5/19/11
to chris dollin, ceving, golang-nuts
On Thursday, May 19, 2011, chris dollin <ehog....@googlemail.com> wrote:
> That may be true. Are you claiming that it is not useful to define the
> value returned by a for loop that doesn't iterate, or that it's not useful
> to define the value of a for loop at all?
>
> Chris
>
> (who has in his hands a language which defines the result value(s)
>  of a for loop, whether or not it it iterates zero times.)

In Scala, a for loop evaluates to a list of the values that are
yielded by each iteration. Thus, a loop that doesn't iterate evaluates
to an empty list. I don't, however, think this behaviour would be
useful for Go because it hides the allocation from the programmer.

I think the ternary operator is unique in that it is concise and
consolidates the assignment, clarifying intent. A loop doesn't have
the duplication of an if-else. A switch is likely going to be large
enough to warrant a function if need be.

Simply good formatting (hello gofmt) can deal with a lot of the more
ungainly looking ones, and restraint with the rest.

chris dollin

unread,
May 19, 2011, 12:37:07 PM5/19/11
to Gustavo Niemeyer, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On 19 May 2011 16:44, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>>> The point is that people very often come up with horrible unreadable
>>> logic using it,
>>
>> BLUFF.
>
> http://groups.google.com/group/golang-nuts/browse_thread/thread/206a3e00e28c589c#9b886de560dbdb40

Well, firstly I discussed those examples in that very thread,
and secondly, it doesn't support "... people very often".

I can paste in a page of straightfoward examples as
counteranecdotes if you like.

Gustavo Niemeyer

unread,
May 19, 2011, 1:03:21 PM5/19/11
to chris dollin, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
> Well, firstly I discussed those examples in that very thread,
> and secondly, it doesn't support "... people very often".
>
> I can paste in a page of straightfoward examples as
> counteranecdotes if you like.

No, thanks. The fact you can do wonderful things with Uranium is not
an argument to stock it in your backyard.

</bikeshed>

chris dollin

unread,
May 19, 2011, 1:26:26 PM5/19/11
to Gustavo Niemeyer, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On 19 May 2011 18:03, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> Well, firstly I discussed those examples in that very thread,
>> and secondly, it doesn't support "... people very often".
>>
>> I can paste in a page of straightfoward examples as
>> counteranecdotes if you like.
>
> No, thanks.  The fact you can do wonderful things with Uranium is not
> an argument to stock it in your backyard.
>
> </bikeshed>

Fortunately conditional expressions aren't Uranium [1] and nobody
is attempting to stock their programs with it to the exclusion of
all other statements, not to mention good taste.

The existence of a plentiful supply of allegedly-non-horrible
conditional expressions is intended to bring a sense of relief
to those who have been over-exposed to the horrible variants.

Chris

--
Chris "[1] Jeremy .. bring Uranium" Dollin

Steven

unread,
May 19, 2011, 1:28:13 PM5/19/11
to Gustavo Niemeyer, chris dollin, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts
On Thursday, May 19, 2011, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> Well, firstly I discussed those examples in that very thread,
>> and secondly, it doesn't support "... people very often".
>>
>> I can paste in a page of straightfoward examples as
>> counteranecdotes if you like.
>
> No, thanks.  The fact you can do wonderful things with Uranium is not
> an argument to stock it in your backyard.

Your examples for "bad" use of conditional expressions are more often
than not just poorly formatted (we have gofmt) or just plain silly.
Hardly Uranium.

Steven

unread,
May 19, 2011, 1:30:08 PM5/19/11
to chris dollin, Gustavo Niemeyer, Skip Tavakkolian, Russ Cox, Sam Fredrickson, golang-nuts

I would like to see this page of allegedly-non-horrible conditional
expressions :).

chris dollin

unread,
May 19, 2011, 2:37:19 PM5/19/11
to golang-nuts
On 19 May 2011 18:30, Steven <stev...@gmail.com> wrote:

> I would like to see this page of allegedly-non-horrible conditional
> expressions :).

I'll attach it so it's not in-your-face for the uninterested, and prune
the To: & Cc: lists down just to golang-nuts.

So I did this on the Jena [RDF toolkit, Java, yada yada] core checkout:

find -name "*.java" | xargs grep "\?" | grep " : " | grep -v "<?" |
grep -v Test | sed -e 's/[^:]*:[ \t]*//' > qq.text

\? to find conditional expressions or a part thereof, " : " to try and get
the else-part as well, "<?" to strip out some funny generics (probably
unnecessary), and sed to strip out the leading filename & whitespace.

Then I trimmed it down to the first 100 (out of 995 matching lines),
because 100 lines is a big page but 995 lines is a three-volume novel.

We lose the multi-line examples -- I know they're there, I wrote
some of them -- but I think this is illustrative enough.

(Interestingly, highlighting the conditionals like this has shown
me some duplication that might want a bit of attention ...)

Arlen Cuss

unread,
May 19, 2011, 10:29:13 PM5/19/11
to golan...@googlegroups.com, ceving

> I think that OCaml defines it to be the value 'unit':
>
>
> # let a = for i = 0 to -1 do Printf.printf "hello\n" done;;
> val a : unit = ()

All for loops in OCaml evaluate to unit:


# let a = for i = 0 to 10 do 42 done;;
Warning S: this expression should have type unit.


val a : unit = ()

(as should the expressions within)

--
Arlen Cuss
Software Engineer

Phone: +61 3 9877 9921
Email: ar...@noblesamurai.com

Noble Samurai Pty Ltd
Level 1, 234 Whitehorse Rd
Nunawading, Victoria, 3131, Australia

noblesamurai.com | arlen.co

signature.asc

Eleanor McHugh

unread,
May 20, 2011, 9:57:00 AM5/20/11
to golang-nuts

+1

The argument that syntax makes for horrible and unreadable code is a complete red herring as I've seen ugly unreadable code in every language I've ever worked in, including Lisp - and the latter is hardly over-burdened with syntactic complexity.

Two of my favourite languages - Ruby and Icon - are expression-oriented and support the x ? a : b syntax. In both cases I use it routinely in place of if-then-else for short expressions where the resulting code would be easier to read. Icon being goal-directed goes a step further and allows me to use the ternary operator to catch expression failure, much like we use recover in Go to catch panics :)

Arguably as Go is statement-oriented this syntax isn't as good a fit for the language, but like a number of others I'd still quite like to have it available at times where conciseness improves readability.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
if _, ok := reality.(Reasonable); !ok { panic(reality) }

Reply all
Reply to author
Forward
0 new messages