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

shkaboinka · « **Reply #45 on:** January 07, 2012, 02:04:09 pm »

Sort of... they are different types altogether. A 'Foo' can be assigned values from the enum declaration (or from other Foo variables). A 'switch(Foo)' just borrows the labels of Foo, but assigns separate values (i.e. addresses of actual cases in a switch somewhere). In fact, given two 'switch(Foo)' variables g1 and g2, g1 and g2 use DIFFERENT values because they are associated with different switches. That is, g1.X is the address of "case X" where g1 is switched on (switch(g1) { case X: ... }), and g2.X is the address of "case X" where g2 is switched on. Therefor, though they appear to have the same type, g1 and g2 cannot be assigned each other's values, neither can they take values from a 'Foo'.

Code: [Select]

enum Foo {X,Y,Z}
switch(Foo) g1, g2;
Foo f;
...
switch(f) { ... } // f is used as an INDEX for a look-up-table for this switch
...
switch(f) { ... } // ...and again in this switch.
...
switch(g1) { // No index. This is simply 'goto (g1)'
   case X: // g1.X refers to the address of this location in code
   case Y: // g1.Y refers to this address, etc.
   ...
}
...
switch(g2) { ... } // Likewise, g2 will have it's own switch, and it's own X,Y,Z
...
switch(g2) { ... } // ILLEGAL! (g1 and g2 are variables for ONE specific switch)
...
g1 = g2.X // ILLEGAL, because that would cause the switch on g1 to goto g2's "case X"

... There is really no point in defining an enum just to make a switch variable on it. The code above might as well have just said 'switch{X,Y,Z} g1, g2;'. The only reason I allow it is that, supposing you already HAD an enum defined, and the cases were related conceptually to the enum, then you might as well just use the same labels (and rather than copying each label, you can just plop the enum name into the switch-variable type). Again, a switch "on" an enum only mimics that enum by using the same labels for its values. ... But since it's only a mimic (switch variables cannot interact with other variables because they each use a unique set of case-addresses), is it worth allowing the mimic at all? That is, I could just allow the switch{X,Y,Z} g1 type of declaration if that would be less confusing.

BlakPilar · « **Reply #46 on:** January 07, 2012, 02:15:22 pm »

Ooohhh, okay, I understand now. That would be awesome if there were both ways!

Also, another question that I've been meaning to ask is will you provide built-in methods for things math and output? Like in .NET there's the static Math class where you can do things like Math.Pow(2, 6); which is the same as 2⁶. And by output, I mean like Print, PrintLn, turning pixels on buffers on/off, etc.

shkaboinka · « **Reply #47 on:** January 09, 2012, 03:06:19 am »

The core language will only contain the mechanisms that are fundamental to the language. In other words, there will be no built-in math, input/output, or other utility functions etc. built in. The only exception might be some string-manipulation (there should be a post somewhere about a "StringBuilder" which can be used to concatenate strings) and possibly some array-copy stuff.

HOWEVER, once the CORE language is finished, then libraries can be written for that kind of stuff. ... And that is where I will need a lot of help (or just let it loose and see what flies)

EDIT: On a side note, IS NOBODY DISAPPOINTED THAT I DROPPED THE JAVA/C#-ish VERSION OF OPIA? (I just want to make sure everyone is still good with it; or be able to convince otherwise). I do intend for OPIA to be much faster and more versatile (and much more optimizing) than Axe or Grammer, or anything else aside from pure assembly

I have recommitted my source with some error-fixes. Preprocessing should not be complete, with errors marked correctly. The result is a list of tokens (which the syntax-tree-building portion of the compiler is to process), containing (in order):
- Error tokens (if any)
- #allocate and #assembly statements (as applicable to environment)
- all other source tokens (as applicable to environment)
- Token.EOS (the "end of source" token).

EDIT-EDIT: I adapted some code from Google Go into OPIA code as a demonstration of what OPIA can do (and how to adapt their "gofuncs" and channels into cofuncs, and how cofuncs can be used as asynchronous processes). This is a prime-number sieve:

Code: [Select]

cofunc generate(:word) { for(i := 2; true; i++) { yield i; } }

cofunc filter { func(:word) in; word prime; } (:word) {
    while(true) { i := in(); if(i % prime != 0) { yield i; } }
}

cofunc sieve(:word) {
    in := new generate{};
    while(true) {
        prime := in(); yield prime;
        in = new filter{in, prime};
    }
}

func main() {
    nextPrime := sieve{}; // Print first 100 primes:
    for(i := 0; i < 100; i++) { Print(nextPrime()); }
}

BlakPilar · « **Reply #48 on:** January 09, 2012, 04:58:38 pm »

Ahh, okay. What language would the libraries be written in? OPIA, ASM, other?

As for the language drop, I'm okay with it; I like learning new languages

(I'm studying Russian by myself right now

)

As for the example, do we not need to declare a value's type? (nextPrime, prime)

C0deH4cker · « **Reply #49 on:** January 09, 2012, 05:29:43 pm »

