Lisp on Lines

ruby-talk
1

Read on the comp.lang.lisp group that someone is developing 'Lisp on Lines'

http://groups.google.co.nz/groups?q="lisp+on+lines"&hl=en

I've always admired Lisp from afar. I wonder what it could do for a web
framework?

Luke

2

http://www.paulgraham.com/articles.html

   specifically:

     Beating the Averages
     http://lib.store.yahoo.com/lib/paulgraham/bbnexcerpts.txt

cheers.

-a

···

On Sun, 24 Jul 2005, luke wrote:

Read on the comp.lang.lisp group that someone is developing 'Lisp on Lines'

http://groups.google.co.nz/groups?q="lisp+on+lines"&hl=en

I've always admired Lisp from afar. I wonder what it could do for a web
framework?

Luke

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

3

Yes, I've read Paul Graham's book "Hackers and Painters", which is what
inspired me to think programming could be for me in first place.

···

Essays

   specifically:

     Beating the Averages
     http://lib.store.yahoo.com/lib/paulgraham/bbnexcerpts.txt

cheers.

-a
--

============================================================================

> email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> phone :: 303.497.6469
> My religion is very simple. My religion is kindness.
> --Tenzin Gyatso

============================================================================

4

How much less powerful than Lisp is Ruby?

5

I've only had passing experience with Lisp but the macro facility seems incredibly powerful and useful, especially for defining mini-languages. Also functions are real first-class constructs in Lisp and not in Ruby, afaict. I'm sure there's other stuff but those are the features I envy from Lisp.

Now, how much less readable than Ruby is Lisp? :wink:

William James wrote:

···

How much less powerful than Lisp is Ruby?

6

Lisp has many more features, in fact the entire language could be
viewed as a feature expression system.

That doesn't mean that Ruby is at a huge disadvantage. Ruby has most
of the important parts of lisp. It does lack macos, but very few
languages have the uniform syntax necessary to make macros as easy and
natural as they are in Lisp. Ruby has higher order functions (albeit
with a keyword massage sometimes), lambdas, closures, garbage
collection, and OO.

Some people would argue that Lisp's Object system, CLOS, is more
powerful than Ruby's because it supports multiple dispatch, and it may
be true that some things express themselves more gracefully in CLOS,
but Ruby's method has a lot of strengths too. Ruby also has a very
strong advantage in the meta-object-programming department. While CL
does have a standard for this, called "the MOP," implementation is
spotty and often subtle details cause incompatibility across Lisp
interpreters, and the MOP itself is often poorly understood even on
comp.lang.lisp.

Actually, that's kind of the story of modern Lisp. "Subtle details
cause incompatibility across Lisp interpreters." It's sad to see such
a fine language ritualistically beat and abuse itself, but its
community insists on a perpetual fork. This fork doesn't just extend
between open source and commerical lisps, which might be
understandable, but also among several open source inheritors, none of
which really could constitute a universal distribution.

···

On 7/24/05, William James <w_a_x_man@yahoo.com> wrote:

How much less powerful than Lisp is Ruby?

--
--
Dave Fayram (II)
dfayram@lensmen.net
dfayram@gmail.com

7

William James wrote:

How much less powerful than Lisp is Ruby?

BTW: did anyone try to write a Ruby interpreter in Lisp?
Might be challenging...

benny

8

This looks like first class functions to me:

def accgen (n)
  lambda {|i| n += i }
end

foo = accgen(5)
foo.call(5) # returns 10
foo.call(5) # returns 15

accgen function borrowed from http://www.paulgraham.com/accgen.html

Lisp macros are the main area in which Lisp has more power than Ruby,
and are closely related to Lisp's syntax (or non-syntax). Macros allow
for new language constructs much like OOP allows for new types, for
example, if Common Lisp didn't have unless, you could add it like this:

