Please don't start with the "hEx" nonsense. It's unnecessary and rather discriminatory. Also, I was asking about inserting hex into the bytecode, not hexadecimal machine code.

I have decided to change the idea of the 'Stack Theory' I had -- it was a decent idea, but the way I implemented it was stupid.  However, it did evolve into GROUPING, the main form of inheritance and erm, grouping objects in emerald.

Basically, a group of objects are all related by an 'extending' type (class).  everything in that group inherits everything from that group's master type (superclass).  Every object in there is not extended to that master type during declaration, but during generation.  This means that one class can be made in unique forms and can extend different types.

Another thing about the 'Group Theory' of mine is that it allows more flexibility of Object Polymorphism.  You see, everything in a group extends a master type -- that makes all grouped objects 'brethren' classes.  Protected attributes can by shared only among brethren types.  However, I also plan to have it so that groups can be grouped my master groups, so then that makes all brethren objects in one group brethren with brethren objects in another group.  This layout totally kicks out the wall of normal OOP and can actually be quite useful in a large variety of applications, whereas an OStack most likely won't.  Thanks for all the advice christop, sorry about my bit chin'

Another thing: I've been reading about different programming languages lately, from ALL paradigms and generations that can be found on wikipedia, and from that I've gotten interesting ideas.  Please express what you think of them:

- Atom variable types, which basically define anything you set them to define.  This can lead to confusing code, but on the contrary in some instances can also lead to cleaner implementations

- when you further a class with the 'further' and '/further' keywords, you don't just define a type.  'further' can be used any time, any place to extend the attributes of a type -- so you can create tons of cats with only a name, but later extend them to also have an age (I actually came up with this one on my own)

- simple polymorphic code

- you can declare a class anywhere -- and with polymorphic code included, you can put a class declaration in a nloop (for loop) and change the name of the class you define each loop, so you can effectively create 100 types in <5 lines of code (kinda came up with this on my own)

- allow for pure-functional code to be the basis of a program as well, to support many different paradigms to help more people enjoy the language (well, I obviously ripped this from >50 modern languages )

any others?  I spent a while today thinking these up, so I would appreciate any concerns, comments, or suggestions and I'll try to be more grateful for feedback from now on; again, sorry christop, no hard feelings I hope.

For Vixen I would suggest using Qwerty's Khavi framework as the byte code loader. Khavi is designed to work as a virtual machine framework and is well suited for interpreters and emulators. It is very fast, small size, and can handle threads.

And for Emerald make sure you keep in mind the other languages on the Prizm. Yes there is an Axe like language planned, but sometimes a user would prefer an interpreted language over a compiled one for easier and faster coding. Then on the interpreted side you have both Lua and Java, but both of those are computer compiled. I would though match the language difficulty with Lua, but easier than Java and harder than BASIC. And yes there is also a planned BASIC interpreter rewrite, but that is not byte code so is a little bit slower plus it doesn't have OOP. I would almost think of Emerald as advanced BASIC  as that would be your target group, experienced BASIC coders who feel restricted by current BASIC constraints.

I don't think I'll be using Khavi, since this is going to be personalized for Emerald coding only

..

Why you might ask?  Unless Khavi supports OOP high level commands, multithreading, and background operations, plus other ideals, it will not be suitable

Why you might ask?  Unless Khavi supports OOP high level commands, multithreading, and background operations, plus other ideals, it will not be suitable

Not sure what you mean by "background operations," but the first two are a definite Yes and the second is probably yes as well.

However, I don't think Khavi would be suitable because it requires that you have some level of control over what the machine code looks like, something that C is notoriously bad at providing. It's probably possible to do in C, but it'd likely require a lot of inline ASM.

Here are some updates that were on cemetech -- they seemed to ask more questions with the specifics --

I have decided to change the idea of the 'Stack Theory' I had -- it was a decent idea, but the way I implemented it was stupid.  However, it did evolve into GROUPING, the main form of inheritance and erm, grouping objects in emerald.

Basically, a group of objects are all related by an 'extending' type (class).  everything in that group inherits everything from that group's master type (superclass).  Every object in there is not extended to that master type during declaration, but during generation.  This means that one class can be made in unique forms and can extend different types.

