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: Sat, 13 Jul 2002 09:44:41 -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>
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: <3d302ede@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1026567902 ool-182f30fa.dyn.optonline.net (13 Jul 2002 09:45:02 -0400)
Organization: ProNet USA Inc.
Lines: 106
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!jfk3-feed1.news.algx.net!dfw3-feed1.news.algx.net!allegiance!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!uunet!lax.uu.net!dfw.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106117

"Tzvetan Mikov" <ceco@jupiter.com> wrote:
>"John Colagioia" <JColagioia@csi.com> wrote in message
>news:3D2EC4E8.80902@csi.com...
>> In terms of readability, this means that "function calls" only carry
>> the "parameters" they need,
[...]
>There are several aspects of this issue:
>- The design of the ZMachine: it allows only 15 locals

Untrue.  It makes no more than 15 locals *convenient*.  A
willing compiler-writer could push pointers to activation
records onto the stack, if there were sufficient
motivation to do so.

> and doesn't
>differentiate between parameters and local variables

Nor do most machines, when the system stack is used for
such things.  Certainly, neither Intel nor Motorola chips
know the difference.

>- Tradition: AFAIK, the Inform language evolved naturally from a ZMachine
>assembler. So, it kept its major conventions - didn't add a distinction
>between parameters and locals, where it didn't exist. Nor does it support
>more then 15 locals (it would be very hard to do in the ZMachine, anyway)

See above.  It wouldn't be all that hard.  Add some code
to pack the data into arrays or an Object, and pass the
relevant pointer or handle.

>- Language design
>Realizing the first two, let's concentrate on the last one, which is more or
>less independant of them.

This should be true, yes.

>You are saying that the advantage of the current
>design is that unused parameters can be omitted and assume default values.

That's about the size of it.  I'm sure I could think of
other uses, if pressed, but they'd be contrived.

>Undoubtedly this is convenient, but it can be achieved with stricter rules,
>like for example in C++. There can be required parameters and optional ones.
>It would allow to catch errors at compile time, without sacrificing any
>flexibility.

It is, however, ugly and less readable, in my opinion.

>Let's, for the sake of this discussion, invent an extension of Inform's
>syntax.
[...]
>[ func2 (a b) c d . e ;
>  e = a + b + c + d;
>  return e;
>]
[...]
>However it is invalid to use:
>  func2( 1 ) or func2( 1, 2, 3, 4, 5 ).

I have two problems with this.  First, it's ugly in the
extreme; not necessarily because of the symbology,
either.  The other...well, I'll wait for that.

>Finally, for compatibility's sake, since all these enhancements are
>optional, the existing syntax is still valid:

This sounds like a job for a pre-processor, since it
can take that annotation and stop the compilation if
there's any deviance.

And, now that I give it some thought, a lint-like pre-
processor would probably be quite nice for Inform.  And
the good news is that it could do checking like this
without touching the syntax:

1)  If a local is unconditionally assigned a value in
    the Routine, then it should never be passed as a
    parameter.
2)  If the local is never initialized, then it should
    be passed as a parameter; auto-initialization (a
    very bad thing, which I'm surprised nobody has
    argued) be damned.  OK, *that* was over the top...

Notice that this changes neither the syntax nor the
semantics of Inform.  It just applies some heuristics
to see that the code is "probably" right.  Any
programmer ignoring such warnings deserves what he
gets, just like in C.

Arguably, if the programmer is willing to do a tiny
bit of the work (say, by using something like
Hungarian Notation for names, which is no more work
than your new function notation, and is far more
general), a lot of the strong-typing that some
people want could be done, as well, and provides a
handy way to bypass it (using non-Hungarian variable
names) on those occasions where strong typing would
be inconvenient.

[...]
>So, what do you think ? :-)

I think it's a nearly reasonable idea, but probably
doesn't belong in the Inform language or mainstream
compiler, itself.
