Don't have an account? Register now to chat, post, use our tools, and much more.
Latest Headlines
Online Users
There are 125 users online: 1 member, 89 guests and 35 bots.
Members: charlessprinkle.
Bots: VoilaBot (4), Spinn3r (1), Magpie Crawler (3), VoilaBot (7), Googlebot (14), Googlebot (4), MSN/Bing (2).
RSS & Social Media
SAX
You must log in to view the SAX chat widget
|
| Author |
Message |
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
 Posted: 28 May 2012 09:26:39 pm Post subject: |
 |
|
1 is my favorite, since that's what I'm used to, so I'm all for that.
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 31 May 2012 05:16:46 pm Post subject: |
|
|
I am officially adding lambda expressions with the traditional syntax!
Here are some examples, along with their full function equivalents:
Code:
(a,b) => a+b; func(T a, b):T { return a+b; } // T is some datatype inferred by context
(x) => x*x; func(T x):T { return x*x; } // Parentheses are optional for this form
() => x; func():T { return x; }
() => { ..code.. } func() { ...code... } // Return(s) inferred from return statements
I don't really want to allow the last form, which is very close to the full form anyway; and because lambda expressions are just meant to be a short alternative way to write "IN => OUT" in expression form. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 17 Jun 2012 12:11:42 am Post subject: |
|
|
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/z80opia
Overview: http://tinyurl.com/z80opiaO
Grammar: http://tinyurl.com/z80opiaG |
|
| Back to top |
|
|
blue_bear_94
Member
Joined: 20 Apr 2012
Posts: 163
|
| Posted: 17 Jun 2012 01:22:24 pm Post subject: |
|
|
You should include examples for the syntax, such as 1+1[i] or [i]&x.
_________________
Do NOT click any links! |
|
| Back to top |
|
|
KermMartian
Site Admin
Joined: 14 Mar 2005
Posts: 55886
Location: Earth, Sol, Milky Way
|
| Posted: 17 Jun 2012 01:24:59 pm Post subject: |
|
|
Eh, I think what he has is sufficiently clear if you're used to reading compiler grammar definitions. I suppose if you're not familiar with that, it's a markedly more annoying task to read that page. Shkaboinka: The grammar that you have listed seems sufficiently straightfoward to me; I think at this point my bigger concerns are how the compiler/implementation/standard library will look and how nicely it will run on-calc.
_________________
 
 
 |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 17 Jun 2012 05:00:59 pm Post subject: |
