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: Thu, 18 Jul 2002 18:19:15 -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> <3d356991@excalibur.gbmtech.net> <3d36bb67.23942883@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: <3d373ef9@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1027030777 ool-182f30fa.dyn.optonline.net (18 Jul 2002 18:19:37 -0400)
Organization: ProNet USA Inc.
Lines: 326
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106341

info@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>"John Colagioia" <JColagioia@csi.com> wrote:
[...]
>> 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.
>And why shouldn't you? If that's what it takes to get the job done,
>that's what the language lets you do. No unnecessary limits. I fail to
>see why this is a bad point in a programming language.

The original poster said that the limited number of
parameters (and locals) was one of the things that was
bad for readability; I claim (if not outright state)
that having more than that severely *damages*
readability, rather than helping it.

Also, while I don't actually think it's bad, per se,
to assume that it's *good* is just as unwarranted, I
think.

[...]
>> 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.
>I doubt it, because it is geared towards an entirely different problem
>space. But at the same time, I think neither of us can prove our point;
>the experiment simply hasn't been made.

True, but, while I haven't taken the time yet to look at it,
there *is* a full operating system written in Inform.  I
don't know if the author kept a design document or "pain and
suffering diary" for the project, though.

[...]
>> 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...
>Well, yes, and with some reason, but I think the designers of Lisp were
>more interested in keeping the language pure than in making it easier to
>use for non-Lisp programmers.

