Re: Pointers to "why C behaves like that ?"

"Daniel Yokomiso" <daniel_yokomiso@softhome.net>
26 Nov 2002 22:13:16 -0500

          From comp.compilers

Related articles
[40 earlier articles]
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-26)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-26)
Re: Pointers to "why C behaves like that ?" Nicola.Musatti@ObjectWay.it (Nicola Musatti) (2002-11-26)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-11-26)
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-11-26)
Re: Pointers to "why C behaves like that ?" fjh@students.cs.mu.OZ.AU (Fergus Henderson) (2002-11-26)
Re: Pointers to "why C behaves like that ?" daniel_yokomiso@softhome.net (Daniel Yokomiso) (2002-11-26)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-12-01)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-12-01)
[20 later articles]
| List of all articles for this month |

From: "Daniel Yokomiso" <daniel_yokomiso@softhome.net>
Newsgroups: comp.compilers
Date: 26 Nov 2002 22:13:16 -0500
Organization: Compilers Central
References: 02-11-083 02-11-097 02-11-105 02-11-137
Keywords: types
Posted-Date: 26 Nov 2002 22:13:16 EST

----- Original Message -----
From: "Mark" <whopkins@alpha2.csd.uwm.edu>
Sent: Sunday, November 24, 2002 3:27 AM
Subject: Re: Pointers to "why C behaves like that ?"


> Robert A Duff wrote:
> > Languages should be designed primarily for the human reader.
>
> Oftentimes this is stated as code for "languages should be designed
> with lots and lots of words and stuff instead of those naughty braces
> and brackets '}', '{', ')', '(', and cryptic symbolism" all the while
> completely forgetting that the vast majority of people on Earth will
> find the words EVEN MORE cryptic (even more: because something's
> less understandable when it's longer too) because the language the words
> are in is not their native language!
>
> The only assurance for making the language suitable for humans (as
> opposed to humans that speak language X at the expense of all other
> humans) is maximizing the incidence of wordless symbolism at the
> expense of anything natural language-specific.
>
> So, really, even the while statement should be replaced by -- say -- the
> Kleene star, e.g.
> {S A? T}*
> for the equivalent:
> x: S if (A) { T goto x; }.
> and -- of course -- "goto" would be replaced by "=>" or "@" or the like.
> x: S if (A) { T @x; }.
>
> "if" we can probably let slide. It's short. In that respect, we're
> fortunate the English word for 'if" was not "descombamulate".


Hi,


        English is not my native language (portuguese is my mother tongue)
but I find it perfectly understandable. Most of keywords are very easy
to follow, with few, if any, cryptic meanings. Perhaps 'volatile',
'static' or other uncommon keywords are more difficult to grasp, but
AFAIK their meanings are very cryptic to most native english speakers
too. Syntax is never a problem, semantics is a more common source of
mistakes. All of my coworkers don't have problems reading


                while condition do
                        thing1
                        thing2
                end


but once in a while we fall in the block vs. statement problem of Java or C


                while (condition)
                        thing1;
                        thing2;


where thing2 doesn't belong to the block because we forgot the curly
braces and the compiler assumed one statement belonging to the while.


        Perl and APL use lots of symbols and are usually viewed as
'write-only' languages. Writing a language using kleene stars instead
of while statements could lead to unmaintainable programs, regardless
of the native language of the programmer. Also most of the time you
don't struggle with syntax or semantics of the keywords, instead you
deal with APIs, classes, functions, etc.. The famous Stack ADT uses
english words to describe itself and it's semantics:


                push S (pop S) = S


        Should we define the Stack as the '#@' symbol and the following
invariant?




                + S (- S) = S


or even


                ^ S (v S) = S
or


                v S (^ S) = S


        What should be the perfect non-language-specific symbol for push?
^ because it resembles the top of the stack? Or v, because it
resembles the direction up-down we use to put things in a stack? And
what should be the symbols for mouseClicked, foldr, mutex?
        We can view regular expressions syntax as a programming language, and
while it's concise and expressive enough for it's power most can't easily
verify it's correctness. Large regexes are difficult to understand, but as
they are usually small we are fond of using them. But a large (say a
compiler or a XML parser) program written with the '{S A? T}*' syntax is the
regular programmer's maintenance nightmare.




        Best regards,
        Daniel Yokomiso.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.