I believe that those do not need have their respective types declared because prime and nextPrime are instances of cofunctions, due to the new statement.

BlakPilar · « **Reply #50 on:** January 09, 2012, 05:31:35 pm »

Ahh, okay, I didn't look hard enough lol. Thanks.

shkaboinka · « **Reply #51 on:** January 09, 2012, 09:05:27 pm »

Actually, they do need to (and did) have their types declared, just like any other variable. The ":=" operator tells the compiler that a variable is being both declared and initialized, and to infer the type from the initialization value. At first I was not sure about having both "=" and ":=" operators, but I've found that it indeed makes it easier to code!

Code: [Select]

cofunc generate(...) { ...i := 2;... } // word i = 2;

cofunc filter(func(:word) in ...) { ...i := in();... } // word i = in();

cofunc sieve(...) {
   ...in := new generate();... // *generate in = new generate();
   ...prime := in();... // word prime = in();
}

func main() { ...nextPrime := sieve();... } // sieve nextPrime = sieve();

The only bearing on "new" is that, without it, that function would overwrite the same static variable each time; so I used "new" to say "allocate new memory for this" (which actually makes the variable a pointer, since that returns an address ... another nice thing about automatic stuff like that)

BlakPilar · « **Reply #52 on:** January 09, 2012, 09:18:18 pm »

Woah, that's a really helpful feature!

shkaboinka · « **Reply #53 on:** January 10, 2012, 01:46:15 am »

What's more, it can also tell when dereferencing (*) and addressing (&) is implied. If you give the current overview a good look, you might find some surprises like that (I am a bit brief in it sometimes) :)

http://code.google.com/p/opia/wiki/Overview

EDIT: Here is another change:

   // ===== Previous setup for cofuncs =====

   cofunc ABC(a:b:c) { ... } // a,b,c represent init args, call args, returns

   cofunc B(b) { ... }    // short for  B( :b: )
   cofunc C(:c) { ... }   // short for  C( : :c)
   cofunc BC(b:c) { ... } // short for BC( :b:c)

   cofunc AB(a:b: ) { ... } // no short form for this
   cofunc AC(a: :c) { ... } // no short form for this

   func(b:c) f = BC(); // funcs declared with same call-args & returns

   // ===== Current setup for cofuncs =====

   cofunc ABC{a}(b:c) { ... } // a,b,c represent init args, call args, returns

   cofunc B(b) { ... }      // previously  B( :b: )
   cofunc C(:c) { ... }     // previously  C( : :c)
   cofunc BC(b:c) { ... }   // previously BC( :b:c)
   cofunc AB{a}(b) { ... }  // previously AB(a:b: )
   cofunc AC{a}(:c) { ... } // previously AC(a: :c)
   func(b:c) f = ABC{a}; // func declaration matches that of cofunc ABC

   // ===== Example of using cofuncs as struct-funcs =====

   cofunc blah { byte x, y; } (byte z : char) { ... }

   b := blah{1,2}; // Just like a struct!
   b.x = 5;

   char c = b(3);  // Just like a func!
   func(byte:char) f = c;
   func(byte:char) f2 = blah{3,4};

shkaboinka · « **Reply #54 on:** January 12, 2012, 10:09:54 pm »

(whole post edited ... again)

Ok, I am going to reinforce some new rules:

(1) Struct members with default values must come last in the struct. When initializing a struct instance, the initial value for a particular data member may be left out of the list only if the values after it are also left out of the list. This includes function bodies for virtual methods (though "= null" or "= otherFunc" may be used as default values for member-functions). Also, default values can be expressions (e.g. the sum of the other values)

(2) Cofunctions are declared as a combination of a struct and a function: "cofunc name { members } (args : returns) { body }", but "{members}" may be left out. They are initialized the same as structs.

(3) Switch-variables may be declared directly, but not "on" other enums (just "switch{X,Y,Z} foo"). Values will be assigned directly by name ("foo=X" rather than "foo=foo.X"). The ":=" operator is not allowed for switch variables, since the initial value can be given directly by name anyway ("switch{X,Y,Z} foo = X"). The compiler will treat these assignments specially, so that "foo=X" does not interfere with some other "X".

(4) "Methods" are only allowed for structs, cofuncs, and interfaces ("single identifier" types), so as to avoid strange dot-expressions on functions and numbers, etc. This does not stop anyone from making a struct containing some other type as a work-around though (since the storage an manipulation would be the same; especially if the member is anonymous)

shkaboinka · « **Reply #55 on:** January 23, 2012, 07:21:14 pm »

Ok, I've made an update:

* Anonymous fields DO bring their methods into the containing struct (i.e. they can be used to fulfill interface requirements)

* Changed "virtual methods" to "method pointers", and altered the syntax from "func blah(...)" to "func(this,...) blah" (so that they just act as special function-pointers). There is also no "declared within" paradigm (i.e. the "with or without a body" thing), though they MAY be given a default value just like anything else (e.g. " ... = func(...) { ... }").

