[DGD]1.1.52

[Mikael Lind]

On Sat, 13 Mar 1999, Par Winzell wrote:

> The only alternative I can think of is this: introduce a boolean type and
> a truth value, letting nil be false. Let ! always map into this type, and
> make 0 and 0.0 aliases for nil in comparisons the same way all non-nil
> strings, arrays, objects and mappings are aliases for true. This allows
> e.g.
> 
>         if (!some_number == !this_object()) { ... }
> 
> for all those of you who don't want to have to compare integers explicitly
> with zero. :-)
> 
> Is this consistent?

If the addition of true and false is considered too costly (backwards
compatibility reasons), then your alternative would still be a great
improvement compared to how things work at the moment. I think that the
null value is used for false in LISP. 

On Sat, 13 Mar 1999, Stephen Schmidt wrote:

> On Sat, 13 Mar 1999, Mikael Lind wrote:
>
> > For instance, a construction such as
> > 
> >     if (string_value) {
> >         print(string_value + "\n");
> >     }
> > 
> > is logically hairy but practically useful. I use it all of the time. But I
> > don't like it. There is of course the elegant alternative
> > 
> >     if (string_value != nil) {
> >         print(string_value + "\n");
> >     }
>  
> I prefer the scond, more elegant alternative. I'm always willing
> to add seven additional characters to my code for a gain in
> clarity/elegance. I add thousands of characters in comments for
> the same reason, so what harm does seven more do?

They don't do any harm. I wrote:

"I could use this, but I don't want to. Since the interpretations of
the tests are identical, I prefer the shorter form. This is something
that may or may not make sense to you."

My interpretation is the same as DGD's. It's hard to explain why I prefer
the first form, since preference depends on many factors.

> > I also think
> > that a certain amount of strictness in a programming language such as LPC
> > is solely positive. Unfortunately, I feel like I'm having a hard time
> > formulating my thoughts on the subject. Can anyone tell me what I'm trying
> > to say? 
>  
> Dunno if this is what you're trying to say or not, but the more
> strictness you have in the language, the easier it is for newbies
> to get compile-time errors (which are easier for them to fix)
> rather than runtime errors (which are far harder for them to fix).
> In my experience, anyway. YMMV.

Yes, this is a good point. (What does YMMV mean?)

On Sun, 14 Mar 1999, Gregory D Lewis wrote:

> > I'd like to stop here and request feedback. It is my opinion that the
> > introduction of a boolean type would improve clarity in code. I also think
> > that a certain amount of strictness in a programming language such as LPC
> > is solely positive. Unfortunately, I feel like I'm having a hard time
> > formulating my thoughts on the subject. Can anyone tell me what I'm trying
> > to say? 
> 
> I do however believe a boolean type adds greatly to the clarity of a language.
> A variable or function of this type has made one aspect of its existence
> abundantly clear to anyone reading the code, it is for the use of a true
> or false value.  To use an int instead you've immediately added a degree of
> obfuscation to your code, variable/function naming schemes notwithstanding.
> Certainly people can (and have) done things such as "#define TRUE 1" and the
> like, but these really boil down to somewhat kludgey workarounds (IMO).

I agree.

> For compatibility concerns, one can always introduce the boolean type in much
> the same way as C++, where it may cast to a 0 or 1 as an int.

In general, I dislike implicit casts.

// Mikael

List config page:  http://list.imaginary.com/mailman/listinfo/dgd