Could this be a BAD thing? 
Author Message
 Could this be a BAD thing?

I'm not much of an expert when it comes to language design, parsing,
and all that really brainey stuff, but it seems like this is a bad
thing:

define variable my-junk = 12345;
                        ^
my-junk := 98765;
        ^^

I've already tripped on this once or twice.  Seemingly this is no big
deal.  After all, there's always something to get used to right?

But think about it this way: why not change the initialization
delimiter
to ':=' instead of '=' and avoid any possible confusion?

Recently I was converting the line of code

   let my-var = "foo";

to an assignment rather than a declaration/init like this

   my-var = "foo";

Oops!  That evaluates fine, but doesn't do what I want, so I miss it
and "things don't work so well."

I know this is rather picky, but consistency is important and Dylan
seems a little inconsistant here (for no reason as far as I can tell.)
Otherwise, dylan looks great!  I can't wait to get a real application
development system that's based on it.


                                                  -Me



Tue, 01 Apr 1997 11:39:26 GMT  
 Could this be a BAD thing?

   I'm not much of an expert when it comes to language design, parsing,
   and all that really brainey stuff, but it seems like this is a bad
   thing:

   define variable my-junk = 12345;
                           ^
   my-junk := 98765;
           ^^

Believe me, details like this have been thought about and debated at
great length.  In this case, several of the designers fervently
believe that assignment is very different from initialization (more
dangerous, in some sense) and should look different and more prominent
in code.  This argument prevailed -- most of those who felt otherwise
didn't feel so strongly about it.

-- Scott

===========================================================================

Principal Research Scientist            Phone:     412 268-2575
School of Computer Science              Fax:       412 268-5576 (new!)
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213                    Mood:      :-)
===========================================================================



Tue, 01 Apr 1997 12:59:28 GMT  
 Could this be a BAD thing?

Quote:


>   I'm not much of an expert when it comes to language design, parsing,
>   and all that really brainey stuff, but it seems like this is a bad
>   thing:

>   define variable my-junk = 12345;
>                       ^
>   my-junk := 98765;
>       ^^

>Believe me, details like this have been thought about and debated at
>great length.  In this case, several of the designers fervently
>believe that assignment is very different from initialization (more
>dangerous, in some sense) and should look different and more prominent
>in code.  This argument prevailed -- most of those who felt otherwise
>didn't feel so strongly about it.

I could agree with this reasoning, but then why make the notation
look like comparison?  Haven't we learned from C's mistake?  How about

  define variable my-junk : 12345;
or
  define variable my-junk(12345);
or even
  define variable my-junk <- 12345;

John Panzer



Tue, 01 Apr 1997 14:48:55 GMT  
 Could this be a BAD thing?

   [...]

   I could agree with this reasoning, but then why make the notation
   look like comparison?  Haven't we learned from C's mistake?  How about

     define variable my-junk : 12345;
   or
     define variable my-junk(12345);
   or even
     define variable my-junk <- 12345;

In C this was a problem because the un-initiated ended up doing an
assignment instead of a comparison, and (depending on the program) the
result could linger undetected indefinitely.  In Dylan, you'll get a
comparison instead of an assignment.  This is likely to be found
rather quickly.