(defmacro unless (test &rest forms)
  `(if ,test 'nil
    ,@forms))

9

Thanks Dave for the interesting post. Would these problems be solved if
Common Lisp went open source?

I noticed a post on a site

http://lemonodor.com/archives/000671.html

that suggests there are some promising dialects of Lisp that are open
source, but currently aren't as rich as, say Common Lisp.

When choosing a new and flexible language, one of the deciding factors for
me choosing Ruby was the fact it was open source.

"Dave Fayram" <dfayram@gmail.com> wrote in message
news:6fb0069505072515455ea2ecc1@mail.gmail.com...

How much less powerful than Lisp is Ruby?

Lisp has many more features, in fact the entire language could be
viewed as a feature expression system.

That doesn't mean that Ruby is at a huge disadvantage. Ruby has most
of the important parts of lisp. It does lack macos, but very few
languages have the uniform syntax necessary to make macros as easy and
natural as they are in Lisp. Ruby has higher order functions (albeit
with a keyword massage sometimes), lambdas, closures, garbage
collection, and OO.

Some people would argue that Lisp's Object system, CLOS, is more
powerful than Ruby's because it supports multiple dispatch, and it may
be true that some things express themselves more gracefully in CLOS,
but Ruby's method has a lot of strengths too. Ruby also has a very
strong advantage in the meta-object-programming department. While CL
does have a standard for this, called "the MOP," implementation is
spotty and often subtle details cause incompatibility across Lisp
interpreters, and the MOP itself is often poorly understood even on
comp.lang.lisp.

Actually, that's kind of the story of modern Lisp. "Subtle details
cause incompatibility across Lisp interpreters." It's sad to see such
a fine language ritualistically beat and abuse itself, but its
community insists on a perpetual fork. This fork doesn't just extend
between open source and commerical lisps, which might be
understandable, but also among several open source inheritors, none of
which really could constitute a universal distribution.

···

On 7/24/05, William James <w_a_x_man@yahoo.com> wrote:

--
--
Dave Fayram (II)
dfayram@lensmen.net
dfayram@gmail.com

10

benny ha scritto:

William James wrote:

How much less powerful than Lisp is Ruby?

BTW: did anyone try to write a Ruby interpreter in Lisp? Might be challenging...

no, but there were some scheme implementations in ruby :wink:

11

Perhaps I'm misunderstanding here, please bear with me. Ruby doesn't have the ability to do this:

a = "test".length
a() => 4

Instead, you have to do this:

a = lambda {"test".length}
a.call()

To me it seems that the closure is first-class but the actual function/method is not. You cannot pass non-anonymous functions as arguments, you cannot assign them to variables, you cannot compare them for equality, as you can in Lisp (and many other functional languages). No?

···

zak.wilson@gmail.com wrote:

This looks like first class functions to me:

def accgen (n)
lambda {|i| n += i }
end

foo = accgen(5)
foo.call(5) # returns 10
foo.call(5) # returns 15

accgen function borrowed from Accumulator Generator

Lisp macros are the main area in which Lisp has more power than Ruby,
and are closely related to Lisp's syntax (or non-syntax). Macros allow
for new language constructs much like OOP allows for new types, for
example, if Common Lisp didn't have unless, you could add it like this:

(defmacro unless (test &rest forms)
`(if ,test 'nil
   ,@forms))

12

Thanks Dave for the interesting post. Would these problems be solved if
Common Lisp went open source?

Er, there are quite a few open source CL implementations

     http://www.cliki.net/Common%20Lisp%20implementation

-Brian

···

On Jul 25, 2005, at 8:55 PM, luke wrote:

I noticed a post on a site

Lemonodor: The Best Open Source Lisp

that suggests there are some promising dialects of Lisp that are open
source, but currently aren't as rich as, say Common Lisp.

When choosing a new and flexible language, one of the deciding factors for
me choosing Ruby was the fact it was open source.

"Dave Fayram" <dfayram@gmail.com> wrote in message
news:6fb0069505072515455ea2ecc1@mail.gmail.com...
On 7/24/05, William James <w_a_x_man@yahoo.com> wrote:

How much less powerful than Lisp is Ruby?

Lisp has many more features, in fact the entire language could be
viewed as a feature expression system.

That doesn't mean that Ruby is at a huge disadvantage. Ruby has most
of the important parts of lisp. It does lack macos, but very few
languages have the uniform syntax necessary to make macros as easy and
natural as they are in Lisp. Ruby has higher order functions (albeit
with a keyword massage sometimes), lambdas, closures, garbage
collection, and OO.

Some people would argue that Lisp's Object system, CLOS, is more
powerful than Ruby's because it supports multiple dispatch, and it may
be true that some things express themselves more gracefully in CLOS,
but Ruby's method has a lot of strengths too. Ruby also has a very
strong advantage in the meta-object-programming department. While CL
does have a standard for this, called "the MOP," implementation is
spotty and often subtle details cause incompatibility across Lisp
interpreters, and the MOP itself is often poorly understood even on
comp.lang.lisp.

