X-Newsreader: Geminisoft Pimmy 3.2 Eng - www.geminisoft.com
From: "John Colagioia" <JColagioia@csi.com>
Newsgroups: rec.arts.int-fiction
Subject: Re: what's wrong with some existing IF languages
Date: Tue, 16 Jul 2002 09:14:46 -0400
References: <Xns924696F5A38E7edmewsicSPAMGUARDcom@199.45.49.11> <agfei1$l7p10$1@ID-60390.news.dfncis.de> <Xns924755A2D30A1edmewsicSPAMGUARDcom@199.45.49.11> <iain-137BC7.21103410072002@socrates.zen.co.uk> <nJ1X8.28523$5f3.16894@nwrddc01.gnilink.net> <Xns92479B14FAF54OKB@12.252.202.62> <656X8.29751$5f3.22064@nwrddc01.gnilink.net> <agitkb$qnp@dispatch.concentric.net> <Hy7X8.18$7W6.3@nwrddc02.gnilink.net> <S%7X8.311714$R61.268018@rwcrnsc52.ops.asp.att.net> <He9X8.241$7W6.122@nwrddc02.gnilink.net> <eheX8.177$uw.207@rwcrnsc51.ops.asp.att.net> <3D2EC4E8.80902@csi.com> <ago3kv$qo9@dispatch.concentric.net> <3d302ede@excalibur.gbmtech.net> <Nf7Y8.350287$R61.330207@rwcrnsc52.ops.asp.att.net> <3d317469@excalibur.gbmtech.net> <7LvY8.541163$cQ3.49111@sccrnsc01> <3D330FCF.60006@csi.com> <ah04np$999@dispatch.concentric.net>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
X-Original-NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
Message-ID: <3d341c5d@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1026825309 ool-182f30fa.dyn.optonline.net (16 Jul 2002 09:15:09 -0400)
Organization: ProNet USA Inc.
Lines: 269
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!newsfeed.news2me.com!west.cox.net!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!uunet!lax.uu.net!sac.uu.net!sea.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106198

"Tzvetan Mikov" <ceco@jupiter.com> wrote:
>"John Colagioia" <JColagioia@csi.com> wrote in message
>news:3D330FCF.60006@csi.com...
>I snipped some parts of our discussion, because albeit interesting, it was
>drifting away from the main topic into a debate of not that important
>details (whether "limitation" is a negative word, for example :-).

Oh, be that way...big meanie...

[...]
>> I fail to see the connection between this and adding syntax.  In
>> fact, I'm tempted to say that I fail to see the (necessary)
>> connection between compile-time error checking and altering the
>> language at all.
>This is where I disagree. On a couple of points.
>- First of all, even if it was desirable (which I don't think it is - see my
>second point), it isn't theorectically possible to build a compiler that is
>smart enough - this is just one of the incarnations of the halting problem.

I think you're seeing past my intent to a much more
sophisticated plan that doesn't resemble mine, but I'll
play along...

>In the absence of a declaration of clear intent from the programmer, it
>isn't possible to determine which of several possibilities is the bug (if
>any). Look at this example:
>[ func a b;
>  if (a > 0)
>    b = b + 1;
>  else
>    b = 100;
>  return b;
>]
>How many parameters does this function have ? Is there only one parameter
>and did I forget to initialize "b" before the if, or are there two
>parameters ? Only I know the answer and the smartest compiler (or human)
>can't guess it.

The compiler will (should) assume that you're a competant
programmer.  Therefore, "a is used before initialization,
and is therefore a parameter; b is also used before
initialization, and is also a parameter."  Ignoring the
more static "else" clause, because it's counterpart isn't
as easily nailed down.

Therefore, they're both parameters, and a call with any
number other than two should be flagged.

If you add variable c between a and b, which is statically
initialized to some value, then we have an error on our
hands.

There's one glitch in this; Inform automatically
initializes all values to zero.  That's why I suggested
adding a semantic analyzer, external to the compiler.

