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

[Byron Jeff]

On Sun, Oct 27, 2013 at 03:10:11PM -0400, Ron Frazier (ALE) wrote:
> Hi Byron,
> 
> Interestingly enough, the indentation you showed didn't appear on my reader until I hit reply.  Now, I can see it.

I still use a text E-mail reader: mutt. Sometimes it's difficult to know
when my posts are going to format properly.

> 
> 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.

All true. Personally I added ELSEIF and ENDIF constructs to all the
languages I designed over the years along with one statement per line so
that explicit statement terminators (semicolon) were unnecessary.

> 
> 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.

The key is that in this instance the indentations cleans up the language
significantly. Here are the two examples with endifs:


if a > 5:
   if b < 3:
      call_small_b()
   else
      call_big_b()
   endif
endif

as opposed to:

if a > 5:
   if b < 3:
      call_small_b()
   endif
else
   call_small_a()
endif

I agree that the endifs disambiguate each by the appropriate closing of the
if. The problem is that now each and every control structure now is
extended by an extra line of code that conveys little meaning if the code
is properly indented.

My point is that enforced indentation both makes the code syntatically
cleaner, while at the same time makes it more readable. It literally
creates a semantic contract between the code author and the
compilation/runtime system. Less typing, less maintenance, less errors.

Personally I think the minor annoyance is worth the winning features, IMHO.

BAJ


> 
> 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
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
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