Action-oriented vs Object-oriented 
Author Message
 Action-oriented vs Object-oriented

Hi,

I'm trying to decide how to design the Tcl extension I'm working on.

I have generated a parser using flex/bison. I created a parse tree in C
using
struct's and union's. These contain enum's, int's, char*'s, ...

Now, the problem is, I need the Tcl to be able to access this data from
the Tcl side. Since I do not know very much about Tcl, I'm wondering
what a good design decision is, Action oriented or Object oriented.

I'm assuming that with Action oriented, I have a function like
set val [new_parse_command $parse_data] and that will set val to some
string like "parse_data1" that represents the parse tree in C that I
have. Then I would have to implement commands to access that data and
returns things like strings, int's or list's.

How would the Object-oriented approach work? is it better for this
case?

Thanks,
Bob Rossi



Sun, 01 Jul 2007 02:58:17 GMT  
 Action-oriented vs Object-oriented

Quote:

> I'm trying to decide how to design the Tcl extension I'm working on.
> I have generated a parser using flex/bison. I created a parse tree
> in C using struct's and union's. These contain enum's, int's,
> char*'s, ...

What's the overall goal of this, the view from 10000 meters, as it were.

Quote:
> Now, the problem is, I need the Tcl to be able to access this data
> from the Tcl side. Since I do not know very much about Tcl, I'm
> wondering what a good design decision is, Action oriented or Object
> oriented.

"action oriented" means that you have a series of commands that
operate on the data, like files.

"object oriented" means that you create new commands which then give
you information about themselves.  The Tk toolkit is a good example of
this:

set b [button .b -text BBBBBBBBB]

You now have a command .b that can do things itself (rather than have
other commands act on it).

Quote:
> I'm assuming that with Action oriented, I have a function like set
> val [new_parse_command $parse_data] and that will set val to some
> string like "parse_data1" that represents the parse tree in C that I
> have. Then I would have to implement commands to access that data
> and returns things like strings, int's or list's.

Right.

Quote:
> How would the Object-oriented approach work? is it better for this
> case?

You would do something like this:

set parseresult [parse $parsedata]

puts [$parseresult depth]
puts [$parseresult node .... ]

And then free it somehow when you're done with it.

It's not really "object oriented" like python or Smalltalk, but it
works well and is very direct.  It's a good technique for when you
have a 'thing' that is going to be around for a while.  If it's
transient, you probably want the 'action oriented' style.

Does that help?
--
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/



Sun, 01 Jul 2007 03:58:13 GMT  
 Action-oriented vs Object-oriented
Yes.

Thank you



Sun, 01 Jul 2007 04:46:38 GMT  
 Action-oriented vs Object-oriented


Quote:
> Hi,

> I'm trying to decide how to design the Tcl extension I'm working on.

> I have generated a parser using flex/bison. I created a parse tree in C
> using
> struct's and union's. These contain enum's, int's, char*'s, ...

> Now, the problem is, I need the Tcl to be able to access this data from
> the Tcl side. Since I do not know very much about Tcl, I'm wondering
> what a good design decision is, Action oriented or Object oriented.

Can you put the whole data into one big associative array?
That's what I'd try first.

Lots of Greetings!
Volker



Sun, 01 Jul 2007 05:44:25 GMT  
 Action-oriented vs Object-oriented

Quote:

> Hi,

> I'm trying to decide how to design the Tcl extension I'm working on.

> I have generated a parser using flex/bison. I created a parse tree in C
> using
> struct's and union's. These contain enum's, int's, char*'s, ...

> Now, the problem is, I need the Tcl to be able to access this data from
> the Tcl side. Since I do not know very much about Tcl, I'm wondering
> what a good design decision is, Action oriented or Object oriented.

[snip]