Not to drift too far off-topic, but McCarthy's stated
design goal was (I'm only paraphrasing) to write an
IBM assembler that integrated some features of the
lambda calculus.

Later versions of LISP might have had the goal you
suggest, but I don't have any design information on
them.

>In effect, they'd probably say that non-
>parenthesized math expressions would _be_ additional verbiage, because
>it would be an exception to the rule that "everything is a function
>call" - thus creating the need to remember an extra syntax rule. IOW,
>Lisp is all about syntactical simplicity taking precedence over syntax
>exceptions for everything "because it's shorter".

True; I wonder why the parentheses aren't entirely
optional, though, since, almost by definition, there
cannot be any ambiguity.

>> >> 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.
>They can if used consistently.

A luxury which, alas, is not remotely always possible
if you're not the originator of the project.

I'm picking on prototypes specifically because I've
been on more than one project with library files best
described as "what source code?"

>> >- 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.
>Sure, but that's not a fault of prototypes. Properly used, they solve
>the problem, and solve it much more completely than mere in-file
>lookahead can.

See, here's the crux of the problem I have:  If I have
access to the source code (to include prototypes), then
so does the compiler.  Ergo, we can have multi-file
lookahead--an entire "symbol table phase."

"No," I hear you cry, "that'd be inefficient."  Tough.
I bought a computer to speed my work, and not to give
me tedious work it could have done better...

[...]
>> If the function is available, though, it should be
>> used in favor of the prototype.
>If a function is available and it doesn't match a given prototype, that
>is an error.

And this helps...who?

Basically, that error message tells me that I didn't
jump through the hoop properly.  Again, I'm not the
one who's supposed to be doing the jumping, in the
user-computer relationship.

>I think your problem is not so much with prototypes themselves, as with
>the fact that pre-ISO C did _not_ have prototypes, and that this
>inheritance means that a non-prototyped function is assumed to have a
>default signature.

Close.  My problem is with the very-real-world effects
that this issue has created.

I actually support the use of prototypes *in C*, because
a goal of C is to have a simple (and, presumably, thus
portable) compiler.  I don't think it's the "right"
language-level solution, by any means, though.

>Prototypes, when properly used, solve the problem
>fully, in fact better than lookahead; it is when you do _not_ use
>prototypes consistently that this K&R heritage starts causing problems.

If you'd like to reverse engineer some library files and
rewrite them in proper C, I don't think the money's in the
budget to *pay* you, but I know one or two people still
working there that'd be grateful...

...provided you don't introduce any bugs, of course...

[...]
>> Sigh.  I'm not suggesting that the precompiler
>> generate documentation, people!  I'm suggesting
>> that the utility flag "used before initialized"
>> cases,
>You cannot in all cases even detect this "used before initialised"
>situation correctly.

The only case I can think of where this might be true
is a switch statement inside a loop, or something,
where the programmer honestly deserves what he gets
for writing such contrived code...

>> 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...
>Lint heavily requires human judgement to be used correctly; relying on
>lint to get everything right is as much a mistake as not using lint or
>something similar at all.

Lint indicates potential errors.  Isn't that what
we're working at, here?

[...]
>> >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.
>Sure; but if you think that C-like languages have infiltrated the
>collective consciousness of the industry, you forget programs written in
>languages like the above - which is the majority of business software.

COBOL hasn't made a major dent in the collective
consciousness.  It isn't taught at many schools, there
are far fewer books on it than for other languages, and
most programmers won't use it, even when not given a
choice.

It's out there, and I've written more than my share of
COBOL code, but it's not a "canonical work," so to
speak...

>C
>is only predominant in systems and general programming, because that's
>what it's good at. It isn't predominant in administrative software,
>because other languages are better at that.

Arguably, COBOL isn't one of them...

[...]
>> >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.
>*shrug* Then you are in disagreement with the ISO C Committee. That's
>your problem, not mine or C's.

I disagree with the misleading vocabulary the ISO C
Committee has used to make the language look more
"sophisticated" (whatever *that* might mean).

I would also disagree in the same way if they called
the if statement a "one-time, optional loop."  It's
an incorrect use of the term.

>> Language components can't be eliminated and
>> replaced by a typical programmer.
>Neither can the Standard library. Redefining malloc() invokes undefined
>behaviour. That Unixoid implementations interpret this instance of
>undefined behaviour as "we'll allow it" doesn't make this any more
>officially sanctioned.

Redirecting malloc() with that silly macro thing isn't
what I'm talking about.  "malloc" isn't a C keyword,
unless they hid that in the new standard (in which case,
C has far more keywords than PL/I, which I doubt), which
means I can create anything I like and call it malloc,
as long as I don't introduce the "standard" malloc into
the namespace.

[...]
>> >  [ 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.
>Not if it is made enforcable. If this syntax is adopted, it should imply
>that a function _cannot_ be called with less than the required or more
>than the required + optional parameters. Merely using syntax as an
>alternative to comments isn't much good, of course not. Using syntax to
>enforce consistency _is_ good, though.

Having programmed in FORTRAN, Python, Ruby, and PERL,
each of which has its own bits that *must* be done,
just 'cuz, I'm going to disagree with you, here.
Consistency isn't so much a good thing as it sounds
when it interferes with the actual process of coding.

>> >> 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.
>That is, at least, something. It can prevent the careless programmer
>from leaving out a required parameter, or passing more than the expected
>number.

Does anyone ever do this?  I've been programming and
working with programmers for a pretty long time, and
this thread is the first I've heard of such a problem.

Sorry, that's not quite accurate.  I will occasionally
forget the file handle in fprintf().  But, guess what?
It's a case where the compiler doesn't notice (not
*that* problem, at least), and I usually find and fix
the problem before the code gets to the compiler.

>>  It tells me nothing about what the parameters *mean*
>Well, duh. Nothing can, not even comments - after all, we all know that
>comments are often out of date, so if you want to know what the
>parameters _really_ mean, you need to read the code.

If the comments are wrong, then the code is wrong.  We
can't enforce that, but that's just tough luck.

I would much rather spend my time teaching programmers
to document their code than make them jump through
stupid hoops to make the compiler's job easier.

>> 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.
>I suggest you take a look at Kvikkalkul - it would be eminently to your
>liking. It makes syntax impossible.

Kvikkalkul was cute, but I wasn't fond of the no-good-
reason rational numbers, which made it hard to program
simple programs in a "natural" (to the language) way,
since most simple programs I think of involve
integers...

I started using ASCII art for comments, in case you're
curious...

>> >> 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,
>It can't portably be replaced,

The name malloc can be used elsewhere, and a new memory
allocator can be written.  No, not portably, but neither
is malloc() portable in that way.

>and it is part of the language. You may
>disagree, but then you're disagreeing with the C Standard.

I'm disagreeing with either the language of the C Standard,
or perhaps the scope of their definition of "language,"
which is inconsistent with the definition used by every
other language designer.

Even the otherwise-overzealous Java people know the
difference between the language and the library.

[...]
>> >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...
>Yes, but a freestanding implementation isn't typically strong enough to
>program IF in. No <stdio.h>, you see, so no reliable input or output.
>And no, this does not contradict my earlier statement about the library
><g>.

Why?  Again, by any practical definition of "language,"
the ability to remove a feature (and still have the same
language) makes that feature not part of the language.

That ISO has decided to redefine the term "language" is
not grounds to make C a special case for analysis, I
don't think.
