From: paytonrules <paytonrules@...>
Date: 2006-09-14T03:40:45+09:00
Subject: Re: Newbie Question: - Parse my commands...


Logan Capaldo wrote:
> On Wed, Sep 13, 2006 at 08:10:35AM +0900, Vidar Hokstad wrote:
> >
> > paytonrules wrote:
> >
> > > The first step, which I'm doing now, is to take our executable program
> > > and break the parsing engine into a DLL.  That's easy.  I can then
> > > create a quick ruby program so I could do this:
> > >
> > > irb
> > > load 'rubyProg'
> > >
> > > parse ObjectName.Make(param1, param2, param3, param4)
> > >
> > >
> > > The rubyProg could work this way - but I'm pretty sure I can go one
> > > step farther with ruby and just type:
> > >
> > > ObjectName.Make(param1, param2, param3, param4)
> > >
> > > through ruby extensions.  The question is - how do I have the
> > > interpreter pass on any code to the parser ruby can't handle it?
> >
> > method_missing() can be used for this to some extent. It depends on how
> > exact you want the syntax. If you can get away with changing the object
> > names so that they start with a lowercase letter it's cleaner. In Ruby,
> > a capital first letter of a name indicates a constant, which means you
> > need some extra uglyness to handle that.
> >
> > With a lowercase first letter in your object names you can do:
> >
> > class MissingProxy
> >   def initialize ob
> >     @ob = ob
> >   end
> >
> >   def method_missing(sym,*args)
> >     # Call your script processor here.
> >     puts "PROCESS: #{@ob.to_s}.#{sym.to_s}(#{args.join(',')})"
> >   end
> > end
> >
> > def method_missing(sym,*args)
> >   MissingProxy.new(sym)
> > end
> >
> > myObject.Make('test',123)
> >
> >
> > If, on the other hand you don't want to rewrite anything, you can wrap
> > the statements like this:
> >
> > begin
> >   MyObject.Make('test',123)
> > rescue NameError => n
> >   eval("#{n.name} = MissingProxy.new(:#{n.name})")
> >   retry
> > end
> To handle the MyObject case, you needs simply define const_missing
> instead of method_missing, no need to rescue name error.
> >
> > I'd consider both of these methods fairly ugly. They make trapping
> > errors in your Ruby code tricky, as any misspelled object/class names
> > will trigger your script interpreter instead of giving an error, but it
> > does give a lot of flexibility.
> >
> Agreed.

> > I'd consider both of these methods fairly ugly. They make trapping
> > errors in your Ruby code tricky, as any misspelled object/class names
> > will trigger your script interpreter instead of giving an error, but it
> > does give a lot of flexibility.

I agree - but the C++ parser is allowed to return errors no?

To put it another way - lets assume I do the const_missing.  Parse will
return errors - couldn't I use the parse errors to deterimine "is this
a parse error or is this a Ruby error"?

I realize I'm not explaining myself well - perhaps because I'm really
just experiementing with this to make sure I've got a good idea.  We've
already got an old parser executable that parses script files.  I just
want to use irb and ruby to glue this and make a statement-by-statement
runtime interpreter.  Would a better design be to include the irb in my
application and work the other way around?