Re: F# fsharp

Jon Watte wrote:
>> Ruby
> 
> Ruby is kind-of like LISP, except it doesn't quite have the fully
> first-class-everything that LISP does.

Humorously, though perhaps also interestingly, Ruby can look a lot
more like Lisp that it would have occurred to me to suppose.

There was an especially staunch Lisper on ruby-talk last year, who
would post ruby code like the following.  I did a double-take when
I first saw this, as I assumed i was reading Lisp until I realized
it was Ruby:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/336646

:)


> If I remember correctly, named
> functions are irrevocably different from global variables referring to
> lambdas, for example.

Yes; this bothered me a bit, conceptually, when I was learning
ruby.  In practice I can't recall it manifesting as an issue,
however.  I suspect this is because one can turn a method into a
lambda-equivalent:

# Define a "real" method:
>> def foo_method(a)
>>   puts "foo: #{a}"
>> end

# Obtain a lambda-like object representing foo_method:
>> foo = method :foo_method

# Define a similar lambda object:
>> bar = lambda {|a| puts "bar: #{a}"}

# Toss the lambda and bound method object into an array
# together, and invoke each equivalently:
>> [foo, bar].each {|m| m[123]}
foo: 123
bar: 123


So one can pass any bound method around just like a lambda
and call them the same way.  (The bound method retains its
lexical scope, with 'self' bound to its associated object
instance.)

So the difference that remains between "real" methods
like foo_method, vs. a lambda, ends up being more syntax
than semantics.  Which is quirky, but which in practice
seems to be a non-issue when we just pass them around as
lambda-like objects.


Regards,

Bill

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com