* Made some minor formatting adjustments with the changes (shortened some examples, but added some others)

I did not mention it in the overview, but bridge-functions will have to be used to map non-initial anonymous fields to their methods when they are used with interfaces.

NanoWar · « **Reply #56 on:** January 27, 2012, 05:48:46 am »

Rather than getting bombed with your short brainstormed ideas you post here every week, I would love to see how you manage to provide basic functionality like any assembler (flow control, primitive data types, ...). I'm just getting lost in you project when I see "func(this,...) blah" all over. I might have gotten this wrong, but to me it seems too big of a project to master on your own.

Write a pong game in OPIA for TI84+, that would be a good starter to get people's interest (as you can see, barely anybody replies to your posts here, but this should change eventually).

I am however hugely impressed by this project, I just don't see it very clear. Do you have a feature breakdown? I dont want to browse your overview that you link to in every post

.

Keep up your work.

DJ Omnimaga · « **Reply #57 on:** January 27, 2012, 10:15:21 pm »

Quote from: NanoWar on January 27, 2012, 05:48:46 am

(as you can see, barely anybody replies to your posts here, but this should change eventually).

I think it's more due to the post lenght. A lot of people tend to be busy, have troubles following long text or in Omnimaga case, have language barrier to overcome. There are also the ones who are lazier or are not as tech-savy and can't help as much. As a result, they go TL;DR on the posts. Those that do will usually skim through them and do short replies.

When Iambian posted Escheron: Shadow Over Rangaroth RPG updates, unless his post included a screenshot, he rarely got any reply because his posts were too long, even though it had grayscale graphics and lots of features.

That said I myself would like to see the language in action eventually, even if just small programs.

shkaboinka · « **Reply #58 on:** January 27, 2012, 10:46:35 pm »

Since I am still developing it, I use my Overview to lay out every single aspect (in detail) as a representation of what I have so far (that way, none of it just becomes lost thought) ... I've been working on designing a language since 2004 now (that means tons of research and experimentation). This is going to be the language that I've meant for previous attempts to be, and much more ... Trust me, I'm being thorough because I know what it takes; not because I'm crapping out ideas left and right (though I started there)

These posts are a way for people to see my thoughts as I design this, and contribute responses (e.g. intelligent opinions about what is/isn't useful/understandable/etc.). This is helpful because I hope to offer a dimension of z80 Calc programming not yet realized. However, I understand that my examples are too abstract for most people (focusing more on intricacies than realistic usage, because THOSE are the details I have yet to polish up). ... The purpose of my discussion is not so much to discuss how to use OPIA, but to discuss compiler/language design/theory directly, with OPIA being a realization of that design. Some of it is very dry and lacking explanation because I figure that people can look at the (constantly updated) overview to reference what I mean (that is partially the point of the overview right now).

However, I am SO close to having it all set, so I will try to wrap it up. Hopefully you'll see more coding being done soon (on the compiler, I mean; it currently only has some very foundational stuff). As I have more testable stuff, then perhaps I can focus more on giving people something that actually DOES something (and yes, example programs like PONG or something). I do apologize for all the convoluted code; I've been hammering out intricacies rather than trying to provide realistic examples. I figure that the overview provides all details, but is not meant to teach people how to program (so it's very dry) ... I realize that the lack of useful examples makes it difficult though, so maybe I will have to do better at that

... I kinda like the overview to be cut and dry though, since it's meant to be "THE" language definition. Perhaps I can make some tutorials/examples/etc. as things progress though.

By the way, there has been responses and discussion on some of these topics (especially anonymous fields) on other sites. I post it all everywhere though so that nobody is left out from knowing what is being discussed or changed. I will stop posting links everywhere though (I had my reasons; but now I have reason not to, thanks).

NanoWar · « **Reply #59 on:** January 29, 2012, 08:28:13 am »

Hey I didn't expect some good comments on my *rant*, very cool (constructive post, Mr DJO!).

What I wanted to get across is that if you provided simple approaches to OPIA more people (programmers, unfamiliar with compiler theory) would join the conversation. I would say that community support and help is the key requirement to finish such a huge project, as you can see with Axe. Axe in particular was build from the view of the users, the programmers. OPIA looks like a language build from fewer people and from a more theoretical point of view, which is just different.

I dont know with techniques other people would *like* to use for programming TI calculators, but asking them to participate in building a language sounds very good to me. How many people know your ideas from 2004?

Cemetech is more with you I guess, since they are techies

, but omnimaga for example is a game oriented community (isn't it?) and showing Pong in OPIA would raise my attention enormously, and maybe other's too. Furthermore, good luck.

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

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

C0deH4cker

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

shkaboinka

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

NanoWar

Re: OPIA - A full OOP language for z80

DJ Omnimaga

Re: OPIA - A full OOP language for z80

shkaboinka

Re: OPIA - A full OOP language for z80

NanoWar

Re: OPIA - A full OOP language for z80