Author Topic: Antelope (formerly "OPIA") - A Polymorphic z80 language (Read 48548 times)

Nick · « **Reply #60 on:** January 29, 2012, 08:38:00 am »

that's true, certainly.. if you would keep your post to the point (in lists or so, instead of sentencces) it will be read more, and examples of games or other programs (simple ones though) would be greatly appreciated, and would get much more attention, since this is the point of omnimage i think..

shkaboinka · « **Reply #61 on:** January 30, 2012, 01:57:52 am »

Thanks for clarifying (I just thought that Omnimaga & Cemetech were just different sites, though both more communal that ticalc.org). I think that your suggestions would do me/OPIA well when it is ready to present. However, it's not ready to say "here it is!" ... but in announcing that it is upcoming, or allowing other to participate in the design (or discussion thereof), it would be beneficial to make it more readable / visual / involved / etc. Let me take just ONE paragraph to explain why this has not been much of the case yet (and then I will explain where/when this will come into play more):

The reason that my approach is so different from that of Axe (etc.) is that it is NOT a bunch of features crammed together. I have done my best to analyze features for their power, efficiency, usability, etc., doing my best not to include anything just because it looks nice or is familiar, etc. ... I am using strong principles of programming language and compiler theory to design a language that is as simple, expressive, powerful, understandable, and unrestricted as possible (which means "Ooh, can you put X into the language? I like X" has less sway than all those other factors). For example (skip rest of paragraph if you don't want one), questions about closures and coroutines led me to consider their necessity versus other techniques versus efficiency. Upon finding that they require the same internal mechanisms, I provided the "cofunc" as a clean and efficient way to do either, removing some of the headache and overlap that either present in their typical usage.

WHEN THE LANGUAGE IS IN PLACE (and at least on its WAY to being developed [e.g. the design already resolved]), then the language will need a LOT of contribution! Unlike Axe & Grammer, OPIA will NOT have any functions or libraries built into it. Using the core language, libraries (for graphics, input/output, math, OS calls, etc.) be written to extend the language by (1) tying directly into other tools/OS's, (2) providing direct access to other assembly resources, (3) embedding (hiding) assembly code into functions, or (4) using pure OPIA code to design new constructs, tools, etc. One is NOT required to know anything of assembly in order to use OPIA, since such integration techniques are only provided so that it CAN tie directly into other already existing tools (no matter where they came from). When I can provide something which can generate runnable code, I will provide some basic functionality for printing etc.; but I intend to involve as many people as want to participate when it comes time to come up with some sort of standard(s) and/or write some of the libraries that people are going to want. THIS is where people can be actively and freely involved in developing the language (through expansion) ... I, however, will design the core language (which I am mostly done with anyway). I will most certainly need to provide some more friendly documentation.

So far, I've decided that posting updates and opening things up for discussion is better than just doing it in the dark, since (1) I can get meaningful feedback from anyone willing to discuss internal theory/design, (2) perhaps I can find what would/would not be "acceptable" for people wanting to use the language, (3) people can see active design and get an idea for what is to come, while (4) building up a larger group of followers who will be anxious to help test it and develop the language further

EDIT: Perhaps I will provide some better examples before then though, so people can see what it would look like etc.

BlakPilar · « **Reply #62 on:** January 30, 2012, 07:06:31 am »

I know I'm coming in late to this (I didn't get the emails for some reason), but NanoWar, this isn't completely done. He wanted to get his ideas out there and see if they were something that people would use. If not, then he would have to change certain aspects of the language. I know how hard it is to structure a language in a way that is practical while still being fun (see Alpha.NET in my signature). That being said, it's not as simple as "just [writing] a pong game" for an incomplete language project

I do agree with you, however, that Omnimaga is more game-oriented while Cemetech is more hardware-/technology-oriented (though I do not frequent there as often as here).

Scipi · « **Reply #63 on:** January 30, 2012, 03:46:33 pm »

Hmm. I'd rather see what an actual programs source code would look like with what is done with OPIA thus far than an actual executable. That way, I think more programmers would be able to suggest what seems simple and what might be over complicated, and so on.

BlakPilar · « **Reply #64 on:** January 30, 2012, 04:00:33 pm »

Well, I know it's not a full program structure, but shkaboinka has examples of all of the features on the wiki overview.

Quigibo · « **Reply #65 on:** January 30, 2012, 04:52:13 pm »

There are advantages and disadvantages of both design techniques. Certainly by spending more time engineering a well thought-out syntax you end up with a more consistent language. There are definitely several areas of Axe that I wish I had planned out more before it became too late to change such as Boolean operators, function call syntax, variable referencing, and even token choice. You do however get the advantage of instant feedback by releasing earlier, not from a feature standpoint, but from an efficiency/trade-off one.

I think the best thing to at least build the parse tree part of the compiler (without releasing it) and add the features you have designed so far. If you're programming it correctly in a massively inheritable object oriented way, this should be extremely easy to add and remove features at around the same speed you can come up with them on paper. It also allows you to program in your language and get a feeling for how the actual flow will end up in the parse tree. Just a suggestion

