Call by Result

[Arved Sandstrom]

The JLS does not defined »String value«, so you are all free to
define it as you like to. However, we also have

!( null instanceof java.lang.String )

. Since the objects of a value class are intended to model the
values modulo »equals«, not being an instance of such a class
has some weight in favor of not being a value of that model.

Albeit in some other context, the JLS says with regard to
Annotations,

»Note that null is not a legal element value for any
element type.«

null surely is a /reference value/, but it does not identify
a string value in the sense of the class String as a class
whose instances model string values.

I agree with the statements above, sure. The problem we have is that
'instanceof', say, indicates that 'null' is not an instance of a
reference type like String. But we also have that Java variables of
reference type can be assigned the value 'null' (implicit typecast).

So we end up with a situation where IMHO it's probably advisable not to
try making too much sense of it. The language mechanics have placed us
in the position of accepting that one special value that you can assign
to variables of reference type is _not_ an instance of any reference
type, but can be somehow implicitly typecast to any reference type. If
one ventures (perhaps too far) down this road, one might ask, what is
the implicit special value of String that null is implicitly typecast
_to_, that is nonetheless not an instanceof String?

Down that road lies madness. Hence the JLS' suggestion that programmers
treat null as a special literal that *can be of any reference type*. And
so I treat it, regardless of the behaviour of 'instanceof'.

We also have the difficulty in Java that 'null' appears - frequently -
as a working - albeit "special" - value of reference variables in
programs. People use it to mean uninitialized, unknown, a termination
condition, and I return also to the fact that 'null' is the *default*
value assigned to reference type variables.

Having said all this, let me revisit Option and Maybe. For me the
distinction to be drawn between the *semantics* of Option/Maybe and the
nullability of Java reference-type variables is probably one of degree,
not kind. So I regret using the word "qualitatively" in my previous
post; I'm not sure what word I prefer in its stead . Option/Maybe are
clean and unambiguous types that represent, by design, optional values
of some contained type. The interpretation of 'null' in Java is not so
clean. Furthermore, I can use == and != with 'null' in constructs like

"Arved" != null

just as easily as

"Arved" == "Bill"

which to me further blurs the perception that null is, or isn't,
_effectively_ a value of String or any other reference type. Again, the
JLS suggestion that we pretend that that's what 'null' is.

To return to Andreas' argument, it's certainly possible for any given
Java programmer to rigorously adhere to an interpretation of 'null' as
meaning None or Nothing. That would however be a personal choice; some
other programmer might not do that (it could be Unknown, or No Mapping
For Key X, or End Of Stream). Assuming that None/Nothing is the rigorous
interpretation of 'null' by said programmer, there is still no special
treatment for the 'null' value...we end up testing for it the same way
as we do for object instances. We test for it just like we do for any
other value, but arguably it's special. So special that it's not an
instance of any reference type except the null type.

So I'll stick to the main case, which is simply that Scala option and
Haskell Maybe are better ways of dealing with this notion. In fact so
would BoolStr (or BoolObj) be; Nigel's suggestion. In Java, as I've
expressed, I prefer exceptions anyway, but I absolutely don't like
'null' as a special value (of something) (*). The OP in any case said
that that latter approach will not be acceptable.

AHS

* I'll hold my nose and use it - Java makes it difficult not to.

 

[Andreas Leitgeb]

Yeah, Stefan, that's just how I see it. There's a distinction between
reference values and "values"/objects of the particular instance/class
type.

Unless Scala also has a concept for Some(null) (I do *not* mean
Some(None), as that would then be two Option-layers), we can say
that Java's references are a stock "Option" wrapper for the actual
values. Any further Option layers in Java would not look that simple,
but require some explicit container-object, like a singleton-array or
a custom one-field class's instance.

 

[lewbloch]

I'm not yet sure, whether null in Java counts as a "String value", or not..

I think it is not (whereas the empty string of course is). As such, a
variable (or field) "s" (or even an expression) of type String really
happens to be implicitly the pendant of Haskell's "Option"al String:

