PNF: Calling Method After Extending Object Causes Crash

[des000]

Im not on my computer now, but my phone. Forgive me. Im working on a language tool set. Im adding objects to it, like in C++.

When i call a method, after i publicly inherit from another class, i cant call an inherited method, without a crash. This only happens when i make an instance of the class.

Error is function not found. It happens in my ICLASSMETHODECALL instruction.

Im guessing that function_stack::find is broken?

You can see code at www.github.com/smileynet000/PNF

Also, example i used is in bin directory. Might need linux to run.

 

[des000]

Forgot to specify. The code that crashes, is in the language being defined, not C++, which it's written in. The error causing it, is in C++, as that's the language the program is written in. The file the instruction is in, is pnf.hpp, located in the source directory, and LINUX. It compiles under g++. Don't know if it would compile in Microsoft C++ or not, but it probably will with a few minor changes if any.

It is one of my controlled crashes. Only its not supposed to crash with that input, it's supposed to print "Hello World!" on the screen again. Thus far, I'm stumped. I've added some output for troubleshooting.

 

[des000]

I fixed a bug in the READ instruction. I'd broke it. Now it's working again. But it requires asking for the newest version in order for it to work though...

I'm going to continue adding some stuff to this release. I'm adding actual loops to the lower levels now.

I haven't decided yet, but I MAY, release without fixing this issue, and just have it be a known bug, that objects don't work. There's lots of features that will work, so it "could" be good.

 

[WhiteCube]

Why continue to use C++?

The PNF interpreter exists, the PNFASM assembler exists.

Why not write the PNFHA compiler, and all future programs, in PNFASM?

Or, write a simple version of the compiler in PNFASM, then use that to write the full version.

 

[des000]

Why continue to use C++?

The PNF interpreter exists, the PNFASM assembler exists.

Why not write the PNFHA compiler, and all future programs, in PNFASM?

Or, write a simple version of the compiler in PNFASM, then use that to write the full version.

I want to get to that point, and I'm close to having enough features to do so. To start with, when it's ready, my plan will be to keep the other source code, just in case, however, restart PNF in PNFHA.

To start with though, PNFHA needs to be updated first. I don't think it yet has all relevant features in PNF (and also PNFASM). I need to add those first.

Second, one other reason I'm close, but not yet doing it: Objects. C++ has the class, while mine is only beginning to get the class. I know of a way to kludge the C language, and consequently, the PNF language, if I first fix PNFHA. Unfortunately, it's more error prone. Structs cannot contain methods in my language either. They are not meant to. And they can't do inheritance. At the very least, it would work better if I could do those things first. It's pretty close.

Once I can do those things, and have an object or two in my languages, and maybe my feeling feature as well, I'll be ready to do it. Just not quite yet. First, I have a few bugs to finish before it's a good idea. By the way, my bugs would carry over to the language, so if READ doesn't work, it won't work when I try to use my language either. Like I said, pretty close though.

Eventually, I want to see about modifying gcc/g++, to be able to generate my language, when told to. Then, I have a choice of languages as well as PNFHA. However, some stuff, like PNFHA, are really difficult to write without a compiler compiler, which mine is not. I can get to the point where I write one of those too, but now is not when. By the way, for those, I can start to use biflex, though, which is something else I've written. I just haven't took the time to work on that yet, but I will.

It's a long way from ALL future things, but some I can use my language for, and more when I finish this process. When it's rewritten, possibly, as much as C++ and some of the ones that java can be used for.

 

[des000]

OK. I just got a new version of my interpreter working. Nope. It doesn't have objects yet. I HAVE to have objects, in order to write itself in itself.

But now, I find myself with a choice of implementation, that I never have had before. I had to get a newer version of my language ready and out, before I could do anything more, it needed a few more features. I just removed the classes from the language for this stable version, (see source code for how) and then added a few features, to produce this version of the language.

Now, what do you think, of the next way to implement my objects? Exactly what I'm doing, is the eventual goal. But in the meantime, I have 2 choices: Continue to implement objects at the interpreter level, which is really where they belong. Delay my end goal until I get the bug solved. Plan 2, would be I could implement objects in terms of structures and unions (they are mostly what they are in C). Then I could implement objects in terms of that, in the higher levels. As long as I have objects, somehow, I'm OK. I don't have to implement them at the lower level in order to rewrite the language. I only need them to work somewhere.

In my newly implemented (or reimplemented) language, once it's feature complete, I still need to add objects to the interpreter. However, I could delay it like that, if I so choose. By the way, never am I deleting the origional C++ code version. I just will have another version too. Why? Well, you never know when I might need to extend or modify the origional one. So anyway, which one sounds like the best idea to you? I could do either way. It's very, very much like C now, in terms of features.

 

[WhiteCube]

Having classes in a low level language feels like a bad idea.

How about taking a leaf out of Microsoft's book and adding an extra level?

Some kind of very general intermediate language (IL) between PNFHA and PNFASM.

PNFHA has classes.
IL has classes.
PNFASM does not.
PNF does not.

All your future high level languages could compile to IL, so you only have to implement classes once, in the IL compiler.

 

[des000]

Yes, intermediate languages, was my other idea for now. I WILL want to be able to add it to the low level eventually, but it can wait, if I can make breakthroughs faster another way.

As for where to place it, my idea was ABOVE PNFHA, called PNFHRA (Portable Numbers Format Higher Level Language A). In my idea:

Below PNFHA - No classes
PNFHA - No classes
PNFHRA - Classes

This was how C++ actually started! C++ compiled to C, origionally. So anyway, that's my idea.

I'm open, to creating more layers, like you suggested, as well, but for now, to me, that feels like a bad idea.

Adding classes to the lower level, feels right, because, at higher levels, I have made some design decisions, that I have to live with for now. It's way harder to begin to determine the meaning of code (for the computer), if I add too much high level concepts that don't map one-to-one with features of the language. For example, I had lots of trouble with if statements, and stuff like that, even though a human, me, would not have trouble. I was trying to implement them in terms of jumps.

So I added ifs to the lower level as well, and it was trivial. Same concept here. It doesn't mean I won't get better at adding stuff like that, but got to learn at my own pace.

If there isn't any major reasons why NOT to do it, I'll probably take the advice here, but my way, as described above. I can always come back and change it later!

 

[des000]

Can't find any such "mark as solved, at least I think", link. So I'm going to just say here, at the end of every forum I work on that I believe it is, whether it's solved or not.

HINT: I believe this one is solved for now.

SOLVED.