Actually, that's kind of the story of modern Lisp. "Subtle details
cause incompatibility across Lisp interpreters." It's sad to see such
a fine language ritualistically beat and abuse itself, but its
community insists on a perpetual fork. This fork doesn't just extend
between open source and commerical lisps, which might be
understandable, but also among several open source inheritors, none of
which really could constitute a universal distribution.

--
Dave Fayram (II)
dfayram@lensmen.net
dfayram@gmail.com

13

Common Lisp is an open standard. There are implementations of it that
are proprietary, and implementations that are open source. Clisp, CMUCL
and SBCL are popular open source implementations; Allegro CL and
LispWorks are popular proprietary implementations, and a number of
others exist. Problems arise where the standard isn't quite specific
enough, but these are usually fairly trivial; Common Lisp offers reader
macros to conditionally read code depending on which implementation is
in use.

14

Perhaps we need a new term. According to Google, "First class hooberglobbers" seems to mean hooberglobbers can be assigned to variables, parameters, and return values, and then, though the assignee, can be manipulated in all the ways that hooberglobbers can be manipulated. Under this definition, yes, Ruby has first class functions.

I have a stricter definition. Let's call it "patrician hooberglobbers." Patrician hooberglobbers, to me, have the additional quality that the syntax for manipulating a hooberglobber is the same whether it is referred to statically or by evaluation/substitution (as through a variable, or return value of a function call). In this sense, Ruby has patrician classes:

a = String.new
b = String
c = b.new

