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: Sun, 14 Jul 2002 09:08:08 -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> <ZE8Y8.2379$kP6.1992@nwrddc04.gnilink.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: <3d3177cb$1@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1026652107 ool-182f30fa.dyn.optonline.net (14 Jul 2002 09:08:27 -0400)
Organization: ProNet USA Inc.
Lines: 56
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!priapus.visi.com!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106150

lraszewski@loyola.edu (L. Ross Raszewski) wrote:
[...]
>You claim that it would be useful for you to know that this is a
>function taking two parameters -- but that's a *radical change to how
>inform works.

Interestingly, though, it's not a radical change to how
Inform is *used*, which is why I suggested putting the
check into a pre-processor.

Local variables come in three varieties, in Inform:
- Uninitialized:  These better come first, and they
  better have values assigned to them in the Routine's
  call.
- Conditionally Initialized:  When the first reference
  to a local is a check against zero, it's an optional
  parameter.
- Unconditionally Initialized:  These should never be
  passed in by the calling routine, and should be
  declared last.

Yes, there "can't" be uninitialized variables, because
the Inform runtime (or is it the Z-Machine?) sets them
all to zero on invocation.  Preinitialized variables
are evil, though...

Similarly, it's be fairly easy to check the return
statements of a Routine to make sure they're
consistent (value, no value, or no explicit value),
and that'd probably have saved me a few mistakes I
made just last week.

>Because it's *not* a "function taking two
>parameters". It's a function.

I'd argue that it's a "routine," rather than a
function.  "Function" carries an assortment of
connotations, which I think is what brought this
topic to light in the first place.  To wit, C has
"functions;" if Inform has "functions," they should
work like C's.

[...]
>You could make similar readability claims -- why not insist that at
>the call-site, you say foo(a=1, b=2);, becauase it makes it more
>readably clear that a is initialized to 1 and b to 2 (actually,
>there's a language that does this... some ada variant I think)

I think it's proper Ada, optionally.  One of the
Modulas may have picked it up, as well, but I
don't follow the Modula scene.

Oh, and VB.  I think you can have keyword parameters
there, too.

[...]
