«

Would it be good to allow me to write either:

<cond> ? <code1> : <code2>

or

if(<cond>) then <code1> else <code2>

without forcing me to commit to which context this piece of code will
appear: i.e., expression or statement.

Normally you will choose one or the other, but when you generate code,
sometimes you just don't know.

Now I miss functional lang.

Suggestions? thanks,

"Shin" <> wrote in message
news: oups.com...
> Would it be good to allow me to write either:
>
> <cond> ? <code1> : <code2>
>
> or
>
> if(<cond>) then <code1> else <code2>
>
> without forcing me to commit to which context this piece of
> code will
> appear: i.e., expression or statement.
>
> Normally you will choose one or the other, but when you
> generate code,
> sometimes you just don't know.
>
> Now I miss functional lang.
>
> Suggestions? thanks,
>
Do what you want to do, who's stopping you?

On 28 Jul 2005 15:23:21 -0700, "Shin" <> wrote or quoted :

>Would it be good to allow me to write either:
>
><cond> ? <code1> : <code2>

in what context are you writing this?


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

"Shin" <> writes:

> Would it be good to allow me to write either:
>
> <cond> ? <code1> : <code2>
>
> or
>
> if(<cond>) then <code1> else <code2>
>
> without forcing me to commit to which context this piece of code will
> appear: i.e., expression or statement.

No. It depends on what <code1> and <code2> are. If they are statements,
then you must use "if", and *should* know that it's the only reasonable
context. If they are expressions, and their values are relevant, then
you should us "?:".

The contents of the branches determines the context, and you should
know what they are.

> Normally you will choose one or the other, but when you generate code,
> sometimes you just don't know.

If you don't know when you generate the code, when will you know?

> Now I miss functional lang.

.... which is easier only because everything is an expression.

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen wrote:

> > Normally you will choose one or the other, but when you generate code,
> > sometimes you just don't know.
>
> If you don't know when you generate the code, when will you know?
>

Without getting into two much detail, here is the thing: when you are
tranversing an abstract syntax tree, you see a function call node, you
want to generate code so that two function calls are guarded by a
condition, i.e.,

<cond> ? foo() : bar()

Depends on the design of the AST, you may not easily figure out this
function call appears in an expression or statement context. I am not
saying it's impossilbe; I am saying if we can blend expr and statement,
it will be a lot easier in this situation. And I don't think
side-effect argument (i.e., Java disallows this because it would be
hard to manage side-effects if otherwise) apply here.

-Shin

"Shin" <> writes:

> <cond> ? <code1> : <code2>

Here, <code1> and <code2> must be expressions evaluating to values of
the same type - these are returned by the expression.

> if(<cond>) then <code1> else <code2>

while here they are statements that don't (need to) evaluate to
anything. Nothing is returned by the if statement.

So you use the former when it is wise, and the latter in most other
cases since it doesn't have the restrictions of the former.

In Lisp, the if function acts like the first case, apart from the lack
of strict typing.

(if (condition_expression) (true_expression) (false_expression))

Tor Iver Wilhelmsen wrote:
> "Shin" <> writes:
>
>><cond> ? <code1> : <code2>
>
> Here, <code1> and <code2> must be expressions evaluating to values of
> the same type - these are returned by the expression.

Not strictly accurate, even for reference types. In old versions of the
language, either the static type of <code1> must be assignable from the
static type of <code2>, or vice versa. Kind of handy if you are using
null. From 1.5 the resultant static type is the intersection of <code1>
and <code2> which may not be expressible in Java (except as a generic
parameter).


Be very conservative generating code. Cool tricks to shorten object code
probably are not worthwhile.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/