🚀 go-pugleaf

	"Sophistry, thy name is Bernstein." -- Anon

I think I am truly beginning to fathom the meaning of that old saying.


	"In France, they have a different word for EVERYTHING!"
				-- Steve Martin

In article <25199:Feb801:33:1191@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>I chose the subject line (I choose most subject lines in comp.lang.misc
>these days) and I was using ``L has X'' to mean ``X can be implemented
>in L'' where L is a language and X is a semantic feature. Apparently

This is not the meaning of ``has''.  X can be implemented in L is a
meaningless statement for any languages that are Turing equivalent.
Meaningless terminology is not useful, and quite frankly Dan, I challenge
you to give me evidence that _anyone_ uses ``has'' in the sense(lessness)
that you do.

To Dan, C ``has'' multiple inheritance because C++ does and C++ can be
implemented in C.  I don't think I can say anything more about this.

	"You can teach nothing to a stone." -- John McCarthy

>
>That call was improperly formed and nonsensical as both a mathematical
>expression and a C language expression.
>

Dan, wtf are you talking about??

	square o square o square

is perfectly sensible as a mathematical expression.  The parens can be
omitted because functional composition is associative, but most
programming languages would prefer that you write

	(square o square) o square

or

	square o (square o square)

In languages that don't give you the ability to make compose an infix
operator, either

	compose(compose(square,square),square)

or

	compose(square,compose(square,square))

is perfectly sensible (C would require some address-of operators due to
its confused handling of functions and functional values).

In order to save Dan hours of strenous calculation, I'll add that they
are eighth power functions, ready to be applied to a integer (assuming
square is an int->int function).  For instance,

	print (((square o square) o square) 2)

should print 256.

And yes, Dan, I specifically request you to try explain what is nonsensical
about those expressions.  I will be willing to let you off with simply
"I was having a bad day."

Instead of continually saying it's trivial, post your compose code in C and
then we'll see how it stacks up.  Remember, it doesn't have to be
polymorphic.  I'll be suprised if you can handle even the simple case
(int->int)*(int->int)->(int->int).

-- Doug Quale
quale@picard.cs.wisc.edu