🚀 go-pugleaf

In article <23986:Dec2703:47:1390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <19418@yunexus.YorkU.CA> oz@yunexus.yorku.ca (Ozan Yigit) writes:
>> You are confusing the intrinsic expressiveness
>> of a language with that which is programmable in it.
>
>No fair to ignore my examples to the contrary. I think you're confusing
>language syntax with language semantics. Or can you define ``intrinsic
>expressiveness'' in terms of anything but syntax? Are composable
>functions part of the ``intrinsic expressiveness'' of Q?
>
>I'd also like to point out that real-world programmers really don't care
>whether a solution is part of ``the intrisic expressiveness'' of a
>language as long as it is ``programmable in it.'' Okay, okay, so I
>shouldn't bring up real-world programming issues in a computer science
>discussion. Sorry.
>
>---Dan


I didn't want to post on this subject again, but since Dan seems to
think that those opposing his view of things cannot express clearly
what their objection is I'll make just one more try (to explain what
I mean, at least).

I apologize to those who find this trivial and think it's just
a waste of time and space.

Since Dan seems to hate computer science (or is it just computer
scientists? Btw. what do you consider yourself to be Dan?) I will
try to refrain from using computer science arguments.

First a short recap of the argument so far, to the right I've
put a similar but completely fictitious argument (the analogy
is not perfect).

Initial claim:                        Initial claim:                   
C has first class functions.	      C has integers.                  
				                                       
My claim:			      Claim:                           
In C you cannot write a function      In C you cannot write a function 
int (*compose)(int (*f)(int), 	      int factorial(int n);            
               int (*g)(int));	                                       
with the proprety		      with the property                
(*compose(f,g))(x) == f(g(x))	      factorial(n)/1/2/ ... /(n-1)/n == 1
				                                       
Dan's counterclaim:		      Counterclaim:                    
Yes, you can. You just define	      Yes, you can.  You just define   
typedef ... func;		      typedef ... bignum;             
func cf_to_func(int (*f)(int))	      bignum int_to_bignum(int) ...  
				      bignum mul(bignum, bignum)    
				                                       
...				      ...                              
				                                       
and now you can define		      and now you can define           
				                                       
func compose(func f, func g) {	      bignum factorial(bignum n) {   
...				      ...                              
}				      }                                

The problem with the counterclaim is that it talks about a completely
different, newly defined type called func (integer), but the original
claim was about another builtin type.

Dan claims that there is no practical difference, but I think there
is a very big one.  If I have tons of code that uses functions (ints)
I would have to make massive changes to be able to use that code with
these new type func (bignum).  Even worse, I may not have the source code
for all the things I use, e.g. a library function like qsort (abs) would
fail horribly if passed an object of the new type insteaad of the original.
It is true that if I have the source the changes are massive, but trivial
so they could be automated.  Unfortunately in the real world you don't
always have the source.
(You cannot write a total function that converts func to C functions any more
than you write a total function that converts bignum to int.  The function
has to fail (or give a "wrong" result) for some arguments.)

To state my argument concisely:  If a predefined type X (function, int)
does not have property P it does not matter if it possible to define
another type that has property P, X still does not have it.

Furthermore, C is such that predefined types have special syntax
and the compiler handles code generation for then in a special way.
This is what makes it into a practical problem.  If a program uses a
*defined* type X in C it would probably be easy (a minimal number of or 
perhaps no changes) to change it so that it uses Y instead.  It would
still be true that if X does not have property P, then it hasn't.
But then I would agree with Dan: the practical implications of the
whole thing would be inconsequential.

Since Dan's description of Q was rather short I cannot say anything
about Q.  Is it the case that you can change anything without
syntactical changes?  Without recompilation?

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
We break here for a short message from our sponsor.  This is a 
excerpt from a thread in comp.lang.nonsense:

Anonymous voice says:
FORTRAN is a subset of C.

August Lennartsson says:
No, here's a counterexample
       DO 10 I = 1,10
10     J = J + I
       END

Ben Darnstein says:
Yes it is!  Just make the following trivial change
main()
{
    fortran_interpreter("
       DO 10 I = 1,10
10     J = J + I
       END
");
}

and this simple definition
fortran_interpreter(char *s) { ... }

There you are!  FORTRAN is a subset of C!

-----
And now back to our main program.
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

A way of changing C to allow the definition of (my) compose would
be to allow nested function defintions and the possibility to return
an inner function.  You would the do

int (*compose)(int (*f)(int), int (*g)(int)) {
    int r(int x) {
        return f(g(x));
    }

    return r;
}

An implementation of this would of course have to do something along
the lines of what Dan suggested, i.e. you cannot just return a pointer
to the code for a function, you have to return a closure with a code
pointer and an environment with the free variables (f and g in the example).

If this was added to C you would almost certainly also want garbage
collection since the closures would probably be heap allocated and
adding explicit freeing of them would be weird since then the programmer
has to free object that has been allocated by the runtime system.

Enough of this ranting.  Exhausted and convinced that Dan wants the last
word on this I leave this group you Dan!


	-- Lennart Augustsson
[This signature is intentionally left blank.]