Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Ashbad on May 10, 2011, 02:03:52 pm
-
Emerald:
(http://img.removedfromgame.com/imgs/Emerald.png)
Emerald is a language I have theorized for a long time. I have finally decided to make this
my primary project! I choose to present it here cautiously, not because there's competition
but rather due to the entirely new form of syntax and ideals it portrays. An example of the
syntax:
~seep classpath
define ostack Felines further
accept Cat, etc
expand
/further
define type Cat further
String Name null
define creator Cat void (String Name) futher
set Name
/further
define action Meow void () further
pusln("Meow".."/n")
/further
/further
generate from Felines Cat("Mimo")
Felines.entry[0].Meow #ouputs Meow :P
ostacks are a main feautre of emerald. Ostcks are object stacks, which essentially hold
unnamed objects in an indexed format. This is one theory I thought HAD to be included, and
is really awesome because to create a new one all you have to do is use 'generate' and say
which stack you add it to. The stacks can be set to accept only certain types, but the
'etc' commands allows for you to later define types that can be inserted into the stack.
Everything in the stack inherits traits from a higher class -- but I didn't use it ion this
example.
Weird concept, but I personally think it's awesome. That's just one of the surprises in Emerald Coding -- other features include:
- compiles to interpretable bytecode
- full support for object oriented programming
- new additions to the original object oriented approach
- very user-friendly syntax
- easy to learn new concepts that extend modern OOP
- low benchmarks for easy VM translation
- interpretable bytecode can be run at speeds similar to Java and other non-direct compiled languages
- very small program size
One thing that may seem trivial at first is the use of object stacks to hold similar types (Emerald name for classes). Stacks can have a mainframe type that all objects in the stack inherit properties from. This allows for easy inheritance that can be applied at any time to specific objects.
All attributes of an object in Emerald are hidden and must be accessed through actions (methods). Example:
generate from Felines Cat(3) # 3 == age
int KittyAge Cat.Age #illegal
int KittyAge Cat.GetAge() #legal
int KittyAge (generate from Felines Cat(3)) #even better!
[More info later]
VixenVM
(http://img.removedfromgame.com/imgs/1-VixenVM.png)
A low-level minimalistic VM for interpreting Emerald Bytecode! Includes minimal GC, threading control, and forwards compatibility with higher-level VM implementation methods!
Features include:
- multi-threading (up to 256 threads at one time)
- program-denoted garbage collection
- preloading of bytecodes to ensure speed while interpreting
- minimalistic design for implementations on lesser technologies
[More info later]
-
Sounds awesome! we should create an interpreter for calcs if its finished! ;D
-
Sounds awesome! we should create an interpreter for calcs if its finished! ;D
That's the thing ;) it IS for calcs :D specifically the prizm, but maybe I'll make a version of Vixen that even is supported on an 84+ ;)
-
Ashbad, I'm sorry if I'm rude, but how many languages have you said you'd make so far? I can count 3, not being rude, but perhaps you should try and finish your projects before starting new ones because your finished ones look great (Pyyrix, Vector Tunnel, Trio and Nikko demo).
Especially for calcs, making languages for calcs is even harder.
Either way, good luck!
-
Ashbad, I'm sorry if I'm rude, but how many languages have you said you'd make so far? I can count 3, not being rude, but perhaps you should try and finish your projects before starting new ones because your finished ones look great (Pyyrix, Vector Tunnel, Trio and Nikko demo).
Especially for calcs, making languages for calcs is even harder.
Either way, good luck!
those languages turned out to be poorly planned and stupid.
most great languages have had many incarnations before they came into being. This is the same. Good day, sir!
and scout, what makes it harder to have it on calc? ;) it really isn't any more difficult, and in many senses much easier, since you have less limitations OS-wise, and the prizm is a perfect platform to kick this off on ;)
-
Nice, I look forward to seeing how this turns out. Good luck handling the threading. Context switchers are a bear to write and shell threading compatibility will be a big problem if you're not careful. :)
Side note: Not sure if it qualifies as a "low level VM," since you're presumably writing it in C and it has OO syntax.
-
thanks for the heads up qwerty ;)
also, I mean low-level in more of a 'minimalistic' sense ;) sorry if I didn't express that clearly :P
-
Seems nice, good luck on this. Remember however that designing a language is a huge undertaking. Make sure the syntax is similar to other languages and that it's easy to learn and not a PITA to use. Also keep in mind you have competition for the Prizm with a potential Axe-style language so you need to make sure it has things to offer that other languages don't. I hope to see more languages come out for the Prizm, though, because it will give more choice for the user.
By the way for some reasons the first logo reminded me of an old TV channel that used to exist here (where they aired some cartoons and stuff for both kids and adults).
-
thanks for the heads-up DJ :)
also, I'd be glad to take ideas. I don't really need any to make this great, bu I would appreciate anything anyone has to offer.
-
On a side note, would this support multiple type of integers? For example would we have to use 1-2 bytes integers or could we use different ones like 4 bytes unsigned?
-
it will actually support integers of defined length ;) of course it will have 16 bit integers as default, but you can declare them as 8 bit to 64 bit. ;)
-
Ah ok that's good. :)
-
yeah, I want low and high level support on this ;)
Any ideas? Please express any ideas you may have here :D
-
The ability to insert hex would be nice, as well as a lot of drawing commands.
-
As a suggestion, try to not make the interpreter and editor ridiculously massive. If someone wants to play Pong, he's not gonna download an extra 1 megabytes interpreter, plus it would take a long while to transfer to the calc anyway.
Also make the editor user-friendly, because for example with BBC Basic for the 83+ people were turned away by the editor.
-
As a suggestion, try to not make the interpreter and editor ridiculously massive. If someone wants to play Pong, he's not gonna download an extra 1 megabytes interpreter, plus it would take a long while to transfer to the calc anyway.
Also make the editor user-friendly, because for example with BBC Basic for the 83+ people were turned away by the editor.
I plan to make an editor in the future, tokens-based ;) you see, I'll be releasing VixenVM in two forms -- a full version with a compiler AND IDE AND interpreter, and a interpreting-only version that wil be significantly smaller and onyl runs compiled bytecodes.
Qwerty: inserting hEx actually won't be that had of a thing to implement ;) in fact, I might go GCC style and have a function in mainlib.emh that inputs blocked hEx code (though no mnemonics, though I'm sure you're fine with that ;)) and when the starting opcode is seen by the interpreter, it stops interpreting, and simply runs in the background while the hEx is run as assembly code, going until a stop codon is found ;)
hEx won't be extremely simple to implement, but following the Codon Interpreting Theory I should be able to do it decently ;)
Also, graphics commands are much easier :D I plan to include a library that has simple sprite, pixel editing, and alpha channeling commands included.
Right now I'm debating as to what libraries in Emerald will be written in, either C or Emerald bytecode...
Any other ideas?
-
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.
-
it's not intended as discriminatory in any way ;) just so you know:
hex -- just hexadecimal numbers
hEx -- programming with hex opcodes
not negative in any way, it's just a quick way to segregate the two. Please don't try to start unnessicary fights.
and, inserting hex into a source file will be pretty easy :)
-
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' :P
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.
-
Sadly I don't code much anymore so I don't understand that stuff much, but hopefully you can find something that satisfy people well in overall.
-
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.
-
It definitely needs to have the smallest and faster interpreter possible for production, but there should also be a development interpreter that can help with debugging.
-
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 ;)
-
I think he was asking so maybe there is only one single add-in required for every existing third-party Casio PRIZM languages. Basically this would be to prevent people who want to program in multiple languages or run interpreted games from having like 10 different add-ins to do so. Another example is how Doors CS can run games from all shell, while with MirageOS, you still needed to carry Ion for certain games, xLIB for others, Celtic III for others, CalcUtil to do backups, etc.
-
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.
-
well, I might be able port it to Khavi in the future, but Vixen will take a tight grip over emerald source programs, and transferring this to Khavi would possibly lead to high levels of underutilization of interpreting. However, feel free to post some features of Khavi here :) I'm interested as to what it can provide emerald with.
EDIT: and if anyone here has ANY suggestions, I bade you to please post them :)
-
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' :P
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:
~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 :P) 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 :D
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:
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.
-
since I have thought of a way to implement them with little strife, I will be allowing for lambda, or anonymous functions to be used in Emerald programming. The approach is exactly the same as Ruby's:
Function = lambda {|x, root| x**root}
-
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.
-
Looks good and I think I understand about 3/4 of what was said. I believe that is a great success for me
Good Luck. We might want a port of this to Nspire sometime...
-
Looks like a fun language to program in. ^^
We might want a port of this to the 84 sometime...
-
This will be fun to play around with I'm sure.
-
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.
thanks DJ ;) I'm aiming it so that everyone from TI-BASIC (beginner) to Java (intermediate) to Ruby (advanced) programmers can enjoy it; which is why I'm making sure that it allows functional programming without OOP, so all of these are legal:
function = lambda {|boolean, value|
if boolean
return value**value
else
return nil
/if
}
putsln(AsString(function().call(true, 5)))
works just as
define type function further
define action call rien (boolean, value) further
if boolean
return value**value
else
return nil
/if
/further
/further
putsln(AsString(generate function().call(true, 5)))
which can work as:
boolean boolcat true
int value 5
if boolcat
putiln(value)
/if
for your favorite taste of programming ;)
-
i'd suggest getting rid of further and /further and replacing them with something else (curly braces, parens). this might just be me but i don't find them aesthetically pleasing. also, i'm not sure how much room there is on the PRIZM's screen.
would all of this fit on one line?
define action call rien (boolean, value) further
it may be annoying to read if it's split up.
-
yeah, that would fit on one screen -- the text is much smaller than the locate or Text letters. I'm thinking of allowing curly braces OR further /further to allow for more people to enjoy the syntax. Also, for actions, I'm debating to get rid of 'define' before it, since I'm not planning on allowing for polymorphic functions. This is what I might make it look like:
action NAME RETURN_TYPE(ARGS) further
which is a bit smaller.
-
I have finally completed a working draft of the Standard Emerald Bytecode Set! The bytecodes are actually rather space-saving as compared to something like Java, because they represent higher ideas than Java ones. I predict much smaller and faster (compiled) code with Emerald :D
I am also working on preliminary testing with a Ruby script I made that 'Emulates' VixenVM. Right now, it works with ~50 of the 200+ opcodes, and I plan to upload the source here by Thursday. Once I have a draft of that working, I can transfer it to Prizm C -- to make sure there will be little hassle translating it, I'm writing my Ruby code C-Style (No OOP, no closures, so other awesome things).
I plan to release a specific list of how all opcodes work later this week. Just to show you how high-level these Bytecodes are, there are no math commands whatsoever. A preliminary math is handled by the queue interpreter, which passes the code to the main interpreter, which Qwerty had asked about earlier. This is what I was planning on having it do, so I guess that answers your previous question a bit easier ;) In fact, it should answer both.
-
Sounds great ashbad. now I just wish I understood half of what you said
-
Don't worry, you don't have to -- all you'll have to understand is the Emerald Language itself ;)
-
so when do you expect to have a guide for programming in it released?
What platforms will it work on?
-
Prizm for now, I'll working on a doc ;)
-
Will you port this to comp sometime?
-
Will you port this to comp sometime?
most likely, if the Prizm version goes well ;)
-
OK because I will probably not get a Prizm anytime soon and wan to play around with this language
-
That could take a while, but I can promise there will be a day ^_^
EDIT: getting some helpers would speed up the process :P
-
I only really know python so If I ccan help I'll try but I doubt I can do much
-
Yeah, the people I'll need for helpers would have to know C, C++ or something comparable like Ada. I'll be the only programmer for the Prizm version, but a computer version would need more developers, since anything on a computer is intrinsically harder to make :P
-
I have been learning C/C++ but still have a long way to go. I'll just be ideas and bugchecking/tester if I can't do anything else
-
well, I mean, only if you're up to it ;) plus, for now the main (or only) focus is on the Prizm version, so it'll be a little while until I would pull you in ;)
-
I can wait I have other projects to worry about also.
I just started an android based python project even though I don't own an android just use the emulator
-
sounds awesome :D maybe one day we'll be using Emerald to write Android applications! ;D
But, to put this in better perspective, the Prizm part is only 10% done O.o
-
Its hard enough to write a basic program in python for it. I don't want to even think about witing a whole language for it
-
I can handle computer stuff pretty well. I'm experienced with C/C++ and can also write in x86 for faster routines. If you need any help later then just ask me.
-
okay, sounds awesome! :D I'll be sure to call on you later.