A C Adventure: your comments are welcome

[spinoza1111]

spinoza1111said:




I see nothing in that quote to suggest that Schildt has written a
compiler, so its provenance is irrelevant. Furthermore, I don't see
how my *asking* for evidence to support the claim (that Schildt has
written a compiler) constitutes posting a lie about anyone.

In the snide style in which you delivered it was as always your
stinking, rotten, filthy attempt to destroy people who are smarter and
more productive than you.

Furthermore, the wikipedia information (which can be checked by
looking up and/or ordering the books on Amazon or a library) confirms
that Schildt:

1. Wrote a lengthy "recursive descent parser". I really hope that you
know that is.

2. Wrote an interpreter based on the output of the parser.

This, in fact, constitutes a compiler. Many compilers have no code
generation, only interpretation, commencing with the Purdue University
Fast Fortran Translator and including a 1401 compiler I debugged in
machine language. Certain languages can ONLY be interpreted, and have
compilers.

Therefore, you have lied about Schildt with malicious intent, and this
constitutes civil, and possibly criminal, libel under British law.

Have you, scumbag, ever written a parser, using recursive descent or
any other technique? Your Web site says you have worked for what is
probably a rather dreary series of banks and insurance companies, so I
rather doubt you have. You are libeling Schildt out of envy, would be
my guess.

 

[spinoza1111]

spinoza1111said:




I do, yes.


I don't dispute this.


I do, however, dispute this.


As has been pointed out, it is certainly possible to blur the
distinction between compilers and interpreters, and it appears that
this is what you are trying to do. The Dragon Book puts it like this:

"Simply stated, a compiler is a program that reads a program written
in one language - the source language - and translates it into an
equivalent program in another language - the target language."

"The target language" is not identified, on p 4 of the Dragon Book
Second Edition, as object code. In fact, later on we read that "a Java
source program may be ** compiled ** [emphasis mine] into an
intermediate form called bytecodes".

The root form of compiler and interpreter is a verb and not a noun.

The Dragon Book describes as an "interpreter" a program which takes
source code and input and executes the source code. For clarity of
exposition, they are describing a rather rare artifact: a program
which executes source code directly, or a one for one encoding of
source directly.

But for clarity, they omit the fact, that they know, that inside what
appears to be and for all intents is an "interpreter" is a compiler of
some sort, that is, a parser which translates the raw source into
encoded form...unless the SOURCE language is Forth-like and does not
need to be parsed!

Even if as in the case of a source language using Reverse Polish
notation there is no parsing, the language still has to be lexically
analyzed, and lexical analysis is what compilers do. A "pure"
interpreter is a limit or ideal case where the interpreter does not
and need not do either lexical or syntax analusis.

For example, I wrote a "pure" interpreter in 1979 for the Mouse
programming language (in 1K of storage) to run on Texas Instruments
TI-79 programmable calculators. This wasn't a compiler since
individual "statements" of Mouse are single characters represented as
floating point numbers on the TI 79, and the language was Reverse
Polish.

Whereas to COMPILE IBM 1401 Fortran-II into something that could be
executed, in 8K, the IBM compiler contained 99 passes to COMPILE
things.

Most "interpreters" are also "compilers" insofar as they have a
parsing front end.

Even if you wrote a program to directly execute a subset of C, your
program would still on the fly be a compiler according to the dragon
book, since either in a single pass, or as a coroutine with the
interpreter, your program will have to parse C. Since compilation is a
verb, a hypothetical compiler that uses recursive descent to transform
C statements into p-code, and passes this material to an interpretive
coroutine, is doing compilation while being an almost pure
interpreter: it is in fact a prejudice that a compiler needs to
transform all source code into a parse tree, and then walk the tree to
generate either object code or p-code.

The narrower meaning of "interpreter" refers only to a program which
accepts an encoding and simulates a computer, but Aho et al. don't
present that meaning.

In other words, just like Schildt, they are producing a text with
hermeneutics.

However, you are still trying to destroy Schildt, so you'll say
anything to advance this cause. I hope he drags you into a British
court and takes your house.

Later, we find: "Instead of producing a target program as a
translation, an interpreter performs the operations implied by the
source program."



No, I've just queried the claim that he wrote a compiler. So far, no
evidence to support such a claim has been produced.


Learn how to ask questions politely. The answer, by the way, is that I
have done so, using both recursive descent and other techniques.

Blow me, scumbag. You state and you imply falsehoods with malicious
intent because you're an unsuccessful author. You got nothing coming,
and I ain't gonna be polite to you. I acknowledged your suggestions in
the text of my code, because on the details you made useful
suggestions, but when you start campaigns of personal destruction, I
ain't your pal.

 

[Richard Tobin]

1. Wrote a lengthy "recursive descent parser". I really hope that you
know that is.

2. Wrote an interpreter based on the output of the parser.

This, in fact, constitutes a compiler.

No, it consitutes an interpreter.

Many compilers have no code
generation, only interpretation,

