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 08:53: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> <3d302ede@excalibur.gbmtech.net> <Nf7Y8.350287$R61.330207@rwcrnsc52.ops.asp.att.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: <3d317469@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1026651241 ool-182f30fa.dyn.optonline.net (14 Jul 2002 08:54:01 -0400)
Organization: ProNet USA Inc.
Lines: 177
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!jfk3-feed1.news.algx.net!allegiance!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106148

"Tzvetan Mikov" <ceco@jupiter.com> wrote:
>"John Colagioia" <JColagioia@csi.com> wrote in message
>news:3d302ede@excalibur.gbmtech.net...
>> > 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.
>Sorry, but you are wrong.

You obviously haven't done much assembly-level programming.

>Most CPUs have an uniform way of accessing
>parameters and locals, but it is clear which one is which (to begin with,
>parameters are pushed in the stack before the return address, the function
>has to allocate space for locals itself, etc).

No.  Tradition on certain architectures has developed
among programmers, so that code can more easily be used.
The BP/SP on Intel chips is a convenience for finding
the return address, but even it makes no claims about
the memory above and below either pointer.

If you know of a chip which does make an actual
distinction, I'd genuinely like to hear about it; the
propagation of RISC chips throughout the industry
makes that unfortunately pretty unlikely.

>> >- 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.
>It may be possible (if one jumps through hoops),

Jump through hoops!?  It'd be, at most, a hundred-line or
so change to the compiler:  On a Routine call, allocate
some Z-memory, load the parameters into it, and put the
pointer onto the stack; in the Routine, change the access
to use that pointer instead of the stack pointer.

Side note:  If the allocated memory is structured like an
Object, you now have convenient dynamic allocation of
Objects, *and* Routines gain a certain first-classness,
in a roundabout way.  Not useful, but really nifty.

>but it isn't being done in
>Inform, which was my point.

Arguably, this was a conscious decision to improve
readability by stonewalling programmers who need a Routine
with twenty parameters and fifty local variables; Such
routines are almost certainly overcomplicated, and need
to be decomposed.

>The limitation in the programming language is a
>direct result of the limitation in the ZMachine.

Where, exactly, is the limitation?  I see some
inconveniences for people programming fringe cases, but
nothing like a limitation.  Unless you definition of
"limitation" is "it's easier in C."  I doubt that, though.

>> >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.
>I really don't understand how
>  [ func a b c;
>is more readable than, for example
>  func ( a = 0, b = 0 ) { var c;
>It is not a matter of syntax (I deliberately made this example language
>neutral). Choose ant notation you like, but in the first case the
>information is simply not there, thus it cannot be read or be "readable". Or
>is there any other definition of readability ? :-)

It's more syntax to slog through, none of which provides
any semantic information.  That is, it's less readable in
the same way that COBOL is less readable.

>> >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.
>This is very subjective.

To an extent, but to handwave it as such is to simply say
that you don't care.

>While I agree that the notation with the "." really
>sucks (I couldn't think of anything better for the example), I believe that
>most people find the brackets notation quite good. Probably that's why it is
>used in most programming languages in existance, not to mention algebra ...
>:-)

Chicken and egg.  I'd argue that the notation is "popular,"
not because it's better, but because programmers are
conditioned to accept it.

>> >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.
>To tell you the truth, we have a too big difference of opinion for this
>discussion to come to a constructive end.

If you want to take your ball and go home, that's
certainly your prerogative, but I think you're
overlooking critical issues, thinking that C (and
its derivatives) are some pinnacle of evolution.

>You and the original poster seem
>to support the point that programming in Inform is unlike programming in
>other languages - it has a different requirements for readability, style,
>notation, etc.

The former is only as true as it is for the difference
between, say, Java and (to use a recent example) Prolog;
the application domains are usually dissimilar, and,
while you can use the same approaches in both ("You can
write your crappy FORTRAN code in any language," as one
of my old professors used to say), each has more
"native" ways of solving most problems.

The last half of that--readability requirements--should
obviously be true.  A different sort of person will read
Inform code than will read COBOL code, and the actual
application will (should) have a different goal and a
different sort of design.  Therefore, the language should
cause the programmer to emphasize (read as "cause to be
readable") different aspects.

Does that mean that software engineering techniques
shouldn't be used?  No.  Again, I'd love to see someone
put together a lint-like tool (and I'd be happy to help
out; I just don't have the time to commit to spearhead
such a project at the moment) to do a bit of checking
long before the compiler ever sees my code.

However, what works for C works for C because of the
PDP-like architecture that C assumes (and simulates),
and the common sorts of programs that C programmers
write.  Inform has different assumptions, and Inform
programmers tend to write different sorts of things.
To intelligently improve readability (and, honestly,
have you seen much *unreadable* Inform code?), it'd
be a very good idea to observe some Inform
programmers in action, rather than trying to apply
some other language's standards.

>If we start with that then all bets are off and I feel that I
>am not qualified to argue convincingly about it, since I haven't ever
>written a real game in Inform.

I'd heavily suggest checking out a few languages that
don't follow the C vein.  It'll give you a better idea
of what I'm talking about (language idioms and changes
in emphasis), and probably give you some good ideas to
bring back to your "normal" programming.

Tell me if that sounds at all condescending; it isn't
meant to be, and I'd like the opportunity to apologize
and clarify, if necessary.
