Toxic Elephant : Tag ruby, everything about ruby

The Arc Challenge

blog@matijs.net (matijs) — Sun, 17 Feb 2008 21:14:00 +0000

Hm, so Arc is here, and Paul Graham gives the Arc challenge. The answer in Arc is short indeed. First, let’s see an answer in Rails (loading a framework is allowed according to the challenge), with said_controller.rb:

class SaidController < ApplicationController
  def index; end
  def click; session[:it] = params['what']; end
  def show; end
end

and some templates, for the first page, index.html.erb:

<% form_tag '/said/click' do %>
  <%= text_field_tag 'what' %>
  <%= submit_tag %>
<% end %>

second page, click.html.erb:

<%= link_to 'click here', {:action => 'show'} %>

third page, show.html.erb:

You said <%= session[:it] %>

The Rails answer may be a little longer (although by how much is hard to say due to the different syntax—is end a token?), but it not a case of the same but longer.

First, the Rails version is in temporal order, the Arc version is not. Perhaps there’s a way of reading the Arc version that makes this order natural, but right now, it looks confusing.

But the most striking difference is that it is based on a completely different philosophy of how web applications should be developed. The Arc answer is great if you want a web application based on continuations. The Rails answer is what you would use if you want to use REST.

I’m definitely in the REST camp, which makes this example meaningless as a demonstration of Arc. It shows me that Arc can be used to write a short program that does something I don’t want to do.

The ultimate question of course is whether brevity (in terms of number of tokens, not characters) is the single best metric for language power.

Update: Someone wrote a Ruby version that is about as short as the Arc version, uses the same paradigm, and is in temporal order:

def said
  aform(input("foo"), submit) {
    w_link("click here") {
      "you said: #{arg :foo}"}}
end

Undressed Ruby

blog@matijs.net (matijs) — Sun, 14 Oct 2007 12:14:00 +0000

In Ruby, there is really no compile time. There is parse time, and then there is run time. All class and method definitions are done at run time.

  class Foo
    def bar
      puts "Zoo!"
    end
  end

is basically¹:

  Foo = Class.new do
    self.define_method(:bar) do
      puts "Zoo!"
    end
  end

See, we just removed the class and def keywords from Ruby. What else? Ah yes, method calls. That’s just sending messages. In fact, you can replace any method call foo.bar with foo.send(:bar), like so²:

  Foo = Class.send(:new) do
    self.send(:define_method, :bar) do
      self.send(:puts, "Zoo!")
    end
  end

How much syntax can you remove like this? How far can Ruby be undressed? And can you come up with a macro system to put the clothes back on?

Some ingredients: Why list macros are cool, RubyToRuby.

¹ Actually, it’s not the same, since the define_method way creates a closure, so you can do like this

² Yes, I know I’m using method call syntax here. But this way I do expose the message-passing view on OO that Ruby has. If you want, you can replace it with send_message(object, method, *args), and assume Ruby defines send_message somewhere.

A DSL for making SQL-like DSLs

blog@matijs.net (matijs) — Sat, 14 Apr 2007 14:42:00 +0000

Setting the stage

Some time ago, I came across SQLDSL, a DSL for building SQL queries. The benefit of using a DSL over plain old string concatenation is that syntax is checked before the database server is hit. Unfortunately, SQLDSL does not deliver. It will happily accept

  q = Insert.into["frot"]["zop"]["blob"].values("kng").values["kgn"]

resulting in

  q.to_sql
  # => "insert into 'frot' (zop) (blob) values ('kng') values () (kgn)"

which is hardly acceptable SQL.

A metasolution

The problem is that each chained call operates on the same class, so the calls can be repeated, even when that’s not appropriate. Instead, each step in the building of the query should return an object of a different class, having only methods appropriate at that stage. Something like this:

  class Insert
    # [...]
    def [](*fields)
      return InsertIntoFields.new(@table, fields)
    end
  end

  class InsertIntoFields
    # [...]
    def values
      InsertIntoFieldsValuesPre.new(@table, @fields)
    end
  end

  # etc.

