This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - shkaboinka
16
« on: July 19, 2012, 01:13:09 am »
Because I took a couple pages to say it in detail (and because I've been told not to link to other forums), I will just sum it up:
With the switch from a C# style to a Go style, I figured that interfaces provide enough dynamic behavior to be alright without providing parametric types ("templates" in C++, "generics" in Java), since you can just use an interface to store data of any type. The empty interface ("interface any{ }") acts as a pointer to anything without any method requirements (like "void*" in C++ or "Object" in Java).
The problem is that using a more complete interface means that each entry is larger, since the relevant function pointers are stored alongside them. For example, each item in "data" below contains a pointer to some object, AND pointers to all the methods of the interface:
interface Printer { Print(); }
struct Foo { []Printer data; }
One solution would be to use Parametric types as a convention for storing the method-pointers separately. It would look something like this, with "<T:Printer>" designating that the struct separately stores ONE copy of method-pointers for the "Printer" interface, and designating "T" as a stand-in for something that counts as a "Printer" (i.e. something with a Print method, but not an actual "Printer" itself):
interface Printer { Print(); }
struct Foo<T:Printer> { []T data; }
This would require each "T" to be stored as a pointer (rather than a whole "Printer") so that the same struct (or any parameterized entity)can be used for anything. Otherwise there would have to be a different "version" for each type, and it would be pointless to actually store implicit method pointers for the interface, since each version could have the "right one" hard-coded in. In either case though, this struct would be used with a datatype plugged into it, which the compiler would use to restrict what can be stored in it:
Foo<int> list; // list may only work with ints (and stores an int.Print pointer)
Foo<Bar> list2; // list2 only works with Bars (stores a single Bar.Print pointer)
The issue is two things (and a couple of trivial things that I will leave out):
The first is that it does not parse well ("x<y,z>w" could be a tuple of two boolean comparisons, it it could be saying that "w" is somthing of type "x<y,z>"). This can be solved by using an unconventional syntax, or by requiring the "tuple version" to use extra parenthesis to work properly, or by reparameterizing each parametric type (e.g. "x<y><z>").
The second is just whether to use the "generic" form (all parametric types are pointers) or the "template" form (the compiler makes a copy of everything for EACH type used). The first only uses one version of everything and provides true dynamic entities. The second makes multiple copies which are hard-coded per type, but each is more efficient; however, the copies depend on what is used per compile, and there cannot be one precompiled version (set of methods), so it could not exist as a runtime library unless the "generics" setup is used.
17
« on: July 18, 2012, 03:17:36 pm »
Woah, looks like I missed a few posts. I don't know why, but I wasn't receiving emails.
Anywho, the grammar looks good! I'll have to take a gander at the source sometime soon 
Awesome, you guys! Thanks! By the way, the source will need some redoing; but feel free to see it anyway. I will have to make sure the Token class matches everything now, and there are other changes (reserved words do not currently "count" as identifiers, which might result in confusing error messages). Also, the Tokenizer class (previously "Preprocessor") is going to be highly revised so that it can spit out one thing at a time (like the Token.nextToken()) rather than messing with Lists (so as to make it play nice as an API). I am planning on perhaps making a "TokenSource" interface so that things OTHER than Token.nextToken() can be used to get tokens, with Tokenizer acting as an intermediary which uses that and preprocesses at the same time. ...I have an interesting conundrum to resolve as well, and posted about it in Cemetech; but it's REALLY long...
18
« on: July 12, 2012, 06:48:47 pm »
Well, being as that I finally fixed up that image so it doesn't look like a stuffed animal...  ...I think I am sticking with Antelope. But thanks for supporting my cause! 
19
« on: July 10, 2012, 07:09:44 pm »
Further discussion suggested I choose a random name that "sounds" better. I considered "tadpole", "polywog", and "caterpillar" (since my language is simple, polymorphic, and will hopefully grow into something big); I threw out other ideas from constructed languages (nevermind!); and then finally I just asked my wife (who has nothing to do with programming), and she immediately referred to my little friend:  ( http://tinyurl.com/AntelopePic) It looks like my little friend ("The Antelope") just accidentally became a programming language mascot: I think I'm going to stick with "Antelope"! (..and I changed the thread name to match..) HERE ARE THE NEW LINKS:http://tinyurl.com/antelopeHome - Antelope Home page http://tinyurl.com/antelopeOverview - Antelope Overview page http://tinyurl.com/antelopeGrammar - Antelope Grammar page http://tinyurl.com/antelopeSource - Antelope Source Code page http://tinyurl.com/antelopeCode - Source Code (again) I have also left a link on the old OPIA page, though I have yet to actually import everything over (but do see what I've done with the home/intro page). EDIT: All the (relevant) documentation and code has been ported over (enjoy)! I will delete the old project eventually.
20
« on: July 09, 2012, 05:02:45 pm »
I am considering changing the name of the OPIA language, since it has already left the classic OOP paradigm (it is still object based, but the polymorphic behavior is provided separately from objects), and to define it in its own terms (i.e. not a "revised" Antidisassemblage).
SOME POSSIBILITIES:
OPIL - Objective Pre-Interpreted Language
OPPIL - Objective Polymorphic Pre-Interpreted Language
PIOBL - Pre-Interpreted Object-Based Language
PIOL - Pre-Interpreted Objective Language
PIOPL - Pre-Interpreted Objective Polymorphic Language
PIOZL - Pre-Interpreted Objective z80 Language
PIPL - Pre-Interpreted Polymorphic Language
POBL - Polymorphic (or Pre-interpreted) Object Based Language
POL - Polymorphic (or Pre-interpreted) Objective Language
POPIL - Polymorphic Objective Pre-Interpreted Language
POPL - (same as above, or flip the P's around)
POPIZL - Polymorphic Objective Pre-Interpreted z80 Language
POZL - Polymorphic (or Pre-Interpreted) Objective z80 Language
PPIL - Polymorphic Pre-Interpreted Language ("P Pill")
ZOPIL - z80 Objective Pre-Interpreted Language
ZOPPIL - z80 Objective Polymorphic Pre-Interpreted Language
ZPIOL - z80 Pre-Interpreted Objective Language
ZPIPL - z80 Pre-Interpreted Polymorphic Language
ZPOL - z80 Polymorphic (or Pre-Interpreted) Objective Language
ZPOPIL - z80 Polymorphic Objective Pre-Interpreted Language
ZPOPL - (same as above, or flip the P's around)
ZPPIL - z80 Polymorphic Pre-Interpreted Language
ZPPL - (same as above, or flip the P's around)
Notes:
- "Objects" and "Polymorphism" kind of imply each other.
- "Pre-Interpreted" could be "Partially interpreted" instead.
- "Objective" and "Object Based" are mostly interchangeable.
- I am also considering how the name "sounds" (though some like ZPPL would just be read letter by letter).
- The following languages already exist: PIPL OPL ZOPL PPL.
OPINIONS (for or against) ARE APPRECIATED!
21
« on: July 02, 2012, 06:01:06 pm »
I have finally completed the grammar!I was very thorough in including notes, explanations, additional semantics, and examples. The grammar gives a technical definition of OPIA syntax in detail, but I have also included a list of classes used and an explanation of how they are used, and a very integrated (and thorough, though somewhat shortened) example of how the parsing works with the classes used. Please take a look! (and let me know if anybody can find anything wrong with it, thanks) Note: Due to current circumstances, designing the compiler may have to take a back seat for a while (job search, baby coming due). HOWEVER, please also note that the grammar is already a very complete definition of MUCH of the compiler internals. ... When I can find significant time, it will be much a matter of writing code to match the rules (almost exactly as they are described).
22
« on: June 30, 2012, 01:58:23 am »
All the grammar rules are now in place! I just have to revise the example a bit more, and perhaps add in some more "notes / additional semantics" (which I have kinda been glossing over).
23
« on: June 27, 2012, 05:24:16 pm »
Hazzah for lambda expressions and anonymous functions! 
One question, though: I just noticed bit rotation. Is that where 0b00100110 >>> 3 == 0b11000100?
Indeed it is! I figured that it's useful enough in z80 programming to just make it a direct operator. I know that Java uses ">>>" for "unsigned left shift", but that's only because it does not allow for unsigned variables. In OPIA (and other languages), you can just use a type-cast to affect the operation anyway
24
« on: June 27, 2012, 03:49:44 pm »
*Bump!* I've updated the Grammar a good deal, take a look! The next step is to throw in all the statement-level items, which will help me finish all the namespace-level items. Notice that I've finally incorporated lambda expressions, anonymous functions, and literal constructs into the expression-web (which was hard because I had to provide a way for "types" to exist as expressions, including all I just mentioned).
25
« on: June 18, 2012, 03:21:33 pm »
I feel it worth sharing a conversation from another thread: It looks good to me. Though I can't help but point at that examples are always a good idea, even if you think it's readable. Not everyone is you. What you and Kerm basically just did is an example of intellectual exceptionalism--you more-or-less said "it's easy to understand if you're not dumb". Thanks for bringing this to light, because the fact that it appears that way means that I was not clear about what I posted and why (oops!): The Grammar is something that I posted as a necessary aid in designing the compiler, rather than as a medium I chose to explain the language to everybody (that's what the overview is for). However, in the spirit of open source development (and to involve the community), I document everything and try to keep it as clear as possible for what it is (e.g. I try to keep the source code easy to read if you know Java). However, given the involvement/interest in the community, the usefulness of a grammar, and in light merth's point (thanks), posting a section about how the grammar works would be very helpful in general as well as providing the opportunity for more people to see how the compiler/language is directly put together (and for those so inclined, I provide those very same classes in the compiler with external access as a Java API).
26
« on: June 18, 2012, 04:12:31 am »
UPDATE: I basically have all the structural classes (for the syntax tree) figured out now! Take a look!
27
« on: June 17, 2012, 06:28:31 pm »
Ooh... Can I have a look at it sometime? At least eventually, I'd love to swap code. I have not yet come across somebody actively coding a compiler, and I'd like to compare approaches / techniques. All I have in place right now though is the Tokenizing and Preprocessing; though I am thinking about redoing some of that as well for modularization reasons.
28
« on: June 17, 2012, 06:11:06 pm »
Everything will be custom-written. In the past, I've kinda cowboy'd it and written classes for function-, class-, etc.- entities and worked down from there. However, this time I am making a clear grammar first, and even going as far as listing what kinds of classes will be needed to represent each. Compiler tools are great, but it is entirely practical, legit, and rewarding to actually make the compiler yourself. I will likely do that from start to finish, though I MIGHT consider something for optimizing intermediate ("3 instruction") code.
Once I have all the grammar rules down (along with additional semantic rules and associated classes), coding it will be a snap -- most rules will translate directly to code (though similar ones might use the same code with a branch in it).
29
« on: June 17, 2012, 01:35:14 am »
I am putting together the Grammar for OPIA, as can be seen in the link below. The compiler will have a portion of syntax-tree-building code corresponding to each rule. In the past, I've made different "versions" of similar rules so that they can work properly in their respective contexts (e.g. variable declarations follow a preset form, but have different restrictions in global, local, and object-member contexts). HOWEVER, my plan this time is to leave the rules more broad (e.g. use the same rule for "lists" of values as function arguments, array values, and variable declarations), but then inspect the contents of the resulting syntax structures to make sure that they are consistent with the context (e.g. variable declarations can contain a "list" of "assignments", but assignments are not allowed within other expressions; Function declarations take a list of variable declarations for arguments, but function pointers take a list of JUST datatypes; etc.). This will also allow complex portions of code to be parsed correctly, even when placed in a context which would otherwise not now what to do with it (which means better error messages). For this reason, I am starting the rules in a very general sense by using "E" values as a placeholder until I narrow everything down. PLEASE LOOK AT THE GRAMMAR IF YOU CAN: Feedback will be GREATLY appreciated as I work on them, and will help ensure that OPIA's compiler is designed well (and sooner). Here are some new links, along with the link to the grammar: Intro: http://tinyurl.com/z80opiaOverview: http://tinyurl.com/z80opiaOGrammar: http://tinyurl.com/z80opiaG
30
« on: May 26, 2012, 04:46:57 pm »
I plan on re-documenting the language once it is done or underway. I do want it to be a concise reference, but I will probably give better (more realistic) examples. The compiler will only be a command-line interface, so there will not be anything visual to show for. However, this will allow it to be integrated into whatever other program (like how different things link into Notepad++, etc.). I will probably make a visual editor; but this way the core language/compiler (and all of it's inner modules) stay modular / pluggable.
|
Show Posts