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

0 Members and 1 Guest are viewing this topic.

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #150 on: September 27, 2012, 06:39:50 pm »
I've decided to forego the idea of traits for Antelope. It's a great idea, but I found that most of the same expressiveness is already available from the fact that methods are declared separately, interfaces are applied automatically, and parametric types fill in the rest.

Some other changes I may make:
 * Namespaces may have type-parameters (namespace Foo<T>;) so as to build setups more generically (not only would you not have to do this to every method, but you could also have static/global T values).
 * Optional Constructors: This would change construction to use parenthesis, and optional constructors (and destructors?) would be declared within structs:
Code: [Select]
struct Foo {
   int x; int y;

   new(int xArg, int yArg = 5) { // Constructor
      x = xArg;
      y = yArg + x; // Now you can map values differently
   }

   delete { ... } // Destructor
}

f1 := Foo(1,2); // x=1, y=1+2
f2 := Foo(1); // x=1, y=1+(5)

struct Bar { int x,y,z; } // Constructors not required.
b := Bar(1,2,3);
(Another option would be Kotlin's approach)

Some other ideas I'm toying with:
 * Changing lambda syntax from (args)=>code to { args => code } (and from =>code to { code }). I'd only do this so I could allow these to come AFTER function-calls when it is the last argument (Kotlin does some fancy stuff this way). Call(1,2,=>{code}) would become Call(1,2) { code }
 * Singleton objects (e.g. "object x { ... }" declares x like a struct, but that x is also the one and only instance of it)
 * "Class (struct) objects" as in Kotlin - a struct may contain a singleton object, which is referred to externally by the class name itself. This can be used to encapsulate "static members", but be referred to as a variable. This object can compose (inherit) from another struct for added functionality.
 * Change variable syntax so that types come after a colon (func f(x:int, y:int, z:int = 3) { ... }). This matches how return-values are given, and would make parsing types much easier (which is also true with constructors, since then Foo{1,2} becomes Foo(1,2) and can be parsed as a function-call). Also, this makes "A := B" more sensible for type-inference, since the type is "left out".

The only other thing I am debating is whether "virtual" functions should be stored directly within structs, or accumulate in an array as a "vtable" (C++) aka "class descriptor" (Java). I'm wanting to just keep them as pointers, because I want the language to be VERY oriented around using interfaces INSTEAD of using that kind of "inheritance". This allows embedded function-pointers to count as methods, and it is still POSSIBLE to construct a vtable (e.g. to mirror some hypothetically already compiled setup if necessary).

Thoughts?
« Last Edit: September 27, 2012, 06:45:44 pm by shkaboinka »

Offline aeTIos

  • Nonbinary computing specialist
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3913
  • Rating: +184/-32
    • View Profile
    • wank.party
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #151 on: September 28, 2012, 06:18:46 am »
This is coming along quite nicely. Do you have any ideas when you might release a beta? (stab me if you said anything about this in previous pages)
I'm not a nerd but I pretend:

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #152 on: September 28, 2012, 02:10:48 pm »
It will probably be a while: Now that I have a full-time software development job and a newborn baby, this project is officially on the back-burner (though I still poke at it between the cracks when I can).

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #153 on: September 29, 2012, 12:02:27 pm »
Clarification of changes:

 * Namespaces will be allowed to have type-parameters.
 * Constructors will be as just explained in previous posts.
 * "Virtual functions" are stored directly in their container as function-pointers.
 * Functions can be mapped to other functions without relisting arguments (we can discuss syntax: "func x = y" or "func x(args) = y").
 * Interface functions may have default bodies; Interfaces may also contain data members (stored "by value"), which may have default values. This might result in the "func" keyword being required in interfaces again though.
 * CONSIDERATION: I'd like to remove "anonymous members" from structs, and instead (1) Allow datatype names to be used as variable names, and (2) Have structs automatically "inherit" the properties (i.e. members and functions) of ALL their inner members (with any conflicts having to be resolved explicitly):

Code: [Select]
// OLD:
struct A { int x, y; }
struct B { A; int y; }
b := B(A(1,2),3);
// b.x == b.A.x == 1
// b.A.y == 2
// b.y == 3

// NEW:
struct B { A A; int y; }
// ...Everything else is the same

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #154 on: October 17, 2014, 02:28:01 am »
... So it's been quite a while (getting married, having two kids, and a dog, and starting a career tends to change priorities), but I've been keeping this project going occasionally, and paying a lot more attention to it in recent months. There have been LOTS of changes (again), and I've been posting on Cemetech and made lots of updates to the language grammar tinyurl.com/z80antelope (though everything else is way out of date). Maybe sometime I'll post a synopsis of what has changed, and bring this thread back life, too!

Anyway, I do intend to (eventually) finish this, and at least have fun along the way discussing and sharing my thoughts/adventure in programming language design :)
« Last Edit: October 17, 2014, 02:30:28 am by shkaboinka »

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #155 on: October 18, 2014, 08:53:42 am »
Wow, that's a lot of change O.O