Of course, this quickly becomes tedious, with all the initialize methods having to be made, etc. Boring, boring. Let’s do some metaprogramming.

First, I need a quick way to create a class with a certain number of instance variables, that are set in the call to new(). That sounds like Struct, but the classes that creates have too many methods that would conflict with a DSL for SQL (like values()). So instead, I took a small, simplified part of Mauricio Fernandez alternative: SuperClass (specifically, I didn’t want any accessors for the fields, or named parameters):

  module SuperClass
    def self.new(*fields, &blk)
      k = Class.new do
    @defined_instance_variables = fields.clone
    class << self; attr_reader :defined_instance_variables end
    define_method(:initialize) do |*a|
      if fields.size != a.size
        raise ArgumentError, "wrong number of arguments (#{a.size} for #{fields.size})"
      else
        fields.each_with_index {|f,i| instance_variable_set("@#{f}", a[i])}
      end
    end
      end
      k.instance_eval &blk if blk
      k
    end
  end

(Annoyingly, there’s no way to dynamically create methods with arbitrary arity, without resorting to eval-ing a string.)

The heart of this metaprogramming is this module:

  module DSLChain
    def self.create(*fields, &blk)
      k = SuperClass.new(*fields)
      k.extend(DSLChain::Link)
      k.instance_eval &blk if blk
      k
    end
    module Link
      def add_step(func, field=nil)
    div = defined_instance_variables
    fields = div.clone
    fields << field unless field.nil?
    n = DSLChain.create(*fields)

    define_method func do |*a|
      vals = []
      fields.each do|f|
        if div.include?(f)
          vals << instance_variable_get("@#{f}")
        end
      end
      vals << a if a.size > 0
      n.new(*(vals))
    end
    n
      end
    end
  end

Stepper::Step#add_step(func, field) adds a method called func that creates an object of a new anonymous class, optionally adding a field called field. It returns the new anonymous class, so theses calls can be chained.

This means we can do the following:

  # Insert ...
  Insert = DSLChain.create(:table) do
    # Insert.into creates an instance of this class.
    def self.into(table)
      self.new(table)
    end

    # Insert.into[fields].values[values]
    self.
      add_step(:[], :fields).
      add_step(:values).
      add_step(:[], :values).class_eval do
    def to_sql
      cn = @table.column_names
      @fields.each {|f| cn.include?(f) or raise "Invalid field: #{f}"}
      raise "Incorrect number of values" unless @values.size == @fields.size
      res = "insert into #{@table.to_s.downcase} ("
      res << @fields.join(", ")
      res << ") values ("
      res << @values.map{|v| v.to_sql}.join(", ")
      res << ")"
      res
    end
      end
  end

In the middle there, each call to add_step(func, field) creates a new intermediate anonymous class that results from a call to func on the previous one. The result is that after creating an Insert object with Insert.into, the call sequence is forced to be

  Insert.into(SomeTable)["some", "column", "names"].
    values["these", "are", "values"].to_sql

Aside One: For this to work, Insert.into takes some object that has a method column_names, like ActiveRecord objects. I’m also assuming appropriate to_sql methods to be defined on String and Numeric)

Aside Two: I changed the syntax a little bit from SQLDSL, since I like it better that way.

The original example then results in:

  Insert.into(Frob)["id"]["zonq"].values("kng").values["kgn"]
  # => undefined method `[]' for #<#<Class:0x30051330>:0x30050220 @fields=["id"], @table=Frob> (NoMethodError)

More examples

If you want two options, you can do this:

  Sample2 = DSLChain.create(:one) do
    k = self.add_step(:foo, :two)
    k.add_step(:bar, :three).class_eval do
      def to_s
        "A bar: #{@one}, #{@two}, #{@three}"
      end
    end
    k.add_step(:baz, :four).class_eval do
      def to_s
        "A baz: #{@one}, #{@two}, #{@four}"
      end
    end
  end

  Sample2.new("one").foo("two").bar("three").to_s
  # => A bar: one, two, three
  Sample2.new("one").foo("two").baz("four").to_s
  # => A baz: one, two, four

