Antelope - A Polymorphic z80 language
» >
» Goto page Previous  1, 2, 3 ... 17, 18, 19, 20, 21, 22  Next
» View previous topic :: View next topic  
Compynerd255 wrote:
Wow... that looks wonderful - I never would have thought of overriding operators like that. How would this code be used, however?

Constructors would completely replace the old braces-initializtion {...} syntax:

Code:
struct A {
   int x, y;
   new(int n) { x = n; y = -n; }
}

struct B {
   int x, y;
   // This default constructor is implied:
   // new(int x, y) { this.x = x; this.y = y; }
}

A allAtOnce = A(1,2);
A separate; separate = A(1,2);
inferred := A(1,2);
A newInitialized = new A(1,2);
A newUninitialized = new A; // NO construction done
B worksAllTheSameAsA = B(1,2);

Arrays stay the same though:

Code:
[]A array = &[]A{A(1,2), ...}; // static instance
[]A smaller = {A(1,2), ...}; // this is ok too
infArray := &[]A{A(1,2), ...};
[]A newArr = new [size]A; // no construction of A's
[]A newInit = new []A{A(1,2),...};
[]*A arrOfPtr = {new A(1,2), new A, &someA, ...}; // etc.
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:
// 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
Update on changes:

* I'll do away with anonymous members as previously mentioned.

* I'll allow for method-pointers in addition to function pointers:

Code:
func foo(Bar b, Bar.func(int) f) { b.f(5); }
foo(someBar, Bar.someBarMethod); // use existing method
foo(someBar, x => x*barMember); // new method (lambda)

* I'll provide some additional short-cuts for creating instances:

Code:
Foo f(..)            // = Foo(..)
*Foo f(..)           // = &Foo(..)
*Foo f = new         // = new Foo
*Foo f = new(..)     // = new Foo(..)
[5]T a = {..}        // = []T{..}
[]T a = {..}         // = &[]T{..}
[]T a = new[5]       // = new [5]T
[]T a = new[]{..}    // = new []T{..}
func(int x) f = {..} // = func(int x) {..}

* I'll allow "initialization blocks" after constructor calls, in which virtual functions can be (re)assigned with a declaration syntax (as I had presented previously):

Code:
struct Foo {
   int x,y,z = 5;
   func Bar() { ... }
}
f := Foo(1,2) { z = 3, func Bar() { ... } }
// Same as:
// f := Foo(1,2); // z defaults to 5
// f.z = 3;
// f.Bar = func() { ... };
(Another) Update on all the changes that currently need to be made:

(1) Add the rest of the preprocessor directives to the grammar, and allow namespaces to have type-arguments (name<type>).
(2) Add constructors (and destructors) using "new" and "delete" keywords; change construction syntax from {} to (); allow constructor parameters without types to map directly to the same variables.
(3) Provide very shortened function syntax:
func x():T { return y; } | func x():T = y; | func x() = y; | func x = y;
(4) Allow interfaces to contain default methods and other member variables (may need constructors?); Replace "interface" keyword with "iface".
(5) Remove anonymous members, but allow transparent member access and method-inheritance (where-ever ambiguity does not result).
(7) Allow method-pointers: T.func() ptrToMethOfT.
(8) Allow initializer lists after (or in place of) constructors:
Foo f(constrArgs) { mem1 = x, mem2 = y }; // f.mem1 = ...
(9) Add "typedefs" to define one type based on another (this is necessary for recursive types):
typedef newType equivType; | typedef recur func(int, recur):recur;
(10) Remove the idea of cofuncs having a "receiver type" (which just acts as composition anyway), but allow them to be embedded within structs again, and still to have their own bodies. However, I am considering changing this syntax:
Code:
//Which syntax?
cofunc Foo { int x; } ():int { return x++; } // SHORT: cofunc Foo { int x; } = x++;
cofunc { int x; } Foo():int { return x++; }  // SHORT: cofunc { int x; } Foo = x++;
Nice changelist. I like the first syntax under number 10 better, because the data for a cofunc feels less like metadata (what would go in a header) and more like an asset the cofunc possesses. The name should definitely go before the data.

Out of curiosity, are there any plans for an Antelope IDE, either as a standalone program or as an extension of an already existing IDE? I'd love to be able to step and trace an Antelope program.

In fact, I have this old Apple //e connected to my computer via a serial port, and I think it would be an awesome project to write an implementation of Antelope for the Apple, complete with a system that deploys the program to the Apple (over the serial line) and uses an Apple-side program to interact with the remote debugger.
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link!
Compynerd255 wrote:
Are there any plans for an Antelope IDE as a standalone program or as an IDE extension?

The compiler will just be a command line application, but I am making is as modular as possible so that other programs (an IDE) can hook into it at different points to make use of specific features such as syntax parsing etc. It will also be usable as a Java API so that, for example, syntax trees can be manipulated directly.