Also, some future Dylan compiler could quite reasonably detect that a
comparison was being done and the result simply discarded, and issue a
warning.  The only case this would not catch is when the expression
occures at the end of a compound expression (ie. it would look like
the compound result was intended to be #t or #f).

For the mathematically cognizant (a gifted subset of humanity of which
I am *not* a member!) using = for initialization and comparison does
make some sense.  Initialization is like definition.  If I say

        "let a = 5"

to a math-type that means a is equivalent to 5, period.  If I then say

        "if a = 7"

or whatever, there's no confusion about what's meant.  Assignment is,
however, a distinctly different (and un-natural) operation and
*should* have a distinct operator.

In summary, I like the status-quo!
--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Wed, 02 Apr 1997 00:49:00 GMT  
 Could this be a BAD thing?

   [...]

   I could agree with this reasoning, but then why make the notation
   look like comparison?  Haven't we learned from C's mistake?  How about

     define variable my-junk : 12345;
   or
     define variable my-junk(12345);
   or even
     define variable my-junk <- 12345;

In C this was a problem because the un-initiated ended up doing an
assignment instead of a comparison, and (depending on the program) the
result could linger undetected indefinitely.  In Dylan, you'll get a
comparison instead of an assignment.  This is likely to be found
rather quickly.

Also, some future Dylan compiler could quite reasonably detect that a
comparison was being done and the result simply discarded, and issue a
warning.  The only case this would not catch is when the expression
occures at the end of a compound expression (ie. it would look like
the compound result was intended to be #t or #f).

For the mathematically cognizant (a gifted subset of humanity of which
I am *not* a member!) using = for initialization and comparison does
make some sense.  Initialization is like definition.  If I say

        "let a = 5"

to a math-type that means a is equivalent to 5, period.  If I then say

        "if a = 7"

or whatever, there's no confusion about what's meant.  Assignment is,
however, a distinctly different (and un-natural) operation and
*should* have a distinct operator.

In summary, I like the status-quo!
--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Tue, 01 Apr 1997 21:49:46 GMT  
 Could this be a BAD thing?

   I could agree with this reasoning, but then why make the notation
   look like comparison?  Haven't we learned from C's mistake?

It sounds as if you are saying that C's mistake was to make the
notation (for assignment and/or initialization) look like the notation
for comparison.  Although I am no friend of C, I must point out that C
does not do that; comparison has a different notation.  If I remember
correctly, ALGOL 60 and PL/I use the same notation for both.



Fri, 04 Apr 1997 02:43:49 GMT  
 Could this be a BAD thing?

Quote:


>   I could agree with this reasoning, but then why make the notation
>   look like comparison?  Haven't we learned from C's mistake?

>It sounds as if you are saying that C's mistake was to make the
>notation (for assignment and/or initialization) look like the notation
>for comparison.  Although I am no friend of C, I must point out that C
>does not do that; comparison has a different notation.  If I remember
>correctly, ALGOL 60 and PL/I use the same notation for both.

I think the problem is that '=' is used for different things in
different languages.  ':=' says "assignment" (just because languages
don't use := for comparison), '==' says "comparison" (due to C's
popularity), and '=' can be either, depending on the language.

C's mistake is that both = and == are valid in expressions, so people
moving from another language often use = instead of == for comparison.
I don't know the Dylan syntax yet, but my understanding is that := or
<- is used for assignment, and = is used for comparison.  If so, then
we will have the opposite problem -- people moving from C will use =
for assignment instead of :=.

I think the way to avoid all of this would be to use := for assignment
and == for comparison, and don't allow = to be used in expressions.
(Perhaps = can be used only in initialization.)  People don't seem to
get := and == confused -- just (:= and =) or (= and ==).

        My opinions only,

        Amit



Fri, 04 Apr 1997 07:32:48 GMT  
 Could this be a BAD thing?

Quote:


>   I could agree with this reasoning, but then why make the notation
>   look like comparison?  Haven't we learned from C's mistake?

>It sounds as if you are saying that C's mistake was to make the
>notation (for assignment and/or initialization) look like the notation
>for comparison.  Although I am no friend of C, I must point out that C
>does not do that; comparison has a different notation.  If I remember
>correctly, ALGOL 60 and PL/I use the same notation for both.

The common mistake is that the Dylan initialization syntax will IMHO
lead to the same sort of hard-to-see bugs which are exemplified by
"if (i=42)" in C.

Of course, for an experienced C programmer such an error is fairly
easy to spot.  This is because C programmers are sensitized to
the problem by hours of debugging in their formative years.
It would be unfortunate if Dylan programmers had to go through
the same sort of initiation.

Perhaps "mistake" is too strong a word - "wart" might be a better
description.

John Panzer          



Fri, 04 Apr 1997 12:55:34 GMT  
 Could this be a BAD thing?

Quote:


> >  The common mistake is that the Dylan initialization syntax will IMHO
> >  lead to the same sort of hard-to-see bugs which are exemplified by
> >  "if (i=42)" in C.

> I know people who write  "if (42==I)"  just to avoid this sort of problem.
> (i.e. Accidentally writing  "if (42=I)"  will fail to compile.)

> --Jon

Howdy,
        Yup - that's what I do when I can't write
(if (eq i 42)...) ;-)  I'm used to writing C this way
now. OTOH, I get lazy and miss more cases of two var
comparisons, e.g. if(a = /*whoops*/ b)...

=============================================
Scott McLoughlin
Conscious Computing
=============================================



Sat, 05 Apr 1997 10:04:10 GMT  
 Could this be a BAD thing?

Quote:

>  The common mistake is that the Dylan initialization syntax will IMHO
>  lead to the same sort of hard-to-see bugs which are exemplified by
>  "if (i=42)" in C.

I know people who write  "if (42==I)"  just to avoid this sort of problem.
(i.e. Accidentally writing  "if (42=I)"  will fail to compile.)

--Jon



Sat, 05 Apr 1997 06:33:29 GMT  
 Could this be a BAD thing?

Quote:


(Robert Stone) writes:

>    I'm not much of an expert when it comes to language design, parsing,
>    and all that really brainey stuff, but it seems like this is a bad
>    thing:

>    define variable my-junk = 12345;
>                            ^
>    my-junk := 98765;
>            ^^
> Believe me, details like this have been thought about and debated at
> great length.  In this case, several of the designers fervently
> believe that assignment is very different from initialization (more
> dangerous, in some sense) and should look different and more prominent
> in code.  This argument prevailed -- most of those who felt otherwise
> didn't feel so strongly about it.

Let's grant the point that initialization and assignment are significantly
different.  This does not imply that "=" is a good choice for
initialization.  With the overall confusion surrounding the "=" character
in various computer languages, avoiding it altogether seems to be the best
idea to me.

Michael Korcuska
Institute for the Learning Sciences
Northwestern University



Sun, 06 Apr 1997 01:43:07 GMT  
 Could this be a BAD thing?

Quote:

> [Assignment and comparison] If I remember correctly, ALGOL 60
> and PL/I use the same notation for both.

PL/I does; Algol 60 does not.

John L

P.S. (define x 5)
     (set! x 7)

Hmm. The whole problem disappears, doesn't it?



Sun, 06 Apr 1997 02:41:36 GMT  
 Could this be a BAD thing?

Quote:

> I think the problem is that '=' is used for different things in
> different languages.  ':=' says "assignment" (just because languages
> don't use := for comparison), '==' says "comparison" (due to C's
> popularity), and '=' can be either, depending on the language.

> C's mistake is that both = and == are valid in expressions, so people
> moving from another language often use = instead of == for comparison.
> I don't know the Dylan syntax yet, but my understanding is that := or
> <- is used for assignment, and = is used for comparison.  If so, then
> we will have the opposite problem -- people moving from C will use =
> for assignment instead of :=.

> I think the way to avoid all of this would be to use := for assignment
> and == for comparison, and don't allow = to be used in expressions.
> (Perhaps = can be used only in initialization.)  People don't seem to
> get := and == confused -- just (:= and =) or (= and ==).

>    My opinions only,

>    Amit

Seconded.

Mark



Mon, 07 Apr 1997 06:17:58 GMT  
 Could this be a BAD thing?

Quote:

>I think the way to avoid all of this would be to use := for assignment
>and == for comparison, and don't allow = to be used in expressions.
>(Perhaps = can be used only in initialization.)  People don't seem to
>get := and == confused -- just (:= and =) or (= and ==).

Agreed.  I'd say a majority of the defects I find in C are from using "="
instead of "==", rather than vice versa.  I'm much more likely to omit a
character than add another.

John Brewer
Wolfram Research, Inc.
(but speaking for myself)



Tue, 08 Apr 1997 02:08:06 GMT  
 Could this be a BAD thing?

Quote:



>> I think the problem is that '=' is used for different things in
>> different languages.  ':=' says "assignment" (just because languages
>> don't use := for comparison), '==' says "comparison" (due to C's
>> popularity), and '=' can be either, depending on the language.

>> C's mistake is that both = and == are valid in expressions, so people
>> moving from another language often use = instead of == for comparison.
>> I don't know the Dylan syntax yet, but my understanding is that := or
>> <- is used for assignment, and = is used for comparison.  If so, then
>> we will have the opposite problem -- people moving from C will use =
>> for assignment instead of :=.

>> I think the way to avoid all of this would be to use := for assignment
>> and == for comparison, and don't allow = to be used in expressions.
>> (Perhaps = can be used only in initialization.)  People don't seem to
>> get := and == confused -- just (:= and =) or (= and ==).

>>        My opinions only,

>>        Amit

>Seconded.

>Mark

Thirded.

Quote:

> P.S. (define x 5)
>      (set! x 7)

>      Hmm. The whole problem disappears, doesn't it?

Seconded.

--
  Dave Yost



Thu, 10 Apr 1997 07:51:06 GMT  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Find out what bad things STIC is up to

2. Exceptions: Are they a Bad Thing?

3. Why Tcl is a Bad Thing

4. Could this be a BAD thing?

5. SSSCA: A bad thing for open source

6. syntax completion - a bad thing?

7. Bad thing about Tcl/Tk Manuals

8. The Worst Things in TK

9. The Worst Things in TK

10. Why Tcl is a Bad Thing

11. Things I am wondering...

12. Am I seeing things?...

 

 
Powered by phpBB® Forum Software