Either it is "Null"... (ahem, "null"), or it holds an actual String value..

Ditto for all the non-primitive types.

'null' is an out-of-band 'String' value (or any other reference type).

I use the "is-a {type}" to indicate if assignment (or casting) is
permissible. 'String x = null;' is valid, so 'null' is a 'String' (or
any other reference type) value. It is "out of band", which expresses
the "not-a" concept well enough to write good software.

 

[Arved Sandstrom]

Yeah, Stefan, that's just how I see it. There's a distinction between
reference values and "values"/objects of the particular instance/class
type.

Unless Scala also has a concept for Some(null) (I do *not* mean
Some(None), as that would then be two Option-layers), we can say
that Java's references are a stock "Option" wrapper for the actual
values. Any further Option layers in Java would not look that simple,
but require some explicit container-object, like a singleton-array or
a custom one-field class's instance.

You can do Some(null) in Scala; I mentioned that already in a previous
post. That's an entirely expected behaviour of Option; as far as it's
concerned 'null' is a valid value, just like any other, of the reference
type that it contains.

_You_ can consider Java references to be stock "Option" wrappers for
actual values, sure. It won't hurt anyone if you do. I'm not going to
myself, because unlike Option and Maybe, Java reference types are _not_
wrappers, and the way the language is, 'null' is a legitimate actual
value *of* a reference type variable. There's no wrapping involved. We
happen to ascribe various meanings to this special value, depending on
usage and API, but it's still a value *of* a reference type variable.

AHS

 

[Michael Wojcik]

Well, here is an example in Scala:
[...]
def getString(s : String) : Option[String] =
{
if (s.reverse == s) Some(s.toLowerCase)
else None
}
[...]
val t = getString(s)
[...]
t match
{
case Some(r) => println("Success, return value is: " + r)
case None => println("Failure")
}

Ah, thanks. Yep, I've seen this concept once when playing with
OCaml (which mentions Haskell as one of its roots). Never got
warm with it, though.

They both get it from ML, which AFAIK is the first programming
language in that particular family. It introduced the type inference
and matching features that you find in OCaml (which is the OO version
of Caml, a ML dialect), Haskell, Scala, F# (which is basically OCaml
adapted for .NET), etc.

In the Verona of functional languages, the ML family are the Montagues
to the LISP family's Capulets. Or something like that.

 

[Andreas Leitgeb]

In the Verona of functional languages, the ML family are the Montagues
to the LISP family's Capulets. Or something like that.

And to which of these two families is Prolog more related to?
It does make lot of use of expression-matching like the MLs,
but seems to be quite different, still. A distant cousin?

 

[H.J. Sander Bruggink]

And to which of these two families is Prolog more related to?
It does make lot of use of expression-matching like the MLs,
but seems to be quite different, still. A distant cousin?

Prolog is not a functional language but a logical language and does not
use matching but unification.

But all programming languages influence each other, so probably all
programming languages are distant cousins of all other ones .

groente
-- Sander

 

[Lewis Bloch]

Prolog is not a functional language but a logical language and does not
use matching but unification.

But all programming languages influence each other, so probably all
programming languages are distant cousins of all other ones .

Real programmers can program in FORTRAN in any language.

 

[Cholo Lennon]

Dear Java'ers:

I wish to call by result with a method. Is it possible? If not,
can it be easily simulated in an unnasty way?

I am writing a simple preprocessor. I have a few spots where a
string needs to be parsed. I want to call something like this:
String ReturnString="";
boolean DidItWork=GetString(ReturnString);
if (!DidItWork)
// too bad
It is not acceptable to have a special String value mean failure. I
want the method to be able to return any potential string.

Sincerely,

Gene Wirchenko

IMHO using exceptions is not always the best answer to this problem (as
other suggested).