Then they're interpreters, not compilers.

Certain languages can ONLY be interpreted, and have
compilers.

They have compilers but can't be compiled? Are you drunk?

Therefore, you have lied about Schildt with malicious intent, and this
constitutes civil, and possibly criminal, libel under British law.

I think you'll find the courts won't buy in to your own personal
language.

-- Richard

 

[John Bode]

[snip]

Therefore, you have lied about Schildt with malicious intent, and this
constitutes civil, and possibly criminal, libel under British law.

Have you, scumbag, ever written a parser, using recursive descent or
any other technique? Your Web site says you have worked for what is
probably a rather dreary series of banks and insurance companies, so I
rather doubt you have. You are libeling Schildt out of envy, would be
my guess.

Jesus Christ, dude, take a Xanax. You act like Schildt is your BFF or
something.

Heathfield simply stated that he did not believe Schildt wrote the
Tiny C compiler. That turns out to be true. There's no libel here.

Schildt wrote a LL parser. BFD. I've written my share of LL parsers
too.

 

[Tim Streater]

John Bode said:



Actually, I don't recall stating even that. I did ask for evidence to
support the claim, however.


I know that, and you know that...

Well actually there is. But they're all perpetrated by spinny-boy.

 

[Beej Jorgensen]

Beej, why are you still feeding the troll?

I thought that was pertinent useful information. He was obviously not
compiling with a C compiler, but I wanted to see if he had compliant
code, and RH was saying someone else with a C99 compiler would have to
try to build it.

I think you'll notice that I have not been arguing with about whether or
not C sucks, and that the places I do respond do not incite him. You
might note, for instance, the difference between his response to my
above post versus his response to yours.

-Beej

 

[Phil Carmody]

I thought that was pertinent useful information. He was obviously not
compiling with a C compiler, but I wanted to see if he had compliant
code, and RH was saying someone else with a C99 compiler would have to
try to build it.

I think you'll notice that I have not been arguing with about whether or
not C sucks, and that the places I do respond do not incite him. You
might note, for instance, the difference between his response to my
above post versus his response to yours.

No, I won't note that, as I've killfiled the troll.

Phil

 

[spinoza1111]

[snip]

Therefore, you have lied about Schildt with malicious intent, and this
constitutes civil, and possibly criminal, libel under British law.

Have you, scumbag, ever written a parser, using recursive descent or
any other technique? Your Web site says you have worked for what is
probably a rather dreary series of banks and insurance companies, so I
rather doubt you have. You are libeling Schildt out of envy, would be
my guess.

Jesus Christ, dude, take a Xanax.  You act like Schildt is your BFF or
something.

Xanax? How's that working for you?

Heathfield simply stated that he did not believe Schildt wrote the
Tiny C compiler.  That turns out to be true.  There's no libel here.

Schildt wrote a LL parser.  BFD.  I've written my share of LL parsers
too.

An LL-parser is normally table driven, so you're not up to speed on
terminology. Schildt constructed a hand recursive descent parser as
part of a system that transformed C code into executable code. That
is, he wrote a compiler according to the Aho/Sethi definition that
Richard Heathfield presented as well as an interpreter, and Heathfield
is lying, perpetrating thereby criminal and civil libel under British
law.

 

[spinoza1111]

No, it consitutes an interpreter.


Then they're interpreters, not compilers.

No, according to Heathfield's pointer to the Dragon book, interpretive
compilers have to transform code unless the source code needs no
parsing nor any linking (such as Mouse).

They have compilers but can't be compiled?  Are you drunk?

No, just informed. Not all languages can be transformed into flat
executable code.

 

[Richard Bos]

Why not package it up a bit more maturely with documentation?

Why keep replying to known, and irritating, trolls? Are you aiming to be
one yourself?

Note: no smiley here.

Richard

 

[Richard Bos]

What are you publishing?

Who the **** cares? Stop feeding it.

Richard

 

[Richard Bos]

Nick Keighley wrote:

Lots of reasons. It goes against the grain of the type system for a start:
.field requires a struct on the left, while -> requires a *struct on the
left. You're saying .field can have a ps or *ps on the left, it doesn't
matter! That would be too undisciplined.

You mean, like allowing the () operator to work on a function pointer as
well as a plain function name? Yes, quite unprecedented...

Richard

 

[bartc]

You mean, like allowing the () operator to work on a function pointer as
well as a plain function name? Yes, quite unprecedented...

And like the [] operator working on an array pointer as well as a plain
array name. No need to add "." to that lot too.

Plain array names 'decay' to pointers, so [] effectively work on pointers.
Plain function names presumably also decay to function pointers, so that ()
always works on pointers -- after all you're not manipulating the function
code itself.

But do plain struct names decay to pointers to structs? Or would that be
struct pointers decaying to structs (otherwise you could use -> on plain
struct names)?

No I didn't think so..

 

[Ben Bacarisse]

You mean, like allowing the () operator to work on a function pointer as
well as a plain function name? Yes, quite unprecedented...

