An ‘exists’ keyword in the DSL would represent an existential quantifier that checked for the existence of a a particular pattern in working memory. The rule would then be satisfied only once if that pattern is matched. This is as opposed to firing ‘for each’ by default.

original LH ticket

This ticket has 0 attachment(s).

Create external DSL. Original DSL’s are internal and written in Ruby. To be able to store rules externally an external DSL is needed. This would allow for a lot of new functionality to be created, i.e. a BRMS.

original LH ticket

This ticket has 0 attachment(s).

Negated patterns (those that use the “not” conditional element) are currently not allowed as the first pattern in a list. This can be resolved with an “initial-fact” design like CLIPS.

original LH ticket

This ticket has 0 attachment(s).

Looks like there are some issues with Ruby 1.9.2. Apparently much faster. Is there any work being done on it?

owain@../dev/ruleby/examples$ rvm 1.9.2-head@rete
owain@../dev/ruleby/examples$ ruby hello.rb 
/Users/owain/dev/ruleby/lib/dsl/ferrari.rb:303: warning: undefining `object_id' may cause serious problems
/Users/owain/dev/ruleby/lib/dsl/steel.rb:160: warning: undefining `object_id' may cause serious problems
Hello World
Goodbye world
owain@../dev/ruleby/examples$ rvm 1.8.7-head@rete
owain@../dev/ruleby/examples$ ruby hello.rb 
Hello World
Goodbye world
owain@../dev/ruleby/examples$ 

I have watched the older presentations for ruleby and am wondering when a presentation for the new dsl will be available, or even a target release date?

The Fact.token value is not really necessary any more. The assert_fact method should have a retract_fact sibling in every occurrence.

original LH ticket

This ticket has 0 attachment(s).

Rake does not like the letters in the version in the Rakefile.
git clone http://github.com/codeaspects/ruleby.git
cd ruleby
rake -T
(in /Users/ric/code/ruleby)
rake aborted!
Malformed version number string 0.7-SNAPSHOT
/Users/ric/code/ruleby/Rakefile:17

Removing the -SNAPSHOT fixes the rake.

There is an "engine" method defined on ActiveRecord::Relation and under certain circumstances this will conflict with the "engine" method that is defined on Object by the inclusion of "include Ruleby" without a surrounding class.

Also, any word on updating this gem?

Currently, the HashedNode class traps NoMethodError. This is necessary for patterns that use the :is_a? quantifier or do not specify a type. But if a type is explicitly specified, and the pattern contains a method that does not exist, then the Engine should throw the NoMethodError.

original LH ticket

This ticket has 0 attachment(s).

Running the example of new rule language does not work.
ruby fibonacci_example3.rb
./../lib/core/nodes.rb:32:in assert_rule': undefined methodpattern' for #Array:0x100349e40 (NoMethodError)
from ./../lib/core/engine.rb:227:in assert_rule' from fibonacci_example3.rb:73 from ./../lib/ruleby.rb:19:inengine'
from fibonacci_example3.rb:71

I ran into an issue when using Rails with conditional associations and Ruleby. Some background, I have two models, a Store and a Batch. Store has many batches, and has one current batch, which is simply a conditional association where the batch has a state of "open."

Here's my stack trace when I try to access the current_batch association.

ruby-1.9.2-p290 :002 > Store.first.current_batch
SyntaxError: (eval):1: syntax error, unexpected tSTRING_BEG
Proc.new { || "batches"."workflow_state" = 'open' }
                         ^
(eval):1: syntax error, unexpected '=', expecting '}'
Proc.new { || "batches"."workflow_state" = 'open' }
                                          ^
  from gems/ruleby-0.8/lib/ruleby.rb:55:in `eval'
  from gems/ruleby-0.8/lib/ruleby.rb:55:in `to_proc'
  from gems/activerecord-3.0.9/lib/active_record/base.rb:1753:in `interpolate_sanitized_sql'
  from gems/activerecord-3.0.9/lib/active_record/associations/association_proxy.rb:165:in `interpolate_sanitized_sql'
  from gems/activerecord-3.0.9/lib/active_record/associations/association_proxy.rb:105:in `conditions'
  from gems/activerecord-3.0.9/lib/active_record/associations/has_one_association.rb:102:in `construct_sql'
  from gems/activerecord-3.0.9/lib/active_record/associations/has_one_association.rb:7:in `initialize'
  from gems/activerecord-3.0.9/lib/active_record/associations.rb:1441:in `new'
  from gems/activerecord-3.0.9/lib/active_record/associations.rb:1441:in `block in association_accessor_methods'
  from (irb):2
  from gems/railties-3.0.9/lib/rails/commands/console.rb:44:in `start'
  from gems/railties-3.0.9/lib/rails/commands/console.rb:8:in `start'
  from gems/railties-3.0.9/lib/rails/commands.rb:23:in `<top (required)>'
  from script/rails:6:in `require'
  from script/rails:6:in `<main>'