Beyond that, I am not going out of my way to hook the compiler into any specific IDE or environment. However, once it is in place, I can see myself wanting to make some Java-based tools for it; or perhaps making syntax files for something simple like EditPlus or Notepad++, etc. -- But that would be an after-the-fact thing.
shkaboinka wrote:
Compynerd255 wrote:
Are there any plans for an Antelope IDE as a standalone program or as an IDE extension?

The compiler will just be a command line application, but I am making is as modular as possible so that other programs (an IDE) can hook into it at different points to make use of specific features such as syntax parsing etc. It will also be usable as a Java API so that, for example, syntax trees can be manipulated directly.

Beyond that, I am not going out of my way to hook the compiler into any specific IDE or environment. However, once it is in place, I can see myself wanting to make some Java-based tools for it; or perhaps making syntax files for something simple like EditPlus or Notepad++, etc. -- But that would be an after-the-fact thing.

Fair enough - I can understand just working with Notepad or something like that, especially since you don't have all the time in the world. If I were to write my own IDE for anything, it probably wouldn't have that many features.
However, the reason I like IDEs is because they provide two spectacular features that have saved me worlds of trouble in my coding:
- Intellisense: I don't have to read complex instructions in the help guide, since the system is popping up with a list of suggestions as I type, even labeling the arguments and telling you how to use methods. This is especially helpful when I have a new API that I'm working with.
- Step and Trace Debugging: As much as I loved Axe, the one thing I hated about it was that I had no idea where my program was crashing. I love working with modern computer languages and stepping through my code to see just what's going on and what's killing my program off. In your case, I know that WabbitEmu has a COM interface that allows you to interact with the system's innards, so extending that to work with an IDE wouldn't be that difficult (although it would probably be more difficult in Java).
But of course, I also understand that those features are luxuries, and the fact that a polymorphic language is being written for Z80 at all is simply awesome. Keep up the good work!
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link!
I think I may throw out anonymous functions and just expand the syntax of lambdas so they can optionally include types, and expand the function-pointer type to optionally contain argument names:

Code:
// Standard syntax (can use (t) or t):
func(T):V f = t => v;   func(T):V f = t { return v; };
// Arguments named in func type:
func(T t):V f = => v;   func(T t):V f = { return v; };
// Argument types within lambdas (parenthesis required):
f := (T t) => v;        f := (T t) { return v; };

The rule: [ IDENT | '(' IDENT* | VARDEC* ')' ] ( '=>' EXPR | '{' STATEMENT* '}' )