Strictly speaking it never does: it must always have a function
pointer on the left (this is a change from K&R C). In that respect it
is like sub-scripting; [] never "sees" an array, only a pointer.

 

[spinoza1111]

Why keep replying to known, and irritating, trolls? Are you aiming to be
one yourself?

"Why are you talking to known, irritating Jews?"

Sure, if you talk to the outcast that makes you an outcast...in the
minds of people at a fourteen year old level of intellectual
development.

 

[Keith Thompson]

You mean, like allowing the () operator to work on a function pointer as
well as a plain function name? Yes, quite unprecedented...

Strictly speaking it never does: it must always have a function
pointer on the left (this is a change from K&R C). In that respect it
is like sub-scripting; [] never "sees" an array, only a pointer.

I'll just note that there is ample precedent in other languages
(Ada, for one) for allowing the prefix of "." to be either a struct
or a pointer-to-struct. It wouldn't introduce any ambiguity in C.
In effect, it would be an overloading of the "." operator, just as
"+" is overloaded for different numeric types -- or, for that matter,
as "." is overloaded for all struct types.

On the other hand, I think it's too late to introduce this as a
change in C. The "->" operator would have to be left in place
(unless you want to insist on doing a global search-and-replace on
all C sources), leading to inconsistent styles.

But it's worth considering for any new C-like (or non-C-like)
languages.

 

[bartc]

Nick Keighley wrote:
struct S *ps;

ps.field = 2; /* illegal */

there is no particular reason why they couldn't have made the last
line legal and equivalent to the previous 2.

Lots of reasons. It goes against the grain of the type system for a
start:
.field requires a struct on the left, while -> requires a *struct on
the
left. You're saying .field can have a ps or *ps on the left, it doesn't
matter! That would be too undisciplined.

You mean, like allowing the () operator to work on a function pointer as
well as a plain function name? Yes, quite unprecedented...

Strictly speaking it never does: it must always have a function
pointer on the left (this is a change from K&R C). In that respect it
is like sub-scripting; [] never "sees" an array, only a pointer.

I'll just note that there is ample precedent in other languages
(Ada, for one) for allowing the prefix of "." to be either a struct
or a pointer-to-struct. It wouldn't introduce any ambiguity in C.
In effect, it would be an overloading of the "." operator, just as
"+" is overloaded for different numeric types -- or, for that matter,
as "." is overloaded for all struct types.

What would it do with pointer to pointer to pointer to struct, do 3 lots of
dereferencing?

On the other hand, I think it's too late to introduce this as a
change in C. The "->" operator would have to be left in place
(unless you want to insist on doing a global search-and-replace on
all C sources), leading to inconsistent styles.

But it's worth considering for any new C-like (or non-C-like)
languages.

I've looked at this too but in my designs, quite often you want to apply
..something on pointers as well as structs (and lots of other things too).

However my syntax uses the sweeter Pascal-like a^.b rather than the
odd-looking a->b or (*a).b. (And often the dereferencing is automatic, such
as when the language provides Var or Inout parameters, so you can write a.b
and still stay on the right side of the type system)

My example above would be a^^^.b in this syntax, but (***a).b or (**a)->b in
C (I think).

 

[Richard Tobin]

What would it do with pointer to pointer to pointer to struct, do 3 lots of
dereferencing?

IIRC that's what Algol68 did - dereference until it has the right
type.

-- Richard

 

[bartc]

IIRC that's what Algol68 did - dereference until it has the right
type.

Yes, that's one of the many things I didn't like about it. (Nice syntax
though, apart from things such as 'b of a' to mean 'a.b')

(I've thought about this some more and while I don't think
auto-dereferencing is appropriate for a C-like language (so that (*a).b,
(**a).b etc can all be written a.b), it might be something to try on a
dynamically typed language:

Once b is known to be definitely a field, and a is a pointer, it can try
deferencing a until it hits a non-pointer (the alternative is a runtime
error). However this problem can come up:

p = &q; // With dynamic typing you can do this!
q = &p;

a = *************************************p; // No problem with this either

But, evaluating p.b could take quite a while..)

 

[Ben Bacarisse]

Yes, that's one of the many things I didn't like about it. (Nice
syntax though, apart from things such as 'b of a' to mean 'a.b')

(I've thought about this some more and while I don't think
auto-dereferencing is appropriate for a C-like language (so that
(*a).b, (**a).b etc can all be written a.b), it might be something to
try on a dynamically typed language:

Once b is known to be definitely a field, and a is a pointer, it can
try deferencing a until it hits a non-pointer (the alternative is a
runtime error). However this problem can come up:

p = &q; // With dynamic typing you can do this!
q = &p;

a = *************************************p; // No problem with this either

But, evaluating p.b could take quite a while..)

This seems to be the wrong way round. You say the auto-dereference in
C would not be appropriate but it might be in a language with
dynamic typing but then you show a problem that C would not have and
the hypothetical dynamic language would.