[ale] Any language (wuz: Assembly Language?)

[Ron Frazier (ALE)]

Hi Byron,

Interestingly enough, the indentation you showed didn't appear on my reader until I hit reply.  Now, I can see it.

It's been a LONG time since I've actively programmed in Clipper.  I assume the compiler would enforce a rule like you mentioned to tie the else clause to the closest open if statement.  However, I believe you could use braces, parentheses, etc. to delimit things where the automatic syntax parser would get confused.  I cannot remember for sure.  Another way to avoid ambiguity is to always include the if, then, else, endif keywords in languages that support that.

I do believe humans should indent code so other humans can read it.  I just don't believe that not doing so should cause a compile failure or a runtime failure.

Sincerely,

Ron



Byron Jeff <byronjeff at mail.clayton.edu> wrote:

>On Sun, Oct 27, 2013 at 09:31:39AM -0400, Ron Frazier (ALE) wrote:
>
>> In my opinion, the best language should ignore all white space AND
>NOT
>> require any curly braces or semicolons except as syntactically
>required
>> delimiters for lists and arrays, etc.  That's the way Clipper was,
>and it
>> was a real pleasure that the compiler wasn't always bugging me about
>> formatting yet still figured out how to compile the program.
>
>I cannot see how it can be without braces. How do you differentiate
>this:
>
>if a > 5 then if b < 3 then call_small_b() else do_you
>call_small_a_or_big_b ()
>
>Python makes it clear:
>
>if a > 5:
>   if b < 3:
>      call_small_b()
>   else
>      call_big_b()
>
>as opposed to:
>
>if a > 5:
>   if b < 3:
>      call_small_b()
>else
>   call_small_a()
>
>Braces can disambiguate the two also. But unless a rule is imposed that
>else is always associated with the closest open if, then the original
>construct is ambiguous. And if that rule is imposed, then there's no
>way to
>do the second construct.
>
>Then there is the philosophical issue of indentation. Indentation is
>rarely
>for the benefit of the compiler. It's task is to create organization
>for
>human readers. Reading improperly indented code is one of the biggest
>headaches. And as a Professor is unfortunately a task I have to do more
>often than I like.
>
>Python's use of significant whitespace is one of the tools that
>actually
>simplifies the language syntax. One statement per line so no semicolons
>are
>required. Indentation replaces braces. It also enhances readability. If
>my
>E-mail is properly formatted, then the two constructs above are
>visually
>clear in their intent, while the original is ambiguous because there is
>no
>imposed structure.
>
>Of course all this is IMHO.
>
>BAJ
>
>

-snip-

>
>-- 
>Byron A. Jeff
>Chair: Department of Computer Science and Information Technology
>College of Information and Mathematical Sciences
>Clayton State University
>http://faculty.clayton.edu/bjeff



--

Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.
Please excuse my potential brevity if I'm typing on the touch screen.

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new email messages very quickly.)

Ron Frazier
770-205-9422 (O)   Leave a message.
linuxdude AT techstarship.com
Litecoin: LZzAJu9rZEWzALxDhAHnWLRvybVAVgwTh3
Bitcoin: 15s3aLVsxm8EuQvT8gUDw3RWqvuY9hPGUU