🚀 go-pugleaf

In article <BtwIqK.78M@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   The name of a variable is purely arbitrary, and any other string of
   symbols recognized as one is just as good.  But an operator is a
   constant, and cannot just be renamed.

I have a different view of operators.  To me they are just symbols
which I can alter at will as long I as know the underlying meaning of
the operator i.e. at one level it doesn't matter to me whether I write
"2 + 2" or "(plus 2 2)", they both imply addition.  Of course this
leads to "how do you know it is addition?" ...

   Now one can attempt to define an operator in terms of "system primitives,"

You certainly can, but why would you want to bother?  I'm not saying
you can't have the semantics, I'm just saying you might not be able to
have the syntax you want.  You can currently write "2 + 2" in most
languages but you certainly can't put an integral sign in your code.
Do you view these things as different in some way?  I don't, to me "+"
is just a shorthand for "plus".  In the case of an integral sign,
there is no shorthand, you just have to use "integrate".


   Do we not have overloaded operators now?

Yes, but is that anything to be proud of?  I'm personally still
ambivalent towards operator overloading.  Most languages that
currently allow operator overloading only do so in a fixed manner.  My
guess is that this is because allowing user defined operator
overloading requires more powerful type systems than you seen in the
vast majority of languages.  The only language that I'm aware of that
makes any progress in this respect is Haskell.  Its type system is
powerful enough to allow the definition of a certain class of user
defined operators e.g. it can easily cope with overloading +, -, * ...
etc.  However, you cannot currently parameterise over an
implementation so you can use the same notation for indexing dense and
sparse matrices (work is being done on this though).


   The CS people should not be telling users that the hardware/software
   combination is "smart."  Rather, they should emphasize that it is very
   unintelligent, but very fast--a super-fast sub-imbecile.

Are you sure you're not taking them out of context?  Some software can
be "smart" in a certain sense.  For example, a compiler can employ all
sorts of optimisation techniques that altough I may know I may miss in
a certain section of code.  Now the compiler isn't smart, it is just
very quickly applying lots of rules that some "smart" compiler writer
put into it.  So depending on how you look at it the compiler is
either "smart" in the sense that it can outdo the average programmer
or it is "dumb" in the sense that it can only use the rules it has
been given.  I think both views are equally valid depending on the
context and how much you attatch the the semantics of "smart" and
"dumb".  Anyway, if you don't think you are taking "CS people" out of
context, then name names or give quotes so this "CS person" can judge
for himself. 


   computer, there would have to be very careful translations.  These
   could be local or global; the .h files are such, and are in common
   use now.  But they, and the current methods of incorporating
   user-defined macros, are inadequate.

What "current methods"?  I realise that there are some primitive macro
processors out there (e.g. cpp for C), but there are better ones.  I
personally think the Scheme macro system is better than most and would
be interested to hear if/why you think it is inadequate.

bevan