BlakPilar · « **Reply #66 on:** January 30, 2012, 04:58:07 pm »

Quote from: Quigibo on January 30, 2012, 04:52:13 pm

I think the best thing to at least build the parse tree part of the compiler (without releasing it) and add the features you have designed so far. If you're programming it correctly in a massively inheritable object oriented way, this should be extremely easy to add and remove features at around the same speed you can come up with them on paper.

I completely agree. This is exactly what I'm doing with Alpha.NET, though I haven't had much time to work on it lately. From what I do have done, though, trees are much easier to navigate, parse, and optimize than arrays or lists.

shkaboinka · « **Reply #67 on:** January 31, 2012, 04:59:26 am »

Quigibo: I've had a few premature run-throughs with compilers before. Last time, I went through and changed some key rules which really affected parsing and verification rules for classes & interfaces. I do have a couple aspects already in place; However, the new design is free of MUCH of that red tape (since it lacks a type-hierarchy), so I might be able to put more up sooner (school etc. permitting)

BlakPilar: There will be a Tokenizer, Preprocessor, and a Parse-Tree (which indeed makes it worlds easier to parse and optimize. I will go a step further by tracing values across variables and allowing things to be marked as "interpreted"). Each will be modularized so that other tools can use them the compiler itself to analyze code at different levels. This compiler will NOT be tied into a GUI, but will allow optional arguments to specify file-paths, extra files to include, and which environment to use. Allowing these as compiler arguments means that they don't HAVE to be present in the source code (e.g. so that other tools/editors can organize things however they like, and then pass that information on to the compiler).

[General]: I want to reemphasize that OPIA is not "better" than other languages, though I do intend for it to be the most versatile and (computationally) powerful. I do this by carefully choosing flexible and efficient mechanisms necessary to make the language "limitless", while making the design as simple as possible. Unlike Axe or Grammer, OPIA does not offer a fully integrated environment with most of the tools you need to make a game; but OPIA is extensible to allow such things to be coded-in/linked-in so as to seamlessly integrate directly with/into any environment (and that is where people can contribute)!

Quigibo · « **Reply #68 on:** January 31, 2012, 10:18:10 pm »

Quote from: shkaboinka on January 31, 2012, 04:59:26 am

Quigibo: I've had a few premature run-throughs with compilers before. Last time, I went through and changed some key rules which really affected parsing and verification rules for classes & interfaces. I do have a couple aspects already in place; However, the new design is free of MUCH of that red tape (since it lacks a type-hierarchy), so I might be able to put more up sooner (school etc. permitting)

How are you creating the parser? Changing rules should be simply a matter of changing a line or so of code. When I wrote my python compiler, it was programmed as an LR parser using Bison as my Parser-Generator. You simply tell it the rules line by line and it generates an abstract syntax tree from any source or gives an error if it cannot match. Here is an example of what rules look like for a simple language:

Code: [Select]

input: 
      expr TOKEN_SEMICOLON

expr:
      expr TOKEN_PLUS expr
    | expr TOKEN_MULTIPLY expr
    | var TOKEN_ASSIGN expr
    | var

var:
      char
    | char var

char:
      TOKEN_A
    | TOKEN_B
    etc.

Changing a rule should be very very easy in Bison, even extreme changes! Again, I'm not sure what method you're using, but if you're doing recursive decent or some other inefficient method, I would recommend switching because a compiler-compiler will produce code that is faster and more accurate than a human would write, and its way easier.

shkaboinka · « **Reply #69 on:** February 01, 2012, 02:39:23 am »

Those tools certainly make stable and effective parsers; but I've seen the code for some of them (I do not recall which), and it looked very generated ... I prefer to do it on my own for the same reason that some people prefer to code in assembly. Sure those tools make it a lot easier and are already proven to work perfectly, but I don't think that necessarily makes them "better". Thought it is ridiculous code everything from scratch when the tools are already provided and proven; but being able to master those techniques means that you know when it might be better to make a custom version yourself (e.g I use my own LinkedList class because I found that java.util.LinkedList concatenates lists by converting them to arrays first!). Also, sometimes its better to have a custom structure that has all the general purpose features removed or works as needed without having extra layers ... but lets just settle on that I am doing it all manually because that's part of what makes it mine. And trust me, I know what it takes (experience and research) to make a solid parser & compiler, and how to do it efficiently (e.g. recursive decent, predefined Tokens with flags marking precomputed aspects, good parse-tree constructs, and keeping things modular). ... If anyone can do it, I can. I want to DO this.

The "change in grammar" from before was also a big change in the semantics of the grammar. The language was also particular about what could be contained where (e.g. whether classes, functions, etc. were abstract, virtual, static, etc.). After it was parsed, I also had to check for integrity between classes in regards to inheritance (things that had to be consistent or exclusive, etc.). This is also a sign that the grammar was not of a simple form ... which is one of many reasons that I like the Go-ish style much better than the C++/C#/Java style for a polymorphic language (especially one geared to such a low-level!)

shkaboinka · « **Reply #70 on:** February 02, 2012, 06:41:31 am »