Rails does some magic on the arguments it gets passed when defining a conditional association, here's the code I believe is causing issues with Ruleby.

def interpolate_sanitized_sql(sanitized, record = nil, sanitize_klass = self.class)
  if sanitized =~ /\#\{.*\}/
    ActiveSupport::Deprecation.warn(
      'String-based interpolation of association conditions is deprecated. Please use a ' \
      'proc instead. So, for example, has_many :older_friends, :conditions => \'age > #{age}\' ' \
      'should be changed to has_many :older_friends, :conditions => proc { "age > #{age}" }.'
    )
    instance_eval("%@#{sanitized.gsub('@', '\@')}@", __FILE__, __LINE__)
  elsif sanitized.respond_to?(:to_proc)
    sanitize_klass.send(:sanitize_sql, instance_exec(record, &sanitized))
  else
    sanitized
  end
end

It asks the object being passed in if it responds to #to_proc. Under normal circumstances, String would not respond to #to_proc so there would be nothing happening here and it would just return the generated and sanitized SQL. But, since Ruleby provides a String#to_proc method, Rails runs the proc and Ruleby just gets really confused at the String it's working with.

I'm still working on a workaround/patch, but I wanted to see if anyone here had any ideas. I'll update this with my findings.

The bridge node currently has to make an awkward check for the head atom. This needs to be changed so that the head atom is a special case.

original LH ticket

This ticket has 0 attachment(s).

Currently, Ruleby does not allow for parameters in method names. For example, the following is not allowed:

[m.get(:name) == ’Joe’]

This needs to be accepted in all syntaxes. Other cases where this is need include:

[m[:name] == ’Joe’]

The Atoms and Nodes are already prepared to accept the arguments. The only area of development needed is in the DSLs.

original LH ticket

This ticket has 0 attachment(s).

The LHS of a rule should be able to chain methods. This would look something like:

rule [:m, m.foo.bar.value = 'hello'] do |v|
...
end

The following should be allowed in a rule definition:

rule :foobar, [MyClass, m.name.in("joe", "jim", "bob")] ...

original LH ticket

This ticket has 0 attachment(s).

These two rules should produce the same results, but they don't:

rule :no_other_exisitng_actions, 
  [CurrentPage, :cp],
  [Link, :l],
  [:not, LowerPage],
  [:not, HigherPage] do |v|
    puts "worked"
end

rule :no_other_exisitng_actions, 
  [CurrentPage, :cp],
  [:not, LowerPage],
  [:not, HigherPage],
  [Link, :l] do |v|
    puts "worked"
end

Thanks to Jason for reporting this:
http://groups.google.com/group/ruleby/browse_thread/thread/7a3774ffaa4de6cd

Investigate RuleML as a potential rule language for Ruleby. See http://www.ruleml.org .

I was originally going to use it, but opted instead to use an internal DSL. Now we are working on an external DSL and I think we should revisit RuleML.

original LH ticket

This ticket has 0 attachment(s).

The MatchResult class has some unneeded attributes and extra code. We need to clean this out.

original LH ticket

This ticket has 0 attachment(s).

Add a method to the Engine class that will allow the caller to enable some kind of tracing. This tracing will record what rules have been fired.

original LH ticket

This ticket has 0 attachment(s).

In this simple example, the condition clause doesn't seem to be able to reference a bound variable from a previous part of the clause:

# 
# Example of situation where bound variable is not available to the condition clause.
#

$LOAD_PATH << File.join(File.dirname(__FILE__), '../lib/')
require 'ruleby'

include Ruleby

class Q
  def initialize(status,message,value)
    @status = status
    @message = message
    @value = value
  end
  attr :status, true
  attr :message, true
  attr :value, true
end

class HelloWorldRulebook < Rulebook
  def rules
=begin
    # original rule
    rule [Q, :p, {m.value=>:pv}, m.status == :HELLO],
         [Q, :q, m.status == :GOODBYE,m.value == b(:pv)]  do |v|
      puts v[:p].message + " " +v[:q].message
    end
=end
    # the next two rules should be equivalent to the original rule but are not.
    rule [Q, :p, {m.value=>:pv}, m.status == :HELLO],
         [Q, :q, m.status == :GOODBYE,m.value(&condition{|c| c == b(:pv)})]  do |v|
      puts v[:p].message + " " +v[:q].message
    end
    rule [Q, :p, {m.value=>:pv}, m.status == :HELLO],
         [Q, :q, m.status == :GOODBYE,m.value(b(:pv),&condition{|v,pv| v == pv})]  do |v|
      puts v[:p].message + " " +v[:q].message
    end
  
  end
end

engine :engine do |e|
  r=HelloWorldRulebook.new(e)
  r.rules
  e.assert Q.new(:HELLO, 'Hello',1)
  e.assert Q.new(:GOODBYE, 'World',1)
  e.match
end;