Ruby in Lisp, preLisp

[Ruli Lupy]

Hello, as I am learning Lisp and I like Ruby, I defined some macros in
Lisp,
for example

f.each-line
h.each-key
h.each-value

so you pay the price of having to specify the first argument, for
example the following Lisp code to collect the lines from a file.

(let (lines)
(f.each-line "my.file" line (push "line" lines))
lines)

you obtain some speed up, because f.each-line is a macro and get
translated
into Lisp code.

Do you think the notation is very ugly?

The idea is that you can translate Ruby to Lisp in this way and get
some
more speed but the syntax requires a little more typing.

What do you think of this? (code in comp.lang.lisp)

 

[Robert Klemme]

Hello, as I am learning Lisp and I like Ruby, I defined some macros in
Lisp,
for example

f.each-line
h.each-key
h.each-value

so you pay the price of having to specify the first argument, for
example the following Lisp code to collect the lines from a file.

(let (lines)
(f.each-line "my.file" line (push "line" lines))
lines)

you obtain some speed up, because f.each-line is a macro and get
translated
into Lisp code.

Do you think the notation is very ugly?

I am sorry, yes.

The idea is that you can translate Ruby to Lisp in this way and get
some
more speed but the syntax requires a little more typing.

What do you think of this? (code in comp.lang.lisp)

My 0.02EUR: interpretation of programming languages in other programming
languages usually does not help improve performance. I believe the
approach to let Ruby run on a highly optimized runtime environment (like
JRuby does with the JWM or IronRuby with CLR) is a more promising
approach if you want to speed up Ruby execution.

Kind regards

robert

 

[Michal Suchanek]

My 0.02EUR: interpretation of programming languages in other programming
languages usually does not help improve performance. =C2=A0I believe the = approach
to let Ruby run on a highly optimized runtime environment (like JRuby doe= s
with the JWM or IronRuby with CLR) is a more promising approach if you wa= nt
to speed up Ruby execution.

While it does not necessarily improve performance it may improve
interoperability between the two languages. That requires a full
interpreter of the original syntax, though. Doing that correctly for
Ruby has proven quite difficult in other languages and I don't see any
reason for Lisp being any different in this regard.

Thanks

Michal

 

[David Masover]

so you pay the price of having to specify the first argument, for
example the following Lisp code to collect the lines from a file.

(let (lines)
(f.each-line "my.file" line (push "line" lines))
lines)

you obtain some speed up, because f.each-line is a macro and get
translated
into Lisp code.

That would speed up that specific example, but I don't think you could do it
in any sort of generic way. Consider these uses:

x = lambda{|line| puts line}
File.open{|f| f.each(&x) }

Or:

File.open do |f|
lines = f.each_line
while (line = lines.next)
if need_next_line_now?
next_line = niles.next
end
end
end

Or:

class File
def every_other_line
lines = self.each_line
begin
loop do
lines.next
yield lines.next
end
rescue StopIteration
end
end
end

There are all sorts of interesting ways you can use blocks which are
definitely more like lambdas (which Lisp has), and less like macros.

There are also plenty of tricks you can do with Lisp macros that you can't
really do with Ruby blocks. At best, you can fake it by going back and re-
parsing that code.

The idea is that you can translate Ruby to Lisp in this way and get
some
more speed

Great! More speed for Ruby is generally a good thing...

but the syntax requires a little more typing.

Well, that kind of kills one of the biggest advantages of Ruby in the first
place:

http://en.wikipedia.org/wiki/Duck_typing

And you don't necessarily have to specify types explicitly to get the
performance advantages of static typing, or even of native compiled code:

http://code.google.com/p/v8/

 

[Charles Oliver Nutter]

While it does not necessarily improve performance it may improve
interoperability between the two languages. That requires a full
interpreter of the original syntax, though. Doing that correctly for
Ruby has proven quite difficult in other languages and I don't see any
reason for Lisp being any different in this regard.

As someone who's been working on a Ruby impl for the past 4 years, I
can say that interpreting Ruby is not necessarily the hardest
part...what actually takes forever (almost literally forever) is
getting all the core classes behaving correctly. RubySpec and the
various test suites we use in JRuby have helped that process, but
there's still a lot of edge cases you have to use to discover.

It is for this reason that Ruby implementations seem to come out of
the woodwork but stumble a bit after leaving the gate. They can run
Ruby code very early (and often very fast). Then they have to address
the much larger task of implementing all the core classes...

- Charlie

 

[Albert Schlef]

As someone who's been working on a Ruby impl for the past 4 years, I
can say that interpreting Ruby is not necessarily the hardest
part...what actually takes forever (almost literally forever) is
getting all the core classes behaving correctly. RubySpec and the
various test suites we use in JRuby have helped that process, but
there's still a lot of edge cases you have to use to discover.

Can you give one or two examples (for an edge-case)?

 

[Ryan Davis]

=20
Can you give one or two examples (for an edge-case)?

A few easy ones off the top of my head are Array#pack, String#unpack, =
and String#[]. Amazing amount of edge cases on all of those, just =
getting complete test coverage for them is difficult.=