How about using a simple generic class? (of course, it could be
corrected or improved. A similar idea could be found in other languages
(such as C++ (boost)):

class Optional<T> {
private T value;
private boolean valid;

public Optional(T value) {
setValue(value);
}

public Optional() {
this.valid = false;
}

public boolean isValid() {
return this.valid;
}

public T getValue() {
return this.value;
}

public void setValue(T value) {
this.value = value;
// TODO Shall I set to true when value is null?
this.valid = true;
}

public void invalidate() {
this.value = null;
this.valid = false;
}
}

// Test
Optional<String> result = GetString();
if (!result.isValid()) {
// too bad
...
}
else {
System.out.print(result.getValue());
...
}


Regards

 

[John B. Matthews]

There's a nice family tree here: <http://www.levenez.com/lang/>

I can't help but notice that Oak, the progenitor of Java, has six
influencing languages, rivaled only by Ruby. Hybrid vigor?

Real programmers can program in FORTRAN in any language.

I recall writing Fortran in Pascal for a time, and then Pascal in Java.
More recently, an Ada compiler caught me writing Java.

 

[Paul Cager]

IMHO using exceptions is not always the best answer to this problem (as
other suggested).

Not always, no. But in this case there are hints that the OP regarded
the lack of a String as an error condition - he used phrases such as
"mean failure" and "DidItWork". In that case I think an exception is
appropriate (and less work than many of the other suggestions!).

I believe that cases where neither of the following two options are
appropriate are relatively rare:

- returning null, meaning the "thing" was not found, but that's
only to be expected.
- throwing an exception, meaning that you can't return anything
because an error happened.

 

[lewbloch]

IMHO using exceptions is not always the best answer to this problem (as
other suggested).

How about using a simple generic class? (of course, it could be
corrected or improved. A similar idea could be found in other languages
(such as C++ (boost)):

class Optional<T> {
     private T value;
     private boolean valid;

     public Optional(T value) {
         setValue(value);

It's dangerous to call an overridable method from a constructor.

     }

     public Optional() {
         this.valid = false;

Redundant assignment, but arguably it adds clarity. I don't think it
does, but one could argue that it does.

     }

     public boolean isValid() {
         return this.valid;
     }

     public T getValue() {
         return this.value;
     }

     public void setValue(T value) {
         this.value = value;
         // TODO Shall I set to true when value is null?
         this.valid = true;
     }

     public void invalidate() {
         this.value = null;
         this.valid = false;
     }

}

The original post establishes 'null' as an out-of-band value. Your
code hints at that possibility in a comment, but doesn't enforce the
requirement. If 'null' is out of band, then the boolean variable is
redundant and duplicative. If 'null' is in band, then the boolean
makes more sense, as it would have to to justify the complexity.

 

[Cholo Lennon]

It's dangerous to call an overridable method from a constructor.

Agree, you're right. It was for simplicity.

Redundant assignment, but arguably it adds clarity. I don't think it
does, but one could argue that it does.

Agree, you're right, it was written for clarity.

The original post establishes 'null' as an out-of-band value. Your
code hints at that possibility in a comment, but doesn't enforce the
requirement. If 'null' is out of band, then the boolean variable is
redundant and duplicative. If 'null' is in band, then the boolean
makes more sense, as it would have to to justify the complexity.

Well, the class presents a general solution. Maybe Null could be a valid
value. But you're right, for sake of simplicity I think it's better to
get rid of the boolean variable. If this is the case, we have a
'Nullable' class (see Dot Net version at
http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx)



Regards

 

[Gene Wirchenko]

Not always, no. But in this case there are hints that the OP regarded
the lack of a String as an error condition - he used phrases such as
"mean failure" and "DidItWork". In that case I think an exception is
appropriate (and less work than many of the other suggestions!).

It would be an error in the contexts that I was thinking of, but
that does not make exceptions the way to go.

I now also have a method for getting the next non-blank, non-tab
character from a line. A character being found is correct when
parsing
$quotes "" '' [] ~
and picking up the quotes characters. However, I also use this method
to check for characters after the logical statement end, and in this
case, finding such a character is an error as when parsing
$include "testin.dat" x
(the "x" being wrong).

I do not like the idea that I might have the normal flow of
execution going through a catch block.

[snip]

Sincerely,

Gene Wirchenko