Fwd: Re: Paul Graham's PyCon Keynote

[Kimberley Burchett <address@hidden>]

---------- Forwarded message ----------
Date: Thu, 10 Apr 2003 14:27:43 -0500
From: Matt Hellige
To: Kimberley Burchett
Subject: Re: Paul Graham's PyCon Keynote

[Kimberley Burchett wrote]
> 
> You can think of an n-ary function as a simple n-ary array of values.  If
> you allow assigning to the result of a function (meaning that the function
> should return the assigned value the next time it's called), then
> functions can take the place of data structures, and vice versa.

This is an interesting and potentially fruitful idea, but I think it
needs a bit more development... I have a few suggestions that I hope
you won't take as criticisms...

 - The C++ syntax is (to my eyes) quite painful, but also ambiguous...
   For example, in C++ with extensions like you propose, you couldn't
   tell whether "size()++" meant "apply operator++() to the value of the
   size() function", or "apply operator++() to the result of calling
   the size() function". "size++", on the other hand, looks like
   function pointer arithmetic. A new syntax might work around this
   problem, but it might be a better demonstration of this idea to
   cast it in a syntactic setting that was more or less specifically
   designed to accommodate this (like Haskell's function definition by
   cases):
     fact 0 = 1
     fact n = n * fact (n - 1)

 - The above hints that maybe there's a relationship here between what
   many functional languages allow in terms of case analysis, and this
   idea... Something like functions definable by cases, but
   extensibly. This is a neat idea, and it highlights some of the
   more subtle issues that might come up: Does order of definition
   ever matter? If so, how could you deal with that? Could you define
   a wildcard (e.g., "get(*) = throw SomeException;" or whatever...)?
   
 - Rather than thinking of functions as "n-ary arrays of values", it
   might be more fruitful to think of them in the more technically
   correct way as "mappings from n-space into 1-space". This suggests
   that maybe a hashtable (dictionary, record, etc.) syntax would be more
   appropriate than an assignment like syntax... So using a
   python-like dictionary syntax:
      int some_func(int, string);
      ...
      some_func[(5, "foo")] = 1
      some_func[(5, "bar")] = 3
   But this raises other questions... For example, it's pretty obvious
   that this only works for pure functions. How would you implement
   something like random()? Could you assign code to a function for
   arbitrary arguments? That's a very neat idea which is again a more
   dynamic run-time generalization of definition by cases, but then
   the language would need to have a syntactic construct for assigning 
   chunks of code to things... Many languages already do, so maybe this 
   is another reason why C++ might not be the best host language for
   this... ;)

 - There are real questions about security and scope... Can any bit of
   code extend or modify the behavior of any function in any other
   scope? I bet there are a bunch of really interesting related
   questions here...

Anyway, those are some things that immediately occur to me. I
definitely think it's an idea worth pursuing further. I hope this
isn't more than you bargained for posting about it. :)

Matt

PS. Feel free to forward this to the list, or reply to the list if you'd
like. I didn't know for sure whether this was getting off-topic as I'm
new to ll1...

-- 
Matt Hellige                  <matt@immute.net>
http://matt.immute.net