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: Wed, 17 Jul 2002 08:56:29 -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> <3d3437cd.20872218@news.tiscali.nl>
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: <3d356991@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1026910609 ool-182f30fa.dyn.optonline.net (17 Jul 2002 08:56:49 -0400)
Organization: ProNet USA Inc.
Lines: 244
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!west.cox.net!cox.net!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106254

info@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>John Colagioia <JColagioia@csi.com> wrote:
[...]
>> I don't know that they're unrelated.  The usual research says that
>> humans can only keep track of about 3-7 things at a time.
>This is, btw, a broken assumption for function parameters, because this
>research is about _unrelated_ things. Function parameters often come in
>pairs or sets, making it easier to remember that the 8 parameters to
>function foo are four sets of coordinate pairs.

That's not nearly as common in IF as it is in more
typical programming, as far as I can tell.  Inform
parameter lists tend to look like the shopping list
for the trip to Price Club ("Onions, a birthday
cake, a bicycle wheel, and a water cooler...").  Or
maybe an inventory list.

Hmmm...Could our playing experience be guiding our
programming...?  Never mind, I'm digressing again...

>> Contrast this with C or (shudder) PERL, where "if you can imagine it,
>> you can program it," no matter how bad an idea it is.
>That's because C at least, and Perl up to a point, were designed to be
>languages you _can_ program everything in - _everything_. If you want to
>write code that buggers the BIOS, well, you can - because you might be
>writing a BIOS flashing tool.

That's not what I meant.  I wasn't referring to
product, I was referring to low-level, fiddly "I
think I should have a function with seventy-two
arguments, none of which are ever used" kind of
things.

That most C runtimes happen to have full access
to the underlying architecture is extremely handy,
but not in any way that another language couldn't
be, given the same runtime access.

>Inform assumes you're trying to write IF, and is geared towards that;
>this comes with both special capabilities and with limitations.

I still don't see many of these so-called limits,
other than in the rhetorical sense.  And the
general paradigmal sense ("you need an algorithm
operating on data to accomplish a goal").

>C, and
>Perl for that matter, assume nothing about what you're trying to do, so
>there are few limits.
>Naturally, C is better for writing OS kernels than Inform. Equally
>naturally, Inform is better for writing IF.

I might disagree on the former point, actually.
C, as a language, isn't all that critical.  C
shines more in the fact that most implementations
directly use the native, underlying structure for
representation.

If I coded up an Inform compiler to directly
generate 80x86 code, and use all the native Intel
structures, Inform would be a pretty darn good
language to do kernel work in, too, I'd imagine.

Depending on what you need in your kernel.

[...]
>> what I dislike is additional verbiage that either doesn't solve a
>> problem (i.e., LISP's desire to have even basic math subexpressions
>> parenthesized, given that a benefit of prefix notation is that you
>> don't need to explicitly group things)
>Well, that's a result of the basic premises of Lisp, really. Making
>basic math an exception might actually make the language _more_
>confusing.

I'm not entirely sure I see it as an exception to
LISP's semantics.  It's obviously an exception to
the syntax, but that's because the syntax is what
I'm complaining about...

>> or solves a problem in a
>> somewhat backwards way (i.e., prototypes in C--the *right* solution
>> is to build a compiler that's smart enough to look ahead;
>Sorry, no can do. Lookahead works within one source file, but it cannot
>possibly work across several source files

Nor can prototypes.

>- keep in mind that with C it
>is possible to compile a whole program today, and next year come back
>and change and recompile only one of the 354 source files making up the
>project. At that moment, you need those prototypes to make sure you call
>the function you compiled last year correctly.

Except, of course (which nobody ever mentions) if the
older source is *lacking* prototypes; then the offical
"really bad things" start to happen.

>Ditto, in spades, for
>calling library files, which might not even be written in C.

In which case (and the previous case), the prototype
*stands in* for the otherwise unavailable function.
If the function is available, though, it should be
used in favor of the prototype.  I, for one, am
willing to wait an extra minute or two for the
compilation.

>> The "right" solution to the problem I believe you're pointing out
>> (compile-time checking of parameter lists) is to semantically analyze
>> the existing code, rather than adding unnecessary syntax to carry the
>> same information.
>Doesn't work. Semantical code analysis _is_ sooner or later going to run
>into the halting problem. You can do whatever you want to make it later
>rather than sooner, but at some point the computer still won't be able
>to understand your code. That's why _I_ write code, and the computer
>compiles it.

Sigh.  I'm not suggesting that the precompiler
generate documentation, people!  I'm suggesting
that the utility flag "used before initialized"
cases, and *assume* that these are parameters.

The lint utility already knows how to do the first
part.  By pointing into that list, you now have a
fairly probable prototype (if you don't, it's a
flaggable error!).  Check the prototype against
the calls to the routine--something else that any
compiler-writer knows how to do.

If you don't believe that this heuristic, semantic
error-checking is possible, I heavily suggest you
take a look at "lint," available on fine (and not-
so-fine) UNIX installations everywhere...

>> > Please, don't put words in my mouth.  I haven't in a single place in my posts
>> > in this thread expressed an opinion about "C", let alone compare it with
>> > Inform (I used C++ once as an example of default parameters, because that is
>> > the most popular one). It is you, in fact, who is constantly doing that.
>> 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).
>You seem to overlook all kinds of Basics (VB!), Pascal (including
>Delphi), Cobol (yes, it still exists), Python, Icon, Perl (not as C-like
>as a first glance would seem to show), DBase-alikes and even Fortran.
>All those are imperative, but not really C-like.

Uhm...That would be why I said "C-like," and not
"ALGOL-like" or "imperative."  They have features and
concepts that nobody has related in this discussion,
and (I'm guessing) probably won't.

>>  But there's no reason to try to shove them into
>> another language or claim their readability based on precedent.
>I'd say that C's readability is _entirely_ based on precedent; it is not
>inherently more legible than, say, Fortran, but lots of experience with
>C-like languages has made it so.

I'd argue this, but I really don't care to get into
a "this language is better" argument, considering
that I wouldn't be able to choose a side...

>> > (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*!
>Not nearly as much so as Fortran, though.

Depends on the version of FORTRAN and the target
architecture.  Early FORTRAN is geared more toward
the (kinda weird, by today's standards) IBM chips,
whereas later FORTRAN seems geared toward massively
parallel systems, for the most part.

>>  Static scoping, lot's of "implementation's calls" in the standard, and no
>> intrinsic I/O.
>*Ahem* #include <stdio.h>?
>Yes, the Standard library _is_ part of the Standard ISO C language.
>Don't be fooled by gregarious Unix implementations.

I consider this a false statement.  The standard
library is part of the standard that also defines
the standard C language.  The library, by definition
of being a library, is not part of the language.

Language components can't be eliminated and
replaced by a typical programmer.

>> > and this prevents you from looking at Inform with an open
>> > mind. Inform is not the pinnacle of evolution either. As anything else, it
>> > can be improved.
>> I haven't said otherwise.  What I *have* said is that I don't believe
>> your particular suggestion was worth integrating into the mainline
>> language, since it (a) can't have a clean syntax,
>Doesn't. It can, though:
>  [ funcname - par1 par2 - opt1 opt2 - local1 local2 local3
>is much cleaner than the original suggestion. Feel free to replace the
>-s by your favourite punctuation mark.

No, that doesn't make *anything* more readable.  It
just intersperses more syntax that should've been
handled by documentation and comments.

>> and (b) adds syntax
>> which doesn't add any semantic information
>Oh, but it does. Not to the compiler, but to the programmer, which is
>the most important goal of syntax.

That doesn't tell me anything of use except the
range of parameters acceptable.  It tells me nothing
about what the parameters *mean* (especially the
all-important optional parameters), and absolutely
nothing about which parameter goes where.

Therefore, I revise my comment.  It add something to
the semantic information, but it's deceptively
useless information.  And that's far more dangerous
than not having it, at all.

>> > Aren't you exagerating a little? :-) I mean, Inform is different, but it
>> > isn't that different. By no means it is as different as ML and Prolog are
>> > from Algol, for example. It definitely doesn't require a drastically new way
>> > of thinking or programming.
>> The syntax and low-level semantics are similar.  It doesn't take too
>> much to, for example, rewrite a C (or Algol, or Java) program in
>> Inform (NB: Only in theory; I haven't bothered to try this).
>With C, I suppose malloc() isn't all that easy to emulate.

Again, since malloc() can be replaced, I can't
consider it part of the language, any more than
the parser is part of Inform.

Second, dynamic memory has been done.  Check the
archive.  I think it's dynmem.h, but don't quote
me...

>A
>freestanding implementation would be easier, but those are barely useful
>except for embedded devices.

Heh.  Like, say, a tiny virtual machine programmed
to play games...
