CRPL Stack Question

Started by thepenguin, February 15, 2014, 06:51:13 PM

Previous topic - Next topic

thepenguin

How does the CRPL Stack work?  I know that C++ has some great ways to create stacks, but those seem to be bounded to just one type of element  (For example, std::vector<int>, std::vector<string>, and std::vector<VECTOR3D>).  Yet, the CRPL stack has ints, strings, floating-point numbers, and even lists.  I want to implement a similar stack-based language in C++ for an unrelated application, but I am not able to figure out how to deal with the datatypes.

Any help figuring out how this magic works would be awesome!  I've tried a couple things without great success.
We have become the creeper...

Michionlion

std::vector<object> and a form of instanceof.  Or a 'StackObject' interface/object to inherit from.
"Remember kids, the only difference between science and messing around is writing it down."
                                                                                                                         - Adam Savage

My website
My CW1, and CW2 maps!

knucracker

CRPL rides on top of mono (.net opensource) and its interpreter is written in C#.  That said, you can still apply the technique below in C++.  You just need to carefully consider object lifetime management.

Basically you need  a vector<Data>, where Data is a struct or class that will hold your fundamental data types.  "Data" becomes the class that represents your data type in your language.  It is a wrapper around any  int, float, string, vector, or anything else you want it to hold.

So this means creating a "Data" container object to hold any primitive value.   I also add methods to Data that will compare one Data to another for equality, as well as return Data as any primitive type.  So there are GetInt(), GetFloat(), GetList()... functions.

As an example you can create a Data that holds and int, say Data d = new Data(42).
Now you can call d.GetString() and get back "42".  Or you can create Data d2 = new Data("3.14"), then call d2.GetFloat() and get back 3.14.

In CRPL, "Data" is what is held by the stack, by the variable heap, is returned from all functions, and is what wraps every constant the CRPL programmer types in.


Grauniad

Quote from: virgilw on February 15, 2014, 08:33:50 PM
... .<Data>, ... Data...  "Data" ... data ... "Data" ... Data ... Data ... Data ... Data ... Data ... Data...
... Data... Data... "Data" .


Did someone call?



Somehow I think using a person's name 14 times implies a call to Data? :P
A goodnight to all and to all a good night - Goodnight Moon

thepenguin

Quote from: virgilw on February 15, 2014, 08:33:50 PM
CRPL rides on top of mono (.net opensource) and its interpreter is written in C#.  That said, you can still apply the technique below in C++.  You just need to carefully consider object lifetime management.

Basically you need  a vector<Data>, where Data is a struct or class that will hold your fundamental data types.  "Data" becomes the class that represents your data type in your language.  It is a wrapper around any  int, float, string, vector, or anything else you want it to hold.

So this means creating a "Data" container object to hold any primitive value.   I also add methods to Data that will compare one Data to another for equality, as well as return Data as any primitive type.  So there are GetInt(), GetFloat(), GetList()... functions.

As an example you can create a Data that holds and int, say Data d = new Data(42).
Now you can call d.GetString() and get back "42".  Or you can create Data d2 = new Data("3.14"), then call d2.GetFloat() and get back 3.14.

In CRPL, "Data" is what is held by the stack, by the variable heap, is returned from all functions, and is what wraps every constant the CRPL programmer types in.
Okay, I guess I was hoping for something better than all those objects/classes/structs.
I do get it in that it makes sanity checking quite easy (poly-morphism want a cracker-morphism?), but I was hoping for the proverbial clouds to open and for an more memory-efficient solution to appear.
We have become the creeper...