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:47:39 -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> <ah4f98$eg4@dispatch.concentric.net> <3d36a85c@excalibur.gbmtech.net> <3d36c532.26450945@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: <3d3745a0$1@excalibur.gbmtech.net>
X-Trace: excalibur.gbmtech.net 1027032480 ool-182f30fa.dyn.optonline.net (18 Jul 2002 18:48:00 -0400)
Organization: ProNet USA Inc.
Lines: 42
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:106345

info@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>"John Colagioia" <JColagioia@csi.com> wrote:
>> The header files are irrelevant; they exist (currently) for
>> the purpose of delivering prototypes.  The I/O calls (and
>> every other library facet) are accessed differently than
>> facets of the language.  Calling printf() is not the same,
>> syntactically or semantically, as "calling" if().
>Strange thing is, calling writeln() is not the same, syntactically or
>semantically, as "calling" if ... then, but I've never heard anybody say
>that the library is not part of Pascal.

The difference is that you can't have a Pascal installation
or a Pascal program that doesn't understand writeln().  You
*can* have a compliant ISO C program which can't be made to
call printf(), however.  The printf() function is part of
the runtime API commonly associated with C, rather than a
part of the language, which is how Pascal defines its I/O.

Note that this is not a judgement call in any way--inbuilt,
langauge-level I/O is rarely a good thing in a language
intended for compiling.  Rather, it's a statement of
definition, which has gotten clouded by people (ISO) who
apparently have some agenda that I don't understand.

>> Plus, given the philosophy behind C, you can (should be
>> able to) create an application which can *never* call
>> printf() (even by walking through memory can calling the
>> proper function pointer), but has its own I/O.
>It can, but it cannot be called printf().

Where is "printf" defined as a reserved word?

>>  That is,
>> any standard library feature "ships with" the language,
>> but, by virtue of being replaceable, is not "part of"
>> the language.
>I can write my own integer division function. Does this mean that / is
>not part of the language, in either C or Pascal?

No, because you can't remove the inbuilt integer division,
you can only choose to not use it.  I can, however, have a
legal C program which knows nothing about printf().
