OOP: Am I doing it right ?

I want a data structure (say X) resembling a singly linked list, with a catch, that its nodes can be of of either of two types, just a value (atom) , or a X itself.
Is the following a right way to approach it ?

Code:

class s_expr;
class atom;
class slist;
s_expr* s_factory(const std::string& s);

class s_expr
{
     enum Type{atom,list} type;
protected:
     std::string symbol;
public:
     virtual s_expr eval(const s_expr& s);
};

class atom:public s_expr
{
public:
     s_expr eval(const s_expr& s){/*Returns a value grabbed from a lookup table*/};
};

class slist : public s_expr
{
     //Singly linked list implementation, with s_expr `s as nodes.
};

So why not std::list<std::list<std::list<int>>>?

Originally Posted by Elysia

So why not std::list<std::list<std::list<int>>>?

Because a list<int> containing a single int and a single int are significantly different for the purpose.
The first represents a function call with no arguments and the second, a variable or constant.

OK, so I'm just going to say:
Here we go again: what are you trying to solve?

Originally Posted by Elysia

OK, so I'm just going to say:
Here we go again: what are you trying to solve?

I'm thinking of rewriting my lisp interpreter ( https://github.com/manasij7479/minlisp ) as it was somewhat naive in design.
As for the exact thing, here it is:
S-expression - Wikipedia, the free encyclopedia

Well...

• s_expr probably should be an abstract base class.
• s_expr probably should have a virtual destructor.
• s_expr ideally should not know about atom and slist (why not name it s_list?), since the rule of thumb is that base classes should not need to know about derived classes.
• eval probably should return a (smart) pointer or reference to s_expr.

Actually, why does eval have a parameter? It is so that if the s_expr is an slist, the second part of the s_expr will be passed as an argument? If so, this means that eval for an atom ignores its argument, yet an argument is required. Perhaps eval actually should not take an argument, and thus there will be some other way to specify the second part of an slist.

Originally Posted by laserlight

Well...

• s_expr probably should be an abstract base class.
• s_expr probably should have a virtual destructor.
• s_expr ideally should not know about atom and slist (why not name it s_list?), since the rule of thumb is that base classes should not need to know about derived classes.
• eval probably should return a (smart) pointer or reference to s_expr.

Good ideas.

Actually, why does eval have a parameter? It is so that if the s_expr is an slist, the second part of the s_expr will be passed as an argument?

I was somewhat mistaken and forgot how I initially designed it , see next paragraph.

If so, this means that eval for an atom ignores its argument, yet an argument is required. Perhaps eval actually should not take an argument, and thus there will be some other way to specify the second part of an slist.

I didn't think about this, thanks for pointing it out.
I'll change eval not to take parameters.

Actually, that is how I did it last time around. (just found out from the code)
The list's cdr (all except the first) contains the second part of the s expression. The first part (another list) is stored as the definition of the function.
The two lists together resemble a tree like structure, when iterated together, giving a key-value pair.