>- The second point of my disagreement comes back to the initial topic of the
>discussion - readability. I looked through the Inform library code to find a
>common example to illustrate it. It didn't take me long. Look at function
>WriteListR in verblibm.h. It starts as this:
>[ WriteListR o depth stack_pointer  classes_p sizes_p i j k k2 l m n q senc
>mr;

I do want to note that I'm disagreeing, to a certain
extent, not just with you, but with Graham Nelson, I
suspect.  Note the two spaces between stack_pointer
and classes_p.  That's a consistent notation used
throughout Mr. Nelson's code to separate parameters
from local variables.

>  if (depth>0 && o==child(parent(o)))
>  {   SortOutList(o); o=child(parent(o)); }
>....
>In the absence of documentation or comments,

...which is a cardinal sin, no matter what the source
code *could* tell you...

And, again, note that there is subtle documentation,
albeit hidden, in the parameter list.

>I can't tell which one of these
>locals are supposed to be parameters. So, I must start looking for clues ...

Except...they're not really "clues."  They're "answers."

>A dozen lines later I find an unconditional assignment to "classes_p", which
>leads me to believe that it is in fact a local. I also find an assignment to
>"stack pointer", but it is obvious that its value has been used before.

Here's what I get:
depth:  Used before initialized.
o:  Used before initialized.
lots of code that only uses o.
stack_pointer:  Used before initialized.
classes_p:  Assigned.
sizes_p:  Assigned.
i, j, k:  Assigned.
and so on.

If lint (and lint-like tools for other languages) can tell
me that something is used before initialization, then a
semantic checker for Inform can certainly do the same
thing, and "propagate" that information when examining the
calls to the functions.

>This
>already is a non-trivial problem of data-dependancy analysis and it is
>unsolvable in the general case, but in this case it is not that hard to
>deduct that that the last parameter is "stack_pointer".

And that's all I'm looking for, honestly.

>Now, I also have to search through all the rest of the source for
>invocations of WriteListR in order to determine that the third parameter
>(stack_pointer) is not always required and can assume a default value of 0.

I'd argue that this should be classified as an error, or
at least an "abuse" of existing Inform rules.

Yes.  I've said it.  I'd add semantic rules that flag
Inform library code as erroneous.

Why?  It relies on the default preinitialization to save
appending a critical parameter (though, coincidentally,
the preinitialization value) to the parameter list.  If
a later version of the Z-Machine (or Inform compiler)
chooses to not preinitialize to zero, this code will
fail to work as expected.

>Finally, I am done. If anything, this is the exact oposite of "readability"
>for me.

It's unreadable code.  You can write that in any
language, with whatever semantic sugar is supplied to
you.

Trust me on this one.  I just graded a heap of papers
that prove the point...

>If the function was declared in the way I propose, it would look like:
>[ WriteListR (o depth) stack_pointer . classes_p sizes_p i j k k2 l m n q
>senc mr;
>Ulgy or not, I need just a quick glance to figure out all the information I
>need: there are three parameters - o, depth,stack_pointer. stack_pointer
>assumes a default value of 0 when omitted. I now know how to invoke the
>function and when I start examining its code in order to understand what it
>does I already have a bunch of helpful data.

Much better, though, would be:

[ WriteListR
 o depth                                     ! Req'd params
 stack_pointer                               ! Opt params
        ! Note that I'd still classify the above as
        ! an error, based on usage.
 classes_p sizes_p i j k k2 l m n q senc mr; ! Locals

>> Your ideas are fairly obviously inspired by C or are mutually
>> inspired by the same sources.  Not that this is a bad thing, per se,
>> because C has pretty much infiltrated the collective consciousness of
>> the software industry (and, by "C," I mean pretty much everything
>> from BCPL to Java and C#, since they all share the same basic
>> semantic structure).  But there's no reason to try to shove them into
>> another language or claim their readability based on precedent.
>Perhaps when you say "C" you mean all Algol-like languages.

Perhaps.  That's what the textbooks probably call them.
I tend to dislike the label, because I usually will put
the Algols in their own category, seeing as how ALGOL
60 greatly resembles non-Algoloids like FORTRAN in many
ways, and ALGOL 68 is so rife with features and
concepts that few languages, if any, resemble it.

When I refer to C-like languages, I refer to languages
that have a simple block structure, and is mostly tuned
to be most effective on "normal" (read "70s-early-90s
architecture") machines.

>Inform is
>obviously one of them, so it is no surprise that it should share lots of
>their qualities.

Except, again, those qualities are on what I'd call
the superficial end of the language--the part that you
show the kids so they don't run away screaming on the
first day...

>> > (Not that it matters, but my opinion of C is not quite as flattering as
>you
>> > might think, especially since I am lookng at it from the viewpoint of a
>> > compiler writer)
>> Heh.  What do you mean?  C is a compiler-writer's *dream*!  Static
>> scoping, lot's of "implementation's calls" in the standard, and no
>> intrinsic I/O.  Hell, if you're targetting a PDP machine, you're just
>> about done, right there...
>Quite the contrary. C is a very challenging target for optimization on
>modern architectures.

Careful, here.  There's a big difference between "compiling"
and "optimizing."  The fact that the same people and
programs tend to do it obscures the fact, but *compiling*
C is easy, because it was designed to be easy to parse and
generate simple code.

It's awful to pipeline and stuff, true, but that has
little to do with the "proper" compiler.

>It also has some annoying undefined cases in code
>generation. During the years in which it has evolved, it has ceased to be a
>kind of high-level assembler and has become a sometimes cumbersome language
>with lots of peculiarites of its own.

I don't know that I agree.  It seems more like C has
been pretty static, over the years, and it's just that
the architecture people have finally realized that the
PDP isn't necessarily the "best idea, ever."

I mean, ignore the library, and ignore stupid changes
like function pointer syntax and prototypes.  What in
C has actually changed since the earliest days?
Nothing, unless you use your C++ compiler to compile
C code, in which case you're in for a few annoying
surprises...

>Many people think, and I agree with
>them, that C is a dead end in language development.

You might want to tell that to the C++, Java, and C#
people.  I wish *somebody* would...

>> > The biggest proof of that is the effort that was required on my
>> > part in order to start reading and understanding Inform sources - I just
>had
>> > to read the manual. It was much harder with Prolog :-)
[...]
>Hm. Programming in Prolog requires a different mindset and one that I never
>quite managed to master (nor did I have much incentive to, anyway). But it
>probably depends on the persons background.

Maybe.  I've been referred to by more than one person
over the years as "insane"...

>> Inform, I was able to "code in" after skimming the manual, but I
>> couldn't "write a program" (idea to design to code) in Inform for
>> quite a few years.  Time will only tell if I can do that *now*, to
>> be honest...
>Are you talking about the Inform language or the library ? There is no doubt
>that it would take time and effort to understand and start effectively using
>the library, but the language itself is simple, I think.

Well, again, the basic syntax (the stuff you'd be
exposed to initially) is really simple, and very
C-like.  However, when you start having to build
more sophisticated gadgets, you end up with things
like this:

 objectloop (d in Compass)
	if (p.(d.door_dir) == self)
		return (p.(d.door_dir));

(note that I'm leveraging the library, but not
"programming in the library," since those properties
could be anything)

Toss in a Routine that takes Routines as parameters,
and maybe a Routine that returns a Routine, and, to
the extent of how they work semantically, you're
really no longer in C-land.
