Ruby in Lisp, preLisp

Discussion in 'Ruby' started by Ruli Lupy, Jan 3, 2010.

  1. Ruli Lupy

    Ruli Lupy Guest

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


    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))

    you obtain some speed up, because f.each-line is a macro and get
    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
    more speed but the syntax requires a little more typing.

    What do you think of this? (code in comp.lang.lisp)
    Ruli Lupy, Jan 3, 2010
    1. Advertisements

  2. I am sorry, yes.
    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 Klemme, Jan 3, 2010
    1. Advertisements

  3. 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.


    Michal Suchanek, Jan 4, 2010
  4. 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}{|f| f.each(&x) }

    Or: do |f|
    lines = f.each_line
    while (line =
    if need_next_line_now?
    next_line =


    class File
    def every_other_line
    lines = self.each_line
    loop do
    rescue StopIteration

    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.
    Great! More speed for Ruby is generally a good thing...
    Well, that kind of kills one of the biggest advantages of Ruby in the first

    And you don't necessarily have to specify types explicitly to get the
    performance advantages of static typing, or even of native compiled code:
    David Masover, Jan 4, 2010
  5. 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
    Charles Oliver Nutter, Jan 6, 2010
  6. Can you give one or two examples (for an edge-case)?
    Albert Schlef, Jan 7, 2010
  7. Ruli Lupy

    Ryan Davis Guest

    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.=
    Ryan Davis, Jan 7, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.