Antelope (formerly "OPIA") - A Polymorphic z80 language

[shkaboinka]

By byte- and uint-prefixed strings, do you mean that number would be the length of the string?

Correct:
"banana" // .db "banana",0
r"banana" // .db "banana"
b"banana" // .db 6,"banana"
i"banana" // .db 6,0,"banana" ;z80 is "Little-Endian"

[BlakPilar]

Alright, that's what I thought. Everything seems good to me!

[shkaboinka]

Ok, I've basically finalized all the (more than very trivial) language issues ... I am just going to repost:

Some final notes before I begin in (May or June?). THESE ARE DECIDED (tentatively):

The new numeric datatypes are byte, sbyte, int, and uint.

String literals can take on different forms:
::: "null terminated string"
::: b"byte-prefixed string"
::: i"int-prefixed string"
::: r"raw string"

Numeric literals are of type "int" by default. Type-casts can be used to be explicit: (byte)5;
Hexadecimal and Binary literals are prefixes with 0x and 0b, respectively, and default to type "byte" or "uint" types according to the number of digits used (so as to reflect a literal bit representation).

Dereferencing is now on the right-side:
::: *[]byte pa;    (*pa)[idx];
::: []*byte ap;    *(ap[idx]); // or just *ap[idx]

Constant (immutable) variables are defined with "const" in addition to the datatype.
Constant expressions (pasted in like macros) are defined with "const" alone.
It is illegal to mix "const" or "volatile" with the ":=" operator.

There are standard-, BASIC-, and iterator-style for-loops:
::: for(init; condition; update)
::: for(var: start, end, inc) (inc is optional)
::: for(var: array); for(var: someYieldyCofunc)

The inferred type of an array literal works as follows:
::: []T{...} = A static array of the given values
::: &[]T{...} = Pointer to the given static array
::: new [n]T = Pointer to a new (uninitialized) array allocation
::: new []T{...} = Pointer to a new array allocation (values copied from static array)

Arrays with the (first) dimension omitted ([]T or [,n]T) are pointers.
Arrays of the form [ , ,...] are rectangular (stored in one static allocation).
Arrays of the form [][][]... are jagged (the "inner" arrays are stored as pointers).
Arr[3..6] is a shorthand for the tuple expression (Arr[3], Arr[4], Arr[5]).
Tuples will remain "auto-unpacked", and no tuple-variables allowed.

Method receivers ("this") are ALWAYS (intrinsic) pointers.

Methods may be defined within structs, just as in Java/C# (compact/familiar).

There will be an "x@value" syntax for embedding variables within array literals.

Addressing goes on the LHS and applies to the whole RHS (e.g. &a[n] is &(a[n])).

Entities may not be defined within each other (e.g. no structs within structs, etc.).

Expressions cannot contain statements (declarations, assignments, calls, var++/var--).

Anonymous functions may may not refer to (non- static/const) external local variables.

All code is precomputed as much as possible (without unrolling loops or recursive calls).

The $ operator Requires something to be interpreted, including loops and recursive calls.

Bridge methods will be inserted for multiple "inheritance" of anonymous fields, as needed.

Control-flow constructs will indeed require parenthesis (avoids parsing conflicts with literals).

No "static" members of anything (but static local vars and static initialization blocks are allowed).

Entites Have Global Accessibility If They Are Capitalized, and namespace accessibility otherwise.

Look-Up-Tables (rather than Jump Tables) will be used with switches and if-else chains as possible.

Methods can only be defined for "identifier" types (structs, primitives, etc., but not funcs, arrays, etc.).

Namespaces may be nested ("Outer.Inner" syntax), and there will be a "using Namespace" mechanism.

Self-Modifying code will be used with cofuncs and switch-variables (Will consider an option to disable it).

Explicit variable addresses can be nominal (@"address") or refer to another variable (@x or @arr[n].foo).

No exception-handling or "try-catch" mechanism (use multiple return values or create an "Exit()" instead).

Type-casts will be represented traditionally (e.g. "(byte)(a+b)").

"Extra" Parenthesis are not allowed within datatypes ("func(...)" requires them, but []*T are *[]T are unambiguous).

Function pointers without any return values may point to functions with return values (e.g. func(byte) pointing to func(byte):byte).

Values will be passed/returned in registers such that any two functions with the same pattern of arguments will use the same registers for them.

Default arguments (and struct members) must come last, and will be embedded in functions so they can be pointed-to as their reduced versions.

An anonymous (nameless) struct/interface/cofunc/func within a namespace will take on the name of the namespace (e.g. "List myList" rather than "ListNameSpace.ListStruct myList"). This also gives namespace values ("List.staticValue") the feel of Java/C#'s static class members.

[DJ Omnimaga]

I didn't check everything out, but is for(init; condition; update) kinda like the start value, then a boolean condition (eg A == 50) then the operation to do if it is (and exiting the loop)?

When stuff is finalized about the language itself, it would be great if you made some document to include with OPIA release that gave syntax examples of the language. (If you ever have a site about the language doc, animated screenshots + program examples would definitively be cool too.

[shkaboinka]

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.

[shkaboinka]

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

[BlakPilar]

Are you using something like ANTLR, or are you making a custom parser?

[Matrefeytontias]

Do you have the compiler working ? Can you post an example of code and its executable ?

[BlakPilar]

He's only on the grammar right now, so no, the compiler is not currently working.

[shkaboinka]

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).

[BlakPilar]

Yeah, that's what I'm doing with my compiler. I was using ANTLR, but I wasn't satisfied with its error reporting for the C# port, so I decided to write everything myself. I love the freedom of being able to customize everything. My lexer is done, and I'm working on the parser right now. My only problem is I don't have an exact syntax for it yet lol.

I took a quick look at your grammar before, and it looks good so far. I'll be able to take a better look at it later, though.

[shkaboinka]

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.

[BlakPilar]

Sure! But yes, now wouldn't exactly be a good time for me either. My code isn't exactly the neatest as of right now. My language doesn't need a preprocessor, but the way I have everything set up, I'd like to think implementing one wouldn't be too hard. Plus my lexer isn't 100% done; it's more like 97%. I just need to add support for decimals / floats and hex.

[shkaboinka]

UPDATE: I basically have all the structural classes (for the syntax tree) figured out now! Take a look!

[BlakPilar]

Nice! That's similar to what I'm doing, except I only have statements and expressions. I have a method I created for extracting token patterns that I found is pretty useful, at least for namespaces. Yours is looking good, though!