Another thing about the 'Group Theory' of mine is that it allows more flexibility of Object Polymorphism.  You see, everything in a group extends a master type -- that makes all grouped objects 'brethren' classes.  Protected attributes can by shared only among brethren types.  However, I also plan to have it so that groups can be grouped my master groups, so then that makes all brethren objects in one group brethren with brethren objects in another group.  This layout totally kicks out the wall of normal OOP and can actually be quite useful in a large variety of applications, whereas an OStack most likely won't.  Thanks for all the advice christop, sorry about my bit chin'

Another thing: I've been reading about different programming languages lately, from ALL paradigms and generations that can be found on wikipedia, and from that I've gotten interesting ideas.  Please express what you think of them:

- Atom variable types, which basically define anything you set them to define.  This can lead to confusing code, but on the contrary in some instances can also lead to cleaner implementations

- when you further a class with the 'further' and '/further' keywords, you don't just define a type.  'further' can be used any time, any place to extend the attributes of a type -- so you can create tons of cats with only a name, but later extend them to also have an age (I actually came up with this one on my own)

- simple polymorphic code

- you can declare a class anywhere -- and with polymorphic code included, you can put a class declaration in a nloop (for loop) and change the name of the class you define each loop, so you can effectively create 100 types in <5 lines of code (kinda came up with this on my own)

- allow for pure-functional code to be the basis of a program as well, to support many different paradigms to help more people enjoy the language (well, I obviously ripped this from >50 modern languages )

any others?  I spent a while today thinking these up, so I would appreciate any concerns, comments, or suggestions and I'll try to be more grateful for feedback from now on; again, sorry christop, no hard feelings I hope.

My theory of defining a class more at any given time:

Kerm, I'm sure you wouldn't be editing a class' structure regularly, but let's say you have a program like this:

Code: [Select]

~seep classpath

define group Suspects further
   accept Man, Woman, CreepyGuy, etc
/further

define type Man further
   define creator Man void () further /further
   define String name "Merth"
/further

define type Woman further
   define creator Man void () further /further
   define String name "Melissa"
/further

define type CreepyGuy further
   define creator Man void () further /further
   define String name "Obama bin LOVING AMERICA!"
/further

Man Merth generate from Suspects Man()
Woman Melissa generate from Suspects Woman()
CreepyGuy Obama generate from Suspects CreepyGuy()

 # Let's say we want to know more about the creepy guy
 # So, let's set him up with a 'Favorite Food'

type CreepyGuy further
   define String FavoriteFood "Unsuspecting teenagers"
/further

###
 this helps us so we can pinpoint a crime directly onto him,
 in this case obviously being a... creepy guy.
 somewhat lame example, but I think it's decent enough to
 get the gist of it :)
###


somewhat bad example, but it does work fine in explaining methinks.