However, while Lisp, Python (from the examples I've seen), and Unlambda have patrician functions, Ruby does not. I can think of two simple enough reasons for this:

1. Because Ruby has a "poetry mode," there is no way to refer to a function by reference -- simply referring to it invokes it. The closest you can get is to refer to the Symbol representing its name, or to create a Method object, which really just wraps an invocation of the method inside a class.

This could be "fixed" by creating a syntax to "thunk" function names, and to later apply them. So that, given some function 'foo', you could say:

foo "hello"; ^foo("hello"); a = ^foo; a("hello");

But then ^ is just syntactic sugar for self.method, and () sugar for Method#call. This doesn't escape the fact that a can't be treated the same as foo.

2. Actually, when I was writing reason #2, I wrote some example code to show that a method is just a way for an object to receive messages in Ruby, but got a surprising result, so there is no #2. Here's the code, though:

class Foo; def thing; nil end end
f = Foo.new; f.thing #=> nil
m = f.method :thing; m.call #=> nil
class Foo; def thing; 5 end end
f.thing #=> 5
m.call #=> nil

Heh, it seems that Ruby really does have first class functions. :wink: (Why is this happening, btw? Does this have something to do with continuations?)

Now, does a language need patrician functions? I dunno, I seem to be enjoying Ruby, and my opinion is pretty much all anybody needs to concern themselves with.

Devin

···

zak.wilson@gmail.com wrote:

This looks like first class functions to me:

def accgen (n)
lambda {|i| n += i }
end

foo = accgen(5)
foo.call(5) # returns 10
foo.call(5) # returns 15

accgen function borrowed from Accumulator Generator

15

"luke" <lduncalfe@eml.nope> writes:

Thanks Dave for the interesting post. Would these problems be solved if
Common Lisp went open source?

I noticed a post on a site

Lemonodor: The Best Open Source Lisp

that suggests there are some promising dialects of Lisp that are open
source, but currently aren't as rich as, say Common Lisp.

Huh? Is GNU Common Lisp not actually an implementation of Common Lisp?
GCL is not only open source, it's Free Software(TM) in the
Richard Stallman-approved sense.

16

Thanks Dave for the interesting post. Would these problems be solved if
Common Lisp went open source?

It already is, but the quality of open source implementations varies
wildly. Not quality as in "are they good." The amount of ego and
expertise that tends to reside in the lisp community assures that the
projects meet their goals. Quality as in, "What problems does this
solve?" Some CMUCL, for example, is an incredibly good compiler when
you need very fast lisp. However, it's harder to use than SBCL, which
has my vote for easiest lisp distro to use in general (and it's what
Peter Seibel distributes as "Lisp In A Box"). On a mac, OpenMCL has a
ton of great features.

The commerical offerings solve enterprise solution problems. Ever seen
a CORBA->Lisp binding? They actually make CORBA usable! But you pay a
lot and LispWorks and Allegro still compile slower mathmatical code.

that suggests there are some promising dialects of Lisp that are open
source, but currently aren't as rich as, say Common Lisp.

They are all common lisp.

And the first thing that drew me to Ruby was its peculiar and very
right-seeming "Ruby Way." Matz has impeccable taste in coding, and
Ruby reflects that taste.

···

On 7/25/05, luke <lduncalfe@eml.nope> wrote:
--
--
Dave Fayram (II)
dfayram@gmail.com

17

a = "test".method(:length)
a.call
=> 4

Kirk Haines

···

On Monday 25 July 2005 4:25 pm, Joe Cheng wrote:

Perhaps I'm misunderstanding here, please bear with me. Ruby doesn't
have the ability to do this:

a = "test".length
a() => 4

Instead, you have to do this:

a = lambda {"test".length}
a.call()

18

Joe Cheng wrote:

Perhaps I'm misunderstanding here, please bear with me. Ruby doesn't
have the ability to do this:

a = "test".length
a() => 4
Instead, you have to do this:

a = lambda {"test".length}
a.call()

It's the same in Lisp. In your first example, "test".length gets
evaluated, and that value is assigned to a:

Ruby:
a = "test".length
a.class #Fixnum
a #4

a = lambda {"test".length}
a.class #Proc
a.call() #4

Lisp:
(setf a (length "test"))
(a) ;error
(type-of a) ;(INTEGER 4 4)
a ;4

(setf a (lambda () (length "test")))
(type-of a) ;EVAL:INTERPRETED-FUNCTION
(funcall a) ;4

19

Devin Mullins <twifkak@comcast.net> writes:

1. class Foo; def thing; nil end end
2. f = Foo.new; f.thing #=> nil
3. m = f.method :thing; m.call #=> nil
4. class Foo; def thing; 5 end end
5. f.thing #=> 5
6. m.call #=> nil

Heh, it seems that Ruby really does have first class
functions. :wink: (Why is this happening, btw? Does this have
something to do with continuations?)

No... nothing to do with continuations. It's quite simple:
On line 3, a reference to the method body that was defined
on line 1 is stored in the method object bound to ‘m’; the
fact that the Foo#thing method is subsequently replaced on
line 4 does not affect the method object, which still has
its reference to the old method body.

···

--
Daniel Brockman <daniel@brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this? --TTN.

20

harp:~ > irb
   irb(main):001:0> a = lambda{ p 42 }
   => #<Proc:0xb755d848@(irb):1>

   irb(main):002:0> a ()
   42
   => nil

   irb(main):003:0> a()
   42
   => nil

   irb(main):004:0> b = a
   => #<Proc:0xb755d848@(irb):1>
   irb(main):005:0> b()
   42
   => nil

   harp:~ > ruby -v
   ruby 1.9.0 (2005-05-16) [i686-linux]

   harp:~ > irb -v
   irb 0.9.5(05/04/13)

getting pretty close...

cheers.

-a

···

On Tue, 26 Jul 2005, Devin Mullins wrote:

zak.wilson@gmail.com wrote:

This looks like first class functions to me:

def accgen (n)
lambda {|i| n += i }
end

foo = accgen(5)
foo.call(5) # returns 10
foo.call(5) # returns 15

accgen function borrowed from Accumulator Generator

Perhaps we need a new term. According to Google, "First class hooberglobbers" seems to mean hooberglobbers can be assigned to variables, parameters, and return values, and then, though the assignee, can be manipulated in all the ways that hooberglobbers can be manipulated. Under this definition, yes, Ruby has first class functions.

I have a stricter definition. Let's call it "patrician hooberglobbers." Patrician hooberglobbers, to me, have the additional quality that the syntax for manipulating a hooberglobber is the same whether it is referred to statically or by evaluation/substitution (as through a variable, or return value of a function call). In this sense, Ruby has patrician classes:

a = String.new
b = String
c = b.new

However, while Lisp, Python (from the examples I've seen), and Unlambda have patrician functions, Ruby does not. I can think of two simple enough reasons for this:

1. Because Ruby has a "poetry mode," there is no way to refer to a function by reference -- simply referring to it invokes it. The closest you can get is to refer to the Symbol representing its name, or to create a Method object, which really just wraps an invocation of the method inside a class.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================