Nice to see you back on it, do you have any idea when we will be able to generate a simple executable written in Antelope ?

Also, do you think this could be used to write KnightOS programs ? That would be awesome !

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55832
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #156 on: November 04, 2014, 01:36:17 am »
It's nice to see you back indeed. Also congrats on getting married and the carreer stuff. :) Also Matref brings up a good point. On TI-OS, it will be very hard to compete against Axe, TI-BASIC and ASM (even C can barely even do it), but KnightOS lacks a programming language for now, as far as I know, so this could be a good opportunity to make Antelope KOS-compatible. Of course, TI-OS compatibility would be nice too for a bigger audience.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF



Official Website |T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify

Offline Scipi

  • Omni Kitten Meow~ =^ω^=
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1547
  • Rating: +192/-3
  • Meow :3
    • View Profile
    • ScipiSoftware
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #157 on: November 05, 2014, 12:15:58 am »
I was wondering a few months ago what became of this. Great to hear it's still alive!

Imma Cat! =^_^= :3 (It's an emoticon now!)
Spoiler For Things I find interesting:
Spoiler For AI Programming:
Spoiler For Shameless advertising:

Spoiler For OldSig:





Spoiler For IMPORTANT NEWS!:
Late last night, Quebec was invaded by a group calling themselves, "Omnimaga". Not much is known about these mysterious people except that they all carried calculators of some kind and they all seemed to converge on one house in particular. Experts estimate that the combined power of their fabled calculators is greater than all the worlds super computers put together. The group seems to be holding out in the home of a certain DJ_O, who the Omnimagians claim to be their founder. Such power has put the world at a standstill with everyone waiting to see what the Omnimagians will do...

Wait... This just in, the Omnimagians have sent the UN a list of demands that must be met or else the world will be "submitted to the wrath of Netham45's Lobster Army". Such demands include >9001 crates of peanuts, sacrificial blue lobsters, and a wide assortment of cherry flavored items. With such computing power stored in the hands of such people, we can only hope these demands are met.

In the wake of these events, we can only ask, Why? Why do these people make these demands, what caused them to gather, and what are their future plans...

Offline aeTIos

  • Nonbinary computing specialist
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3913
  • Rating: +184/-32
    • View Profile
    • wank.party
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #158 on: November 08, 2014, 09:38:09 pm »
Great to hear this isn't dead. I'm still quite excited to see how programming in this language is gonna be :)
I'm not a nerd but I pretend:

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #159 on: November 02, 2017, 04:04:36 pm »
Great to hear this isn't dead. I'm still quite excited to see how programming in this language is gonna be :)

I regret to inform that this is dead; but mainly because I have something better.
I hope you'll be excited to see what programming (or computering at all) in a fully-dynamic system is like.

To save time, I'm going to paste what I've said elsewhere about the end of Antelope and the start of SomethingNew (2 posts).





(Pasted from elsewhere):

Sorry for abandoning this, especially after all that went into it. This is mainly because life happened. However, there is much learning/thought to reflect on; so here are some of my reflections:

1. Top features I've identified that I'd love to have in a language:
A  - First-order functions & lambda syntax (C# linq queries simplify even further!)
B - Functions that can yield values and resume from the same point (aka "coroutines", "generators", or C#'s "enumerators").  My "cofunctions" (not the same as the mathematical term) took this a step further by reifying the function-object ("functors" in other languages) allowing direct inspection/mofification of the entry-points and current "position", and also letting these function-objects to be emedded within other objects with full access to other members and vice versa.
C - Code that is interpreted / pre-compiled at compile time. I found this is BEST done in terms of all the built-in language features, rather than providing a separate syntax/language JUST for interpreted code. LISP does this by allowing macros that have the full power of the full language & other code. The D language does this very well by allowing meta-operations on the code using regular D code itself.
D.i - Use of "interfaces" to allow objects of ANY type to be used somewhere, so long as it has the correct members (Google's "Go" does this well). This provides the feel of dynamic "duck" typing, but with compile-time static type-checking.
D.ii - Ability to provide "default" members of interfaces.
E - "Traits" - that is, reusable blocks of code (object definitions) that can be combined statically, but WITHOUT introducing an inheritance relationship; it's just a clean mechanism for code-reuse. Traits are more refined than "Mixins", because you have full control over how to resolve conflicting names when combining multiple traits, and you can also map things differently (e.g. use a trait that provides behavior X and requires behavior Y, but provide "Z" in place of Y, or take X but call it "W"). Scala's "traits" are actually Mixins, because they do NOT allow any control over mappings, and they manipulate runtime inheritance hierarchies rather than combine code statically.
F - Reflection using "attributes" (as in C#; "annotations" in Java). This essentially treats the parts of a program like objects, allowing you to attach custom properties and behaviors to parts of the AST (e.g. to a "class"), without any impact on the RUNTIME entities that the relate to. In C#, this is done by creating runtime representations of everything (e.g. you can inspect classes and their members dynamically at runtime); but I was having this all be accessible at RUNTIME. That is code, code that can manipulate / be conditional on other code at compile-time. The D language does this very well. Languages that are self-hosting ("bootstrapped") like LISP or REBOL do not NEED reflection, because everything is already in the same "layer".
G - Default arguments for functions. My special technique for this is to insert the assignments of default values as extra instructions at the top of the function, and have multiple entry points in the function. To use all defaults, the function is entered at the "top"; when one default value is overridden, the function is entered "after" that default assignment. This not only saves code space, but allows the function to be referenced as EVERY sub-set of function type by referring to the correct entry point (e.g. F(A, B=X) is an F(A) and an F(A,B)). C# handles defaults by manually inserting the default values at all the call-sites, which means that the calling code can be "wrong" if the actual function-definition is separately recompiled with different defaults.
H - Function closures. I accomplished this through the "cofunction" implementation (B), though I had decided to remove them as an explicit language feature and instead have the compiler "detect" when to use them. That is, any function declared inside another function or class that references contextual data would automatically create a function-object to track it (or embed this data in the parent object, as applicable).
I - Generalization between functions and methods. Most languages do this by making methods a generalization of functions (e.g. the D language) by having the "this" argument count as the "first" argument (e.g. an O.F(A,B) is also an F(O,A,B)); but I did this by making functions a generalization of methods (e.g. an F(A,B) is also an <null>.F(A,B)) by reserving a special register (IX for z80) for passing the "this". This allows something that takes an F(A,B) to take an O.F(A,B) (JavaScript allows this by resolving "this" separately the function arguments). This also ties into J:
J - Generalizing all aspects of a source program into an object model. That is, a "class" and its static members are actually stored as an "object" which can be passed around or even inherit from other classes. Namespaces (including the default one) are also objects like this, and so all global/namespace-level declarations are members of some object (and thus all functions are "methods" -- but the passing of "this" is optimized out of the compiled code, because the allocation of these namespace "objects" is statically determined and thus so are it's members). This also allows one to define the namespace of a whole program (or part of one) to inherit from another class or compose traits into it, thus bringing OOP facilities to the level of the whole program.

...The above started as a 3 item list of 3 sentences. I forgot how much I put into this!...

2. I'm glad to see other languages/tools available, even though I didn't finish this one.
When I started, there was NOTHING like this, and mostly I really wanted to introduce a more general/full/open-ended language than the built in TI-BASIC (without assembler being the only other choice) so that others could experience the joy of programming on a fully-programmable device that is accessible to many. ... But since then, there is AXE, GRAMMER, and perhaps others, and that makes me happy and reduces my urgency. Big props to Xeda and Kevin for that!

3. ...I've had a bit of a perspective change on "language", which makes it hard to want to invest too much into one. I've been following past/present key figures such as Jim Coplien, Rich Hickey, Bret Victor, Alan Kay, Christopher Alexander, Richard P Gabriel, etc. (I actually found a GOLD MINE with lots of videos from many of these guys), and traced some of the roots of OOP and modern software paradigms to their origins to find that much of current view of what software & programming is, is a reduced form of a once grander picture. I've been one of many to try to find the next better language, paradigm, tools, etc. ... but this is just the software culture chasing its own tail. What needs to change is how software ITSELF is thought of, and the tools we use to do that cannot do that for us. My first wake-up call was recognizing this delimma as called out by Jim Coplien (and it took a year of study to for me to finally see what he's talking about), but does an excellent job of pointing this out (and demonstrating this could change), as does Rich Hickey (especially if you consider his statements of simple representation in a GENERAL sense, rather than just promoting functional programming or Clojure), and Alan Kay has a lot to say, but is very abstract. ... You cannot language or unit-test or TDD or tool your way into good software design; you have to think about software design itself, which means understanding HUMAN models of software. THAT should shape language & programming paradigm, but instead the software industry has let the opposite happen. ... places like THIS do a lot of good though in supporting open-ended exploration & learning; but there are nonetheless some DEEPLY ingrained views that come with being a programmer nowadays, and a lot of it is upside-down, but it's hard to change or even challenge.

... I see a world of software in which "language" becomes a malleable thing that can be adapted and mixed selectively or on the fly, rather than as a rigid distinction between one language or another. Ideally, you want to be able to create whatever software you want using whatever paradigms and language tools you want, without having to have had someone package it up into this static thing called a "language". Less like choosing between Legos or K'nex and more like being free to use any of all of paint, markers, crayons, pencils, charcoal, clippings, staples, glue, etc. etc. on your paper, and not even being limited to those things, or even to paper.



A lot of this was me trying to make the "perfect" general purpose language, and I was never satisfied with it 100%, so it never got done. Now that I have kids and a career, I see no priority for something this big; though I enjoy the discussion, and maybe someday I will use these ideas somehow. I've also had some changes of heart as to what to pursue in software, it's put me off of pursuing "language" too strongly. It's like Jim Cope says about language.

Anyway, I'm still all about the ideas, but I have nothing to offer beyond that at this time.

As for "the old one" (I assume you are talking about Antidisassemblage / SquirrelBox), yes that was a precursor. It was largely a first-time crash-course attempt at a language & compiler (which I'm still somewhat proud of); but over time I've learned that I could do SO much better! ... But I don't know if it will come to be in any time span that anyone is willing to wait for.

Anyway, I'll add further thoughts to my previous post (which I left "in progress")

Thanks for following my work though!





If anyone is interested in what I "moved on" to, here it is: https://github.com/d-cook/Objects

The idea is a software system that escapes the rigid boundaries of traditional languages and software tools, by empowering the end-user to create whatever things & behaviors they desire. It will act as a tool with a UI for creating and manipulating data & code in the form of objects, including all parts of the system itself (interpreter, UI, etc.). This will work the system will be made out of the same components that it edits, which can all be live-edited.

One idea for how this can be used is to replace traditional software development (code in language-X, depends on compiler- or IDE-Y, etc.), a software project can be its own self-contained tool that is its own editor, compiler, and UI for whatever software is being developed. All these pieces can be used on each other, and you can thus create the ideal everything (language, UI, etc.) for the thing being developed, and it's all just part of "the code". And it need not be uniform through-out (e.g. a chunk of code that contains its own interpreter or UI just for that part). That is one example, but the possibilities are endless.

...

Beyond that, as I am not the only one doing "this kind of stuff", I've actually formed a collaboration with others who are seeking to redefine software in similar ways. Check it out (it has its own brief explanation / history): https://github.com/d-cook/SomethingNew

Edit (Eeems): Merged triple post
« Last Edit: November 17, 2017, 01:09:48 pm by shkaboinka »

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4646
  • Rating: +717/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #160 on: November 04, 2017, 09:55:09 am »
I'll be honest, I have no clue what a lot of that means. I've played with OOPLs here and there, but I've never managed to really "get it." However, I know for many programmers it is more natural and it would be cool to have such a language available on the (e)Z80 calculators.

I totally get being busy, but maybe you'll be lucky enough to pull a JamesV and come back in ten years with renewed energy/time/motivation.

Offline shkaboinka

  • LV3 Member (Next: 100)
  • ***
  • Posts: 86
  • Rating: +10/-1
    • View Profile
    • Antelope (polymorphic z80 language)
Re: Antelope (formerly "OPIA") - A Polymorphic z80 language
« Reply #161 on: November 17, 2017, 02:30:10 pm »
It's hard to explain the whole thing, but I can explain what I mean by escaping "language" (or at least escaping compiled language):

Instead of writing a program in language-A or language-B and being limited to using only the features of one language, you should instead be able to mix and match whatever language features you want, even ones that you create yourself. Or you should be able to modify those features just for your program. So how do you do this?

Instead of using (or writing) a compiler for some language, you write your own program to generate the program you want. This would be more doable if you take the code that normally would be in a compiler, and instead make it part of a library. A compiler creates structural representations (AST) of the code that it compiles, so instead the library would be a tool to build parts of that representation and give them back to you. You could then modify them, or create your own somehow; and then you hand them back and say "ok, build the program from these".

Think of uncompiled source code (written in a compiled-language) as a program that makes an executable program, and the compiler as the interpreter of that program. When viewed in this way, declarations within code (classes, functions, variables) act as imperative commands to create components of a program. Replacing these "commands" with an API & user-defined functions would allow programs to be generated with any components & mechanisms, rather than from a fixed set of "language features". No more language restrictions!

::instead of this:: class Foo { Bar b }
::you write this:: myClass = MakeClass("Foo"); myClass.AddMember("b", myBarClass)

::another example:: myTrait = new MyVeryOwnTraitsImplementation("ResizableThing"); myTrait.ApplyTo(myClass)

This is what makes languages like JavaScript so powerful: many things that are "declarations" in other languages are actually imperative calls to user-defined functions. This is why people have been able to make so many different kinds of object-models (etc.) in it. This makes things like compiler hooks and reflection mostly obsolete.

----

Now you might notice that the program that is generated by your program has whatever features and structure you want; but what about the program that did the generating; what language is that written in? Two possible answers are:
(1) It doesn't really matter, so long as you can generate whatever you want from it.
... However, since it just has to "run" once, it is more important for that code to have good expression than for it to be efficient, and that screams "interpreted language". Also, why would you want to have your source program, feed it into another program called a compiler, which generates an executable program, which you run to have it generate the program that you care about? Why not just run an interpreted program that generates the output program? So though it really does not matter what language the program-generating-program is written in, a compiled-language has no gain here, but the advantages of an interpreted language do apply.
(2) The only other option is to "close the loop" with some meta-circularness. That is, a software system or tool that is self-defining, self-modifying, etc., which is only possible if everyrthing (interpreter, code structure, etc.) is accessible at runtime. That is what my Objects project is about, except that it will do more than just that (e.g. a UI through which all things can be viewed or changed at runtime by the user, including the workings of the UI itself).
« Last Edit: November 17, 2017, 02:34:24 pm by shkaboinka »