Where to from here?

This was mainly a proof-of-concept, of course. There is now a DSL to make DSLs. I haven’t even begun to create the DSL for the select statement, and insert is far from complete. Doing the conditions of the where clause is yet another matter, although ez_where could prove useful for that.

On the other hand, I may not get round to adding all those parts. The metaprogramming was the best part, anyway.

On the gripping hand, wouldn’t it be nicer to have a DSL that actually looks like Ruby’s array operations, such as grep and map? That would be so much more beautiful.

I Want Cells-GTK for Ruby

blog@matijs.net (matijs) — Mon, 22 Jan 2007 13:21:00 +0000

For some applications, a spreadsheet is the perfect development environment. The UI is a no-brainer, while the relations between the different values is clearly visible, and changes are automatically propagated from what could be called properties to derived values.

The problem is, of course, that you’re missing out on the features a programming language could offer. Macros are basically a dead end, unless you like to solve user issues like ‘It doesn’t work because I disabled all macros.’

What I want is something that gives me this easy linking within a model and between model and UI, but from withing Ruby. It is my prefered solution to the Gnome on Rails problem.

Cells for Common Lisp promises to take care of the automatic propagation and dependencies between cells:

Cells is a mature, stable extension to CLOS that allows you to create classes, the instances of which have slots whose values are determined by a formula. Think of the slots as cells in a spreadsheet (get it?), and you’ve got the right idea. You can use any arbitrary Common Lisp expression to specify the value of a cell. The Cells system takes care of tracking dependencies among cells, and propagating values.

That seems to take care of the automatic updating of derived values. The second part is the no-brain-UI. What’s needed for that is a dead-simple way to link settable values to input widgets (text boxes, spin buttons, etc.), and to link derived cell values to labels. By dead-simple I mean that it should be done in at most one line per widget/value pair.

It seems for that part, the solution would be to use cells-gtk:

Cells transparently link GUI elements with each other and the application model to greatly simplify development of rich interfaces. Cells also automate how Lisp GUI instances drive their GTK+ counterparts.

Sounds great!

The problem (for me at least) is that this is all in Lisp, and I don’t know Lisp yet. So, I want this, but in Ruby (since that’s the language I like to use most right now). Some basic ingredients are already there: We can use blocks as formulas for the derived values, and there’s the Observable module. Also, Ruby has bindings for Gtk+.

I have some more wishes, but they’re mostly about Gtk+, so I leave those till later.

Skipping Python for Ruby

blog@matijs.net (matijs) — Thu, 18 Jan 2007 18:59:00 +0000

Without an e writes:

Well, ruby just isn’t that much better than python. If I’m going to relearn everything, why would I bother with ruby? Why not just jump straight to lisp?

I can really appreciate this argument, since it resonates with my reasons for not learning Python: I knew Perl, and was doing most of my programming in it, making nicely structured, readable, object-oriented programs. To me, Python didn’t seem like such a big step forward: It’s like a Perl with enforced readability.

And then came Ruby.

My introduction to Ruby was not through Rails, but through reading the online version of the Pickaxe Book. After reading the first chapter, I was sold. Here was a language that truly embraced object-orientation, and gave access to all kinds of interesting abstractions that I had only vaguely heard of (such as coroutines). There also was a pleasant lack of boilerplate.

So to me, Ruby is that much better than Perl, whereas Python is not. I wouldn’t know if I agree that Ruby is not that much better than Python, but at least I can understand the argument. Ruby is certainly no Lisp, although it comes close.

So what’s next? Lisp’s features certainly look appealing, giving basically the pinnacle of power of abstraction, in exchange for slightly unappealing syntax. I believe the syntax can be overcome, so my next language to learn may well be a Lisp. Which Lisp is still an open question. On the other hand, there are interesting languages like Erlang, ML and the like.

[Incidentally, Without an e is the creator of Scarlet Lambda, which is roughly a web framework written in, or at least used with, a functional style of programming in Python, with a Lisp-like syntax. Wow.]