Duck typing came up, but christop proposed it would lead to too much overhead on a calculator, so I pretty much dumped he idea (that and because it wouldn't be as easy to implement.

The variable type 'atom' as described above is now renamed 'rien' variables, which means 'anything' in french.  Once they are defined with a type, their type remains static.

Kerm wondered exactly what Emerald was to provide (good question, actually) so my response:

Full applications.  The thing is, unlike that stupidly funny EmulatorLanguage he posted (which, when I read it, seems quite funny ) this is being made such as in the same way Ruby, Groovy, etc. were made -- the creator thought that existing languages could either use a little 'oomph' or even a different style of implementation of modern features, which is essentially what I'm doing -- if you read any syntax from the past few pages, you'll realize that many things are different in Emerald -- maybe not enough differences to merit a 'Brainf*ck' award, but it is considerably different.

One thing about Emerald is that it's meant to portray a different perspective on today's view of Programming Science theories.  Such as my method of OOP -- literal groups that are treated in a way somewhat like a type themselves that hold actual references to objects, master types, further polymorphism merits, and even more is quite different than the normal "Class JavaClass extends Object" method.  Maybe it'll fail to attract that much of an audience at all -- but then again, I'm sure some would love the radically different ideals, and would use it.

And, the only reason I'm implementing it on a calculator is because I think C++ is disgusting, C isn't OOP, Java is lame, Lua is slow, BASIC is Lua--, Axe is even less OOP than C, and I need something that's IMO good to write stuff in on calc since the others do not appeal to me.  Of course, I could always port Ruby or the like, but even then, I need a better project than converting something that can probably be ported with minimal stress

I intend for it to be used in a wide array of applications.  Whether or not people DO use it, it's up to them, but I will be one who won't code in anything else.

And, to force people to have at least a rudimentary version of Vixen on their calculators, I will only write my stuff in Emerald, and if you want to play/utilize my applications, you need my other applications

I am taking this project extremely seriously and unlike all my other crap ideas, this already has everything from a timeline to > 100 hours of my thought and theory.  It has twice as much planning as my eagle project did, and still hundreds of hours more until a stable 1.0 will even be released.  I expect most of my summer coding to be devoted to this -- I'm even forming a flexible timetable for advancements in the project details.  This isn't like Suave, Lo-C, or 'DE, it has a lot of devotion going into it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

With that being said, I've already started theorizing the exact functions of VixenVM, its operations, and how it interacts with a program.  Basically, it 'wraps itself around the program like a snake' and in turn the program 'force feeds Vixen with bytecodes and instructions'.  Here is how a program initialization will work:

1. Vixen reads through the program's header and preliminary VM-specific instructions while the program is finalized for cases of runtime-applicable polymorphic coding
2. Vixen starts by loading 64 bytecode-grouplets (the operation and the parameters, plus other aspects of the bytecodes being analyzed) into a quick-to-access bytecode buffer
3. Vixen starts a thread that interprets the operations in the bytecode-buffer
4. right after, Vixen then starts a simultaneous thread that loads more opcodes into the buffer that the first thread reads.  This thread  remains inactive until the other thread gives an output signal that it has finished a bytecode-group and quickly adds another onto the buffer while the other thread starts reading the next in line, and chucks out the old one.  These last actions happen simultaneously.
5. (still thinking)

[more to come in an hour or so]

Qwerty asked:

Quote from: Ashbad

With that being said, I've already started theorizing the exact functions of VixenVM, its operations, and how it interacts with a program.  Basically, it 'wraps itself around the program like a snake' and in turn the program 'force feeds Vixen with bytecodes and instructions'.  Here is how a program initialization will work:

1. Vixen reads through the program's header and preliminary VM-specific instructions while the program is finalized for cases of runtime-applicable polymorphic coding
2. Vixen starts by loading 64 bytecode-grouplets (the operation and the parameters, plus other aspects of the bytecodes being analyzed) into a quick-to-access bytecode buffer
3. Vixen starts a thread that interprets the operations in the bytecode-buffer
4. right after, Vixen then starts a simultaneous thread that loads more opcodes into the buffer that the first thread reads.  This thread  remains inactive until the other thread gives an output signal that it has finished a bytecode-group and quickly adds another onto the buffer while the other thread starts reading the next in line, and chucks out the old one.  These last actions happen simultaneously.
5. (still thinking)

You can't have simultaneity on a single core processor. Accordingly, there's almost certainly going to be a way to get the instruction parser to overrun its buffer. Also, I don't see why you need a secondary buffer if you're not going to do explicit caching or JIT compilation. It seems like you're just going to waste cycles copying data that's already in the file you're reading from.

Just a thought.

PS: The "Snake/living VM" thing sounds pretty much like the standard VM model. Is there a difference?

I responded:

Well, basically, I didn't write much of what's truly going on, because that takes a very large and complex diagram

the cache loader does some hand-over interpretation to make the main interpreter go faster, and since it can happen simultaneously (there's a wide array of ways to achieve multitasking on single-core processors) it will reduce overhead.

So, a lot of updates here -- I thought I should share them, as most of them are extremely important ones.

This seems nice Ashbad. In the end the language has to be user-friendly, while still being powerful. Unfortunately I don't understand everything that was said above but I wish you luck in this project.