Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday May 21, 2008
09:06 AM

Suitably Impressed with Ruby

[ #36484 ]

Yes, I know you can do this with Perl and overloading, but in Ruby, this is built in to the language. First, here's some Prolog:

mortal(X) :- man(:X).
man(socrates).

The to find out who is mortal:

? - mortal(WHO).

Someone has created a tiny Prolog in Ruby and to do the same query above, you do this:

mortal      = Pred.new(:mortal)
mortal_goal = Goal.new(mortal, [:X])

man         = Pred.new(:man)
man_goal    = Goal.new(man, [:X])
mortal_goal.fact(man_goal)
Goal.new(man, ['socrates']).fact
query Goal.new(mortal, [:Y])

(Note: That took me a while to figure it out. Aside from dabbling, I've never really used Ruby before today. Now I'm trying to port a predicate logic engine. I'm not too bright.)

Of course, that's pretty painful. So they've redefined bits of Ruby (as they apply to their objects, so it's not global) and now they can issue the query like this:

mortal[:X] <<= man[:X]
man["socrates"].fact
query mortal[:Y]

That's pretty impressive. I wish Perl has symbols. Right now, I'm trying to fake it with an object, but it's not as easy.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Seems kind of nutty to write a bunch of stuff that approximates Prolog when the Prolog is designed for what it does and reads more easily.

    Makes me wonder if some sort of Inline::Prolog isn't a better way to go. Parse a bunch of Prolog, interpret it and spit out a "query" sub.

    --dagolden
    • Already I've talked to a couple of folks who thought they could do that. Then they saw what it entailed. Apparently it's much harder than it sounds. I wouldn't know.

      That being said, I want to be able to use real Perl data structures with predicate logic. That gives me the ability to open up doors that Prolog has a lot of difficulty with. It also means that AI::Prolog also won't cut it.

      This solution is fairly small, fast, and doesn't require an interpreter for another language.

  • IIRC, ruby symbols are just constant strings quoted by a leading ':'. So, please explain how my understanding is wrong or how perl's string quoting is leaving you wanting.
    • Symbols are extremely lightweight and fast. Also, you can check for one with Symbol === some_var. In Perl, if you're using a quoted string, you don't get that, so you pretty much have to bless a reference to get the distinction. At that point, there's enough overhead that it's just not worth the point.

      • So, you just want the optimization of comparing a constant memory address ala \&::X?

            use warnings; use strict;
            my $q = \&::thing; my $v = \&::thing;
            warn $q == $v;
            warn $q == \&::thing;
            package bar;
            warn $q == \&::thing;

        Thus, perl has symbols. Yeah, so our sigils are a bit hairier, but that makes us cuddly.

        (Aside: if you want to play the package game, you can leave out the colons, but IIRC ruby only has
        • Part of the point of a symbol appears to be that you can easily recognize it as a symbol. Not so with the references above. You can't distinguish those from any other types that easily unless you bless them into their own class. Symbols in Ruby (someone stop me if I'm talking rubbish!) aren't just some funky constant. They're a way of making an extremely lightweight, constant identifier that is easy to pass around. It seems like a variable with no value. Sometimes you just want a guaranteed identifier

  • As an aside, Perl6 also doesn't seem to support symbols a la Ruby. But perhaps one can use the 36 radix form of number literal e.g. :36, :36. It's supposed to be ultra-fast cause it's nothing but number. But the caveats are: it's case-insensitive, you can insert "_" and 0 prefix without changing its value. But I think it's good enough and also rather cute.
    • Sorry, the formatter ate my symbols. Pretend [] are the correct braces: :36[MySymbol1], :36[Your_Symbol2].

      The "_"-insensitiveness can (and should) be viewed as a feature :-)
  • ... is it fast enough to be useful?

    As we discovered when I tried to use AI::Prolog in a "real application" last year, it's one thing to be able to do the work, it's another thing entirely to be able to do it fast enough to be actually useful.

    Ruby is already famous for being slow because of all the layered abstraction, is their implementation of that logic stuff fast enough to implement, for example, a 100 guest "dinner party problem" solution in a reasonable time?

    • My reply became long enough that I have a dedicated post about benchmarking the Ruby and Perl implementations [perl.org]. Short answer, it's a hell of a lot faster, but depending on your constraints, you still would have problems doing the "100 guest" dinner party.

    • I didn't recognize the phrase, so I googled for it and got too much. If I tried to add Prolog to the query all I got was your post.

      So I have to ask. What is the problem?
      • I don't know if there is an exact problem, per se, but I assume it's like any other scheduling problem. You have lots of guests and ...

        • Bob has a restraining order against Alice.
        • Alice has a crush on Tim.
        • Tim has a crush on Bob.
        • William is violently homophobic.
        • Sarah is a vegetarian.
        • ... and so on.

        And you have to find seating and dinner arrangements which are suitable for everyone. It is, as you know, a potentially very difficult problem.