This may not be quite the direction in which you were headed, but one
approach is to avoid writing any more of an extension than you have to.
When I can, I try to do my parsers in "yeti" so that I can keep the entire
processing on the Tcl side (so to speak). When that is not possible or
desirable, I write a program using flex/bison to build the parse tree.
After parsing the input, that program walks the parse tree and emits
(usually on the standard output) a Tcl script that builds the parse tree
using commands from "::struct::tree" from Tcllib. It is then a relatively
simple matter to "exec" the program, snarf up the output and "eval" it to
build the parse tree as a "::struct::tree" (which happens to be an "object
oriented" package). This is particularly nice since as of Version 2.0 of
"::struct::tree" one can "serialize" the tree if it needs to be passed
around as a value or needs to persist until some other time.

Andrew



Sun, 01 Jul 2007 13:00:19 GMT  
 Action-oriented vs Object-oriented
You can always try to automatically create
the extension through swig (http://www.swig.org).
This free tool specialises into turning C/C++
"libraries" into packages for various languages
(Tcl included). If you use swig, the tcl API
will look "object-oriented": Each structure/class
will be converted into a token, having a
set of "methods" for accesing the various
functions/properties. It will work similar
to tk widgets...

For me there is no other approach if you have
C/C++ code and you want to expose to Tcl. If you
go in writting the wrapper manually, very soon you will
see that its too difficult & error prone to maintain the
wrapper as you extend the C API. I know it from first hand :-)

George


Quote:
> Hi,

> I'm trying to decide how to design the Tcl extension I'm working on.

> I have generated a parser using flex/bison. I created a parse tree in C
> using
> struct's and union's. These contain enum's, int's, char*'s, ...

> Now, the problem is, I need the Tcl to be able to access this data from
> the Tcl side. Since I do not know very much about Tcl, I'm wondering
> what a good design decision is, Action oriented or Object oriented.

> I'm assuming that with Action oriented, I have a function like
> set val [new_parse_command $parse_data] and that will set val to some
> string like "parse_data1" that represents the parse tree in C that I
> have. Then I would have to implement commands to access that data and
> returns things like strings, int's or list's.

> How would the Object-oriented approach work? is it better for this
> case?

> Thanks,
> Bob Rossi



Sun, 01 Jul 2007 18:27:18 GMT  
 Action-oriented vs Object-oriented


:I have generated a parser using flex/bison. I created a parse tree in C
:using
:struct's and union's. These contain enum's, int's, char*'s, ...

:How would the Object-oriented approach work?

Well, I'd presume that you would have a command that would create a
parse tree object, and that the object would have a series of subcommands
that acted against it.

parsetree MyFirst -file input.txt

$MyFirst setNoun dog
$MyFirst setVerb barks

or whatever - the methods of a parsetree would be determined by what
you wanted to do with the parse tree.

--
<URL: http://wiki.tcl.tk/> MP3 ID tag repair < http://www.fixtunes.com/?C=17038 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Sun, 01 Jul 2007 21:53:39 GMT  
 Action-oriented vs Object-oriented

Quote:

>Hi,

>I'm trying to decide how to design the Tcl extension I'm working on.

>I have generated a parser using flex/bison. I created a parse tree in C
>using
>struct's and union's. These contain enum's, int's, char*'s, ...

>Now, the problem is, I need the Tcl to be able to access this data from
>the Tcl side. Since I do not know very much about Tcl, I'm wondering
>what a good design decision is, Action oriented or Object oriented.

>I'm assuming that with Action oriented, I have a function like
>set val [new_parse_command $parse_data] and that will set val to some
>string like "parse_data1" that represents the parse tree in C that I
>have. Then I would have to implement commands to access that data and
>returns things like strings, int's or list's.

>How would the Object-oriented approach work? is it better for this
>case?

                        .
                        .
                        .
There have been several valuable follow-ups to these questions.
My own instinct is that, as Mr. Rossi becomes familiar with Tcl,
it might turn out that his C-coded parser falls away; it adds no
value, and only complicates maintenance.  Unless the language
he's parsing is unusual, he'll find it's easier to parse in Tcl-
native ways, than with flex and bison.

At that point, the distinction between "action-oriented" and
"object-oriented" will assume quite a different character.



Wed, 04 Jul 2007 22:08:04 GMT  
 Action-oriented vs Object-oriented
Hi,

At this point, I am still trying to figure out how to best represent my
parse tree in Tcl. There have been several options I have been told
about here, they seem to be,
* represent the data in lists or (one big associative array)
* use swig to generate the interface
* right the interface manually
* create the parse tree using flex/bison and generate a parse tree
in Tcl.

All of these options are worth looking at and hopefully I will come up
with a good working solution soon.
Thanks for the great info,
Bob Rossi



Thu, 05 Jul 2007 11:28:39 GMT  
 Action-oriented vs Object-oriented
Hi Andrew,

Could you explain in more detail how you generate a parse tree in Tcl?
This might currently be the best option that I have.

I basically am using flex/bison and I generate a parse tree.

After this I don't quite follow. Probably because I don't know Tcl very
well yet. I understand how to walk a parse_tree and output info, but
how does that get me to build a parse tree in Tcl? Do you have any
small examples of something you've done?

Thanks,
Bob Rossi



Thu, 05 Jul 2007 11:32:02 GMT  
 Action-oriented vs Object-oriented

Quote:

> Hi Andrew,

> Could you explain in more detail how you generate a parse tree in Tcl?
> This might currently be the best option that I have.

> I basically am using flex/bison and I generate a parse tree.

> After this I don't quite follow. Probably because I don't know Tcl very
> well yet. I understand how to walk a parse_tree and output info, but
> how does that get me to build a parse tree in Tcl? Do you have any
> small examples of something you've done?

> Thanks,
> Bob Rossi

Okay, I can be a little more concrete with the usual caveat that the code
examples are written off the top of my head and haven't been tested.
However, the idea is one I have used successfully.

Assume a simple "C"-like assignment statement:

        a = b + 5 ;

When parsed, the resulting tree would look something like (in a simple
indented style debug print out):

root
   type = assign
      type = var, value = a
      type = plus
         type = var, value = b
         type = const, value = 5

Of course, there are many ways in which the parse tree could be represented.
One way is as a Tcl script that when executed would build the parse tree.
So for this example if we represented the parse tree using "::struct::tree"
from Tcllib, it might look like:

package require struct 2.1

::struct::tree ptree
ptree insert root end n1
ptree set n1 type assign
ptree insert n1 end n2
ptree set n2 type var
ptree set n2 value a
ptree insert n1 end n3
ptree set n3 type plus
ptree insert n3 end n4
ptree set n4 type var
ptree set n4 value b
ptree insert n3 end n5
ptree set n5 type const
ptree set n5 value 5

Now if this script is evaluated by an interpreter, it will build a tree that
contains all the information of the original language statement. Note that
the tree name, "ptree", and the node names, "nX", are essentially arbitrary
and indeed "::struct::tree" will compose them for you if you are willing to
use some variables to capture the result. Also note that we have attached
several key/value pairs to the nodes to hold the essential node
information.

So the technique I described previously uses a flex/bison parser program to
parse the input language statements and build an internal parse tree
structure. It is then a matter of augmenting the parser program to perform
what is essentially a depth first pre-order walk of the resulting parse
tree, emitting the necessary "::struct::tree" commands to build the parse
tree representation in Tcl.

Assuming that such a program is called "parser", that it accepts the name of
the input file as an argument, that the input is in a file named, "input",
and that it produces the Tcl script on its standard output, then the
following will "import" the tree into a Tcl script:

set pchan [open "| parser input" r]
eval [read $pchan]
close $pchan

That is we can import the parse tree into a script by forking a process at
the end of a pipe and evaluating the output of that process as a Tcl script
(if you don't mind a rather UNIX intepretation of what open "|" does). In
the end the "parser" program is one that reads a set of language statements
and "writes" the corresponding Tcl script that represents those language
statements. Also, any realistic Tcl script to evaluate the output of a
program will have to have better handling of errors than the three lines
above do.

All this being said, I still recommend the use of "yeti" (and its companion
"ylex") for smallish grammars. Yeti/ylex are to Tcl what bison/flex are to
"C" and for smaller grammars it is often just a lot easier to avoid
crossing the "C" to Tcl boundary. For big stuff, where there may be
ambiguity in the grammar or a need for more extensive error handling or
recovery, I have accomplished the transition from a bison/flex parsing
program into a Tcl script using these ideas.

Andrew Mangogna



Fri, 06 Jul 2007 08:01:31 GMT  
 Action-oriented vs Object-oriented
Andrew,

Thanks for the excellent follow up! I completly understand the
technique you are suggesting now. I am going to spend some time looking
into this approach. I really like the idea of populating a
::struct::tree data structure, since this seems to be a native Tcl
type. I assume people familiar with Tcl would probably appreciate using
this data structure more than my custom Tcl extension.
Thanks,
Bob Rossi



Fri, 06 Jul 2007 10:41:14 GMT  
 Action-oriented vs Object-oriented
Below is a small xotcl program for the presented
example for demonstration purposes. Every node in the
tree resembles an object with a certain type, depending
on the type, it has different instance variables
containing other objects or values.

best regards
-gustaf neumann
=================================================

package req XOTcl; namespace import ::xotcl::*

Class Assign -parameter {lvalue rvalue}
Class Expression -parameter {op left right}
Class Variable -parameter {name}
Class Constant -parameter {value}

Assign new  \
-lvalue [Variable new -name a] \
-rvalue [Expression new -op + \
-left [Variable new -name b] \
-right [Constant new -value 5] \
                ]



Fri, 06 Jul 2007 12:03:43 GMT  
 Action-oriented vs Object-oriented


Quote:
> Andrew,

> Thanks for the excellent follow up! I completly understand the
> technique you are suggesting now. I am going to spend some time looking
> into this approach. I really like the idea of populating a
> ::struct::tree data structure, since this seems to be a native Tcl
> type. I assume people familiar with Tcl would probably appreciate using
> this data structure more than my custom Tcl extension.
> Thanks,

It's an extension too.
OTOH, you can use arrays to map a tree too:
set Tree(ROOT,KIDS) [list assign1]
set Tree(assign1,TYPE) assignment
set Tree(assign1,KIDS) [list var1 expr1]
set Tree(var1,TYPE) variable
set Tree(var1,VAL) a
set Tree(expr1,TYPE) expression
set Tree(expr1,VAL) addition
set Tree(expr1,KIDS) [list var2 const1]
set Tree(var2,TYPE) var
set Tree(var2,VAL) b
set Tree(const1,TYPE) const
set Tree(const1,VAL) 5

Lots of Greetings!
Volker



Fri, 06 Jul 2007 19:35:44 GMT  
 Action-oriented vs Object-oriented

Quote:


> > Andrew,

> > Thanks for the excellent follow up! I completly understand the
> > technique you are suggesting now. I am going to spend some time looking
> > into this approach. I really like the idea of populating a
> > ::struct::tree data structure, since this seems to be a native Tcl
> > type. I assume people familiar with Tcl would probably appreciate using
> > this data structure more than my custom Tcl extension.
> > Thanks,
> It's an extension too.

struct::tree is not just any extension - it is part of the Tcl
standard library.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/



Fri, 06 Jul 2007 21:13:28 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

2. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

3. Compare object-oriented and function-oriented ....

4. object-oriented vs. functional

5. Visitor-Iterator (Re: object-oriented vs. functional)

6. object-oriented vs. functional

7. Transaction vs. Object Oriented

8. WAS: Re: Object-Oriented Reading List (now structured A&D vs OO)

9. object-oriented vs. functional

10. Object Oriented vs. Overloaded

11. Object Oriented vs. Overloaded

12. Traditional vs Oriented Objects Programming

 

 
Powered by phpBB® Forum Software