For consistency, I should probably also change the "short form" of functions to use "=>" instead of just "=".
Are there plans to add a compilable comment system (e.g. JavaDoc for Java and XML for C#)? I could see having a form of JavaDoc implemented so that one could easily compile HTML documents for readmes of their APIs.
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link!
Compynerd255 wrote:
Are there plans to add a compilable comment system (e.g. JavaDoc for Java and XML for C#)? I could see having a form of JavaDoc implemented so that one could easily compile HTML documents for readmes of their APIs.

No. However, comments are parsed into tokens, which can be intercepted by an add on (the compiler uses a default implementation of a "TokenSource" interface, which could be overridden, for example, to filter input and inspect comments).

I currently do not let comments become part of the syntax tree, but perhaps it would be useful to either let them in amid things, or allow them to be "attached" to statements etc. We'd need some rules for "attaching" them to things, such as:
* slash-slash comments are combined together when they appear on consecutive lines with nothing in between.
* comments "touching" a statement / construct are "attached" if they appear on the same line (at the end) or immediately before
* perhaps only keep comments which have a special syntax to distinguish documentation from other comments. C# uses /// and Java uses /**.
I think JavaDocs etc. work no matter what the language. AFAIK it just scans for the format and runs with it, right?
Shaun
iirc, javadoc was based on doxygen and is just a stripped down, lacking useful functionality and features. Doxygen works with many languages and isn't too hard to have it support another language, easier if your syntax relates to another language.
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
I'm working to bolt down the changes I mentioned, and then not deviating from it. One small change though: The C/C++ "typedef" is backwards from mine, so in trying to write it in a readable-right-off-the-bat way (without changing the order), I came up with this:

Code:
// The old setup:
typedef T func(func(T,T):T, T): T;

// The new (proposed) setup:
type T = func(func(T,T):T, T): T;

// Having a bit of fun with recursive function-types:
T me = (choose, you) => (pick, them) => pick(choose(me, you), them);
Updates I've finally made on the grammar as discussed:

* Added Constructors and Destructors!
* * (removed arguments/parens from destructor syntax)
* Changed Instance Construction syntax from {} to ();
* Added Initializer lists after constructors: new A(){ m1=x, m2=y };
* Can now call methods from other namespaces: Object.(Foo.Method)(Args);
* Added "@args" syntax to use existing variables as parameters
* Provided previously mentioned "shortcuts" for instance values
* Interfaces can have default methods and member variables
* Altered the TYPEDEF syntax: type DerivedType = OtherType;
* * (use "new type" for a distinct new type rather than an alias)
* Added method-pointers: T.func() ptrToMethOfT
* Changed Type-Cast syntax from A:T to A->T
* Added the ?? operator (A??B is like (A!=null)?A:B)

I have yet to finish adding in all the preprocessor directives (along with allowing namespaces to contain type-parameters).

With these changes, I am going to try to bolt down the language so that development can happen (sorry for all the changes / delays)!
Edit: Update: All grammar rules (except namespace and using) are in place!!! (...again. ...I'll try to keep it for sure this time).

Things that have come up, but I've resolved NOT to change:

* Trait composition (instead, use "func A @ B" to reuse implementations).
* Anonymous members (instead, name vars after their own base type).
* Overriding implicit interface construction (like Explicit Interfaces in C#) (instead, use an explicit function; rarely needed).
* Importing only specific members of an interface (can already be done explicitly, e.g. int ALIAS @ X.Y.OTHER).

Semantic additions (no grammar changes):

* Operator overloading is enabled by normal functions of pre-chosen names (e.g. "func Plus(Foo a,b)" defines how to add two Foos).
* Will designated a special keyword ("thisType"?) to use within an interface to refer to the type of the implementing object.
* Might have interface implementation depend on namespace visibility (e.g. if an interface relies on method M, and there are multiple M's in different namespaces, then which M is used will depend on the namespace, and perhaps which namespaces are made transparent by "using" them).

Minimal Grammar changes:

* Might allow aliasing a namespace within a file (using ALIAS = OTHER)
* Might allow namespace declarations throughout a file (preprocessing would have resulted in something similar anyway, with namespace token-tags). Declarations are not nested, and apply to the rest of the file (until another declaration).
* * Might allow things in different namespaces but within the same file to have public (but not transparent) access to each other.
The grammar is finished (again).

The reason it didn't stay finished before is that the design was more theory oriented, and examples revealed that parts of it were clunky to actually use. In the process of revising everything that felt remotely awkward, I also gained a wider knowledge of other great language designs, and it was hard not to compare Antelope to them. It took a long time to re-establish what lines I did/didn't want to cross, but I feel like I finally crossed off that whole list, and I've now finally put the grammar back where I want it -- Sorry about all that!

(On a side note, I could go back someday and make one language based on Trait composition, one on Class-based design, and one on Prototype-based design).

What's Next?

* I'll need to revise the overview (make it up to date, redo each section with better / more applicable examples).
* I should also revise the extra documentation on the Grammar page (Example Walkthrough, Order of Operations [needs to be moved elsewhere], List of Classes).
* CONTINUE CODING:
- * Go over existing code and make minor revisions to make sure it's best suited to current design.
- * Implement the Syntax Tree classes with full syntax parsing Smile
- * (We'll go from there; but next is validating, optimizing, and interpreting code, and then generating assembly code for it all).

Thanks for your patience Smile
shkaboinka wrote:

- * Implement the Syntax Tree classes with full syntax parsing Smile
- * (We'll go from there; but next is validating, optimizing, and interpreting code, and then generating assembly code for it all).

Out of curiosity, I did notice that the compiler system would allow for the creation of syntax trees from non-Antelope code and the analysis of generated code, but will we be able to take the completed syntax tree and generate code for another architecture, such as 6502 for the Apple or Atari 800?
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link!
Compynerd255 wrote:
shkaboinka wrote:

- * Implement the Syntax Tree classes with full syntax parsing Smile
- * (We'll go from there; but next is validating, optimizing, and interpreting code, and then generating assembly code for it all).

Out of curiosity, I did notice that the compiler system would allow for the creation of syntax trees from non-Antelope code and the analysis of generated code, but will we be able to take the completed syntax tree and generate code for another architecture, such as 6502 for the Apple or Atari 800?

Yes. However, the public interface to the syntax tree will only allow you to create (or deserialize) correct Antelope code-structures. You can have it do anything among parsing, validating semantics (i.e. error checking), optimizing, and compiling to assembly, and you can come in or leave at any point. So yes, you can let it do all that, and then jump in and compile the optimized code for another system altogether.
shkaboinka wrote:
Yes. However, the public interface to the syntax tree will only allow you to create (or deserialize) correct Antelope code-structures. You can have it do anything among parsing, validating semantics (i.e. error checking), optimizing, and compiling to assembly, and you can come in or leave at any point. So yes, you can let it do all that, and then jump in and compile the optimized code for another system altogether.

Thanks.

Also, I took a look at your code repository on Google Code and noticed something strange: shouldn't your files be in the "trunk" directory, since the default for an SVN checkout (as shown on the website) is the trunk directory of a repository?
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link!
Compynerd255 wrote:
Shouldn't your files be in the "trunk" directory, since the default for an SVN checkout (as shown on the website) is the trunk directory of a repository?
Probably. I actually just created new files through the web UI, and I either edit them directly or copy/paste. I might fix that sometime.
  
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
Antelope - A Polymorphic z80 language
» Goto page Previous  1, 2, 3 ... 17, 18, 19, 20, 21, 22  Next
» View previous topic :: View next topic  
Page 18 of 22
» All times are UTC - 5 Hours
 
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

 

Advertisement