|
|
blue_bear: I agree with Kerm that a Grammar is a very standard form for sufficient documentation (especially with the key I included to explain my conventions). However, I understand that language grammars take a bit of getting used to reading.
Kerm: The compiler (and other tools that might tie into it) are all PC oriented, and there is next to nothing for a runtime library built into the core language. I was careful to choose language aspects which rely only on standard coding practices. Libraries can be written (and I hope that many people will want to be involved with such things), but are not part of the core language. Think of C without and libraries. There is support for dynamic allocation, but you need to specify functions for them (external or user-defined).
UPDATE: I basically have all the structural classes (for the syntax tree) figured out now!  Take a look! |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 18 Jun 2012 10:40:42 am Post subject: |
|
|
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".
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 18 Jun 2012 02:20:45 pm Post subject: |
|
|
| merthsoft wrote: | | 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).
EDIT: ...Especially since I requested that people look at it ("if you can" has a couple interpretations) and help make sure it's all good  |
|
| Back to top |
|
|
Ashbad
I am governor Jerry Brown
Joined: 01 Dec 2010
Posts: 2423
Location: There lived a certain man in Russia long ago
|
| Posted: 18 Jun 2012 02:41:37 pm Post subject: |
|
|
I agree about the symbols, but honestly I personally found it quite understandable to read, and kind of cool about how compact and to the point it is  Also, any reason why the "Rule" column on the far left has all the rule names all caps and in many instances, abbreviated? Perhaps to less experienced programmers it would benefit to have them all written out. So overall, my opinion is that the grammar you devised is pretty nifty.
Actually on a side note, perhaps change the notations from gray to a slightly bluish or greenish color so they stand out? Some of the bottom ones are slightly hard to read.
_________________
-Ashbad |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 18 Jun 2012 04:43:07 pm Post subject: |
|
|
I've added an example, but it's messy (and will remain that way until I fix up the grammar rules). It was hard to map the rules properly without knowing how I wanted the underlying classes just yet (and I was fighting separating the class-hierarchies of statements and expressions so that nothing could be build incorrectly from an API standpoint), but now I can work it all out ... and then fix the example (which I might change from a declaration to a plain assignment).
| Ashbad wrote: | I agree about the symbols, but honestly I personally found it quite understandable to read, and kind of cool about how compact and to the point it is Also, any reason why the "Rule" column on the far left has all the rule names all caps and in many instances, abbreviated? Perhaps to less experienced programmers it would benefit to have them all written out. So overall, my opinion is that the grammar you devised is pretty nifty.
Actually on a side note, perhaps change the notations from gray to a slightly bluish or greenish color so they stand out? Some of the bottom ones are slightly hard to read. |
Thanks! ... I had actually started this in Notepad, and I was "quoting" the actual code, but that got bulky. To remove them, I have the rules in ALL CAPS to distinguish them from other code. I chose gray-bold for the other marks because I felt like it actually made them stand out less than the actual code, since (unlike even the rule-names) they are never actually part of the code. This way you can just look at the black text for the code without the control-marks cluttering it up. For the classes, I actually tried putting the types in blue and in bold-blue, but it just looked like too much of a contrast which made it hard to look at; so I just used bold, and decided to unbold the initial class-names for a similar reason. ... I will look over the rule-names though, since they do not really need to be quite so compact. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 20 Jun 2012 03:36:46 pm Post subject: |
|
|
...Would it be terrible if I changed the type-cast syntax again? The issue is that it can be ambiguous to interpret a series of parentheticals:
Code:
(a)(b)(c) // (b) could be either a cast, a function-call, or some other expression
I could go back to the (expression : type) form, since that at least matches the syntax for return types (e.g. saying that the expression is to "return" a certain type). ... I had to go in circles for HOURS with my grammar rules on this issue (note how PRIMARY is supposed to come before CAST and INSTANCE, but CAST comes first so that it can preempt the interpretation of something after a cast, though it calls PRIMARY back so that it evaluates in the proper order ... bleh!). My temporary solution was to assume that all chained parentheticals are casts of casts (until the last one).
EDIT: ... I'm just going to go ahead and use the : syntax. However, I will be thinking about whether to have it be (expression : type) or (type : expression). I will just pick one for now, since it would be VERY easy to change between forms in the grammar.
RE-EDIT: It MUST be the (expression: type) form; otherwise it would clash with function-syntax and make statements like "func():foo" ambiguous.
Last edited by shkaboinka on 04 Jul 2012 12:26:34 am; edited 1 time in total |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 21 Jun 2012 09:53:24 am Post subject: |
|
|
How does C handle (a)(b)(c), and why is yours different? Won't (b) only be a cast if it's a type?
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 21 Jun 2012 04:17:38 pm Post subject: |
|
|
| merthsoft wrote: | | How does C handle (a)(b)(c), and why is yours different? Won't (b) only be a cast if it's a type? |
I know this is a probably more in depth of an answer than expected, but if anyone can follow this, it will give a good understanding of why it matters (and I might still consider that syntax):
The thing about C and C++ is that everything must be declared before it is used, so that by the time you even GET to that statement, it can know whether or not something is a type. Java and C#, on the other hand, allow global (namespace-level) constructs to be declared in any order so that you don't need "headers" etc., but the language syntax makes it much easier to spot things (e.g. they don't allow arrays-types to have specific sizes given, and all literal instances must use the "new" keyword).
The opia compiler is going to build a syntax tree, and then inspect the contents to see what is what (like Java/C#), so it needs to decide in the first place how to package things up. However, because of my decision to NOT allow assignments and declarations within expressions, I designed the underlying classed to not even ALLOW for this hierarchically (for open-API reasons); so I have to do some tricky things to "get" types out. For example, I threw "array-sizing" into the grammar as a unary operation so that higher rules can convert them (and dereferencing) to the corresponding types as needed.
Now for type-declarations and literal-instances, it's a one-time all-or-nothing conversion, and it's pretty clear by context alone when something ought to be a type (e.g. "*x.y" could be a dereference of {dot of x and y}, but the z in "*x.y z" would clearly mean that z is a "x.y" pointer). However, because of the conflicting syntax and direction of traditional type casts versus function-calls, it would involve considerably more "unraveling" to work with the traditional style, as follows:
Something like (A)(B)...(Z) is some combination of casts and/or calls, which are necessarily divided with the casts on the left and the calls on the right (with one other entity in between). Supposing we just interpret everything as calls by default (since they happen much more often anyway), say we come across this:
(A)(B)(C)...
...We end up with call(call(A,B),C) (that's "call(LHS,RHS)"). Now suppose we see some expression after:
(A)(B)(C)x
...Well, in any (A)...(Z)x, we want a cast(Z,x) ("LHS,RHS" again). Therefor, any such cast(call(X,Y),Z) should be (recursively) converted to cast(X,cast(Y,Z)). Here is that conversion process for this example:
cast(call(call(A,B),C),x)
cast(call(A,B),cast(C,x))
cast(A,cast(B,cast(C,x))
"Ta-da"! And aside from the ...(Z)x situation, there are other instances where it becomes immediately clear that something is a type (e.g. the use of "array-sizing") (or perhaps something is obviously a function-call) in which case we know that everything (in parenthesis) before a cast must be a cast, and everything after a call must be a call.
This might not seem so bad, especially if I use a loop and a linked list to store the whole chain of it before deciding how to store it. HOWEVER, since we may only find out after the source is all parsed that "foo" is a type, the compiler would already have stored (int)(foo)(bar)(x) as a chain of calls, just to have to convert it further again (e.g. the work is done twice). ... All in all, I guess that's not terrible anyway, since most such situations are not only few, but trivial (who chains casts, anyway?).
...So I can do it, and it won't be too rough. BUT, the colon syntax is SO much more straight forward and would simplify the code required for handling it (e.g. function-call and type-cast syntax handling would not have to be tangled together). However, if people agree that having an already familiar syntax is worth that extra effort (more so than getting used to another unfamiliar but decent syntax which is easy enough to learn), then I will go for it.
...What say you? |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 21 Jun 2012 05:43:10 pm Post subject: |
|
|
Every time we've come up against something and there are two options, and one of them is more standard and fits with existing programming stuff I know, I always pick the one that fits with what I already know. Programmers are lazy; learning takes effort. That being said, I'm a little less concerned about this than I was about e.g., lambdas. If it's that much more complicated, colon syntax should be fine. I like (type:var).
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 22 Jun 2012 02:58:25 pm Post subject: |
|
|
I apologize to everyone who will suffer from this, but I am going with the following:
The colon-syntax for type-casts (type: expression).
Assignments and increments/decrements may NOT be embedded within expressions (must be whole statements), though assignments may be chained (a=b=c).
Variable declarations are not allowed within tuples (e.g. (char a, int b) = 'x',5), but tuples are allowed within variable declarations (e.g. int (a,b,c) = (1,2,3)).
NOTE: I have added a section for my "final notes" in the overview, and have temporarily put the order of operations at the end of the grammar. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 27 Jun 2012 02:49:56 pm Post subject: |
|
|
*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).
EDIT: 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). |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 02 Jul 2012 04:51:47 pm Post subject: GRAMMER COMPLETED! |
|
|
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). |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 04 Jul 2012 01:12:39 am Post subject: |
|
|
| ...So I apparently had my Type-Cast syntax flipped, even when I last posted about how it "had to be". I fixed it in the grammar (and edited that post as well). Also, I had apparently left the "return values" portion of function-related entities out (after removing a no-long-used sub-rule which used to have that in it). Also, I made other minor fixes to the grammar and overview. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 376
Location: Spokane, WA
|
| Posted: 09 Jul 2012 03:59:48 pm Post subject: NAME CHANGE |
|
|
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!
Last edited by shkaboinka on 09 Jul 2012 04:02:36 pm; edited 1 time in total |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 09 Jul 2012 04:01:13 pm Post subject: |
|
|
Why are you so obsessed with acronyms? Call it "Ketchup". Call the compiler "Mustard".
_________________
Shaun |
|
| Back to top |
|
|
|
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
© Copyright 2000-2013 Cemetech & Kerm Martian :: Page Execution Time: 0.050052 seconds.
|
![[t]](/forum/templates/Cemetech6/images/twitter.png)
![[t]](/forum/templates/Cemetech6/images/fb.png)
![[RSS]](/forum/templates/Cemetech6/images/rss.png)