I discovered something fundamentally wrong with how I present "confuncs" in my language: They are METHODS! ... In other words, I cannot just embed a function-call at the start and say it acts like a function. Therefor, I propose a new scheme which allows cofuncs to act as embedded-methods of a struct:

Code: [Select]

struct S {
   byte x;
   cofunc f(...) { ... } // f and g may contain yields
   cofunc g(...) { ... } // f and g have access to each other and x
}

s := S{1};
s.f(...);
s.g(...);

And there is a short form as well:

Code: [Select]

struct T { cofunc(...) { ... } } // the cofunc is an anonymous field of T
cofunc T(...) { ... } // This is a shorthand for the same thing above

t := T{};
t();

The benefits of this approach:
- A struct may embed multiple cofuncs like this (anonymous ones referred to as ".cofunc")
- These cofuncs count as methods (and are thus compatible with function-pointers and interfaces)
- These cofuncs may call each other or access other members of the struct (they "are" the struct)

On a side note, would it be nice to have ".x" be a shorthand for "this.x"?

BlakPilar · « **Reply #71 on:** February 02, 2012, 03:00:32 pm »

It all seems well and good to me, but could you explain the last two lines of the example to me? (The shorthand and the one below it.) I don't quite understand them.

As for the .foo() or whatever being shorthand for this.foo(), I think that's a great idea.

shkaboinka · « **Reply #72 on:** February 03, 2012, 01:33:44 am »

EDIT: I am going to change the form a bit to be closer to how it was before (i.e. still use the "cofunc" keyword). I am going to update the overview to reflect this, and modify this (and previous posts) to reflect it. TO ANSWER THE QUESTION (with modifications applied):

Code: [Select]

cofunc T(byte x : byte) { // THIS SHORT-HAND FORM...
   for(byte last = 0; true; last += x) {
      yield last;
   }
}

struct T { // ...REALLY MEANS THIS
   cofunc(byte x : byte) {
      for(byte last = 0; true; last += x) {
         yield last;
      }
   }
}

t := T{}; // make a T variable
t(1); // 0+1 = 1
t(2); // 1+2 = 3

You can also name cofuncs, and have multiple of them in one struct:

Code: [Select]

struct Foo { 
   byte x; 
   cofunc f(byte y) { ... } 
   cofunc g(char c) { ... } 
} 

f := Foo{1}; // x 
f.f(2); // y 
f.g('H'); // c

Embedding cofunc-definitions in a struct causes the struct to store the data needed to allow "yield" commands to work (i.e. local variables [like "last"], and the point of execution to continue from after the yield). In this case, the cofunc is anonymous (has no name), hence "t(1)" in the first part versus f.f(2) in the second.

BlakPilar · « **Reply #73 on:** February 03, 2012, 10:41:58 pm »

Ahh, okay, now I get it. ~~Now, will func still be valid, or is it just cofunc?~~ EDIT: Nevermind

shkaboinka · « **Reply #74 on:** February 04, 2012, 01:39:54 am »

BlakPilar: Just to be very clear on what's what and usage:

Code: [Select]

struct S {
   func fp(byte); // function-pointer
   func mp(this, byte); // method-pointer (caller is passed to "this" automatically)
   cofunc cf(byte x) { ... } // member cofunc ("this" is implied)
   // NOTE: cf is NOT directly modifiable (it changes after each 'yield')
}

func f(*S, byte x) { ... } // non-member function
func S.m(byte x) { ... } // non-member method 

s := S{f,m}; // cf is not in the list (not a pointer)

// To show that they are all of type func(*S,byte):
s.fp = s.mp = f; // all point to f
s.fp = s.mp = S.m; // all point to S.m
s.fp = s.mp = s.cf; // ... (Yes, even the cofunc!)

// To show how call syntax differs:
s.fp(s,5); // pass an *S directly (does not have to be s!)
s.mp(5); // s is automatically as "this"
s.cf(5); // s is automatically passed as "this"

NOTE: cofuncs cause the containing struct to contain a tail-call to the underlying function (and any other data needed to be saved between 'yield' commands). However, the containing struct is passed as "this" (rather than just the cofunc itself). This allows the cofunc to access the other members of the struct (i.e. the implication of declaring a cofunc WITHIN a struct is that you are giving a function-behavior the actual STRUCT rather than to some separate cofunc WITHIN the struct). You COULD declare a cofunc separately and then have a struct contain one, but then the cofunc takes a reference to itself rather than the struct:

Code: [Select]

cofunc CF(byte x) { ... } // cannot access y in there
struct S { byte y; CF cf; }
s := S{5,CF{}};
s.cf(5);
ptr := s.cf; // ptr is a func(*CF, byte), rather than a func(*S,byte)

Author Topic: Antelope (formerly "OPIA") - A Polymorphic z80 language (Read 48548 times)

Nick

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

BlakPilar

Re: OPIA - A full OOP language for z80

Scipi

Re: OPIA - A full OOP language for z80

BlakPilar

Re: OPIA - A full OOP language for z80

Quigibo

Re: OPIA - A full OOP language for z80

BlakPilar

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

Quigibo

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

BlakPilar

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

BlakPilar

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80