Holy necroquote batman!

Also sorry if my post sounded like that. It was definitively not my intention. I just saw so many similar projects struggle in the past, so I wanted to make sure he makes it so as many people as possible will use it. (By the way even if it was a project on my site I would have said the same thing, since I did with Quigibo in the past, anyway)

Ahh, it's no problem. I thought about it afterwards and figured you didn't intend it to be interpreted that way. I shouldn't have really said anything.

That said, you did point out a couple good drawbacks to the project. I honestly don't see myself going out of my way to learn another programming language in addition to z80asm and messing with Axe.

To each their own

Though that is one reason I modelled it after popular languages; so it's basically the same thing, but tweaked for z80

Shkaboinka, don't worry about the other languages if nothing else, I would try dabbling in your language for fun, just to see how well it works and to possibly practice Higher Level concepts.

What language is the parser/compiler/linker written in? If it's Java or C, I can help. I technically could help with C#, but I'm not used to the little tricks that adds the Java doesn't, so I'll be makignbad coder the whole way (plus, half my time will be googling things like libraries).

Again, I wouldn't be able to help for a while, but maybe after this summer I can pitch in a few commits

I think he said that it was in Java. If not that, it's definitely in C(++).

It's in Java. I hadn't thought about having help with the coding; though that might be nice. I don't have a repository though (I've just been doing it locally), but if there was an easy way to get one, that might be nice!

Honestly, I do/will have a lot going on; but I wanted to get this out there and iron out the language specification so that, as I found any little bits of time, I'd be able to do something here and there.

http://code.google.com/hosting/ supports git, subversion, and mercurial for source control (and it's free)

Decent choice the downside is that the compiler will depend upon the JVM and Java IMHO is pretty ugly, but it's a good choice because it will work well with something like this regardless, and development will be faster and easier than in C++. Plus, I know it decently, so I can help later on in the summer again right now I'm booked

I'd like feedback on 3 points before I call it complete enough to start recoding; so as many yes/no/what-to-do responses I can get, the better -- and please back your opinion with real points beyond that you just flat out "like it better" one way or the other:

(1) Get rid of structs.

The distinction was that a struct would be a non-reference versions of classes; but for that to work cleanly, they had to have no inheritance or virtuals. I was convinced that having both makes it a bit confusing, and the compiler can compensate anyway by making final instances of a class non-references (the same thing will be done with arrays). This WILL require the "final" explicitly to avoid filling an array with references vs. actual instance allocations; but will therefor be predictable.

(2) Iterators (formerly "Enumerator" and "Process") and FOR-EACH loops:

The main problem is just that they are messy to use with loops! If some class-instance "foo" contained an iterator "iter" that returned bytes, one would have to use it as follows:

foo.iter i = foo.iter(...);
while(i.hasNext()) {
byte b = i.next();
// do something with b
}

It would be cleaner to go "foreach(byte b in foo.iter(...)) { /* use b */ }" or "for(byte b: foo.iter(...)) { /* use b */ }" (C# vs Java syntax, respectively). The reason for using "foo.iter" rather than just "foo" is that an iterator can exist independently of a class or class-instance (and declaring [instance.iteratorName] really results in a [classOfintance'sType.iteratorName], but with a reference to [instance] stored in the iterator to act as the invisible "this" argument). ... I know the syntax is a bit rough, but that's because an iterator is not necessarily tied to an instance, and it may take arguments. Any better suggestions?

Note: I decided to make these non-references, since I see them being used more directly with loops than being passed to/from functions.

For a foreach to work on arrays, there'd need to be a way to specify the size separately or indicate that it is null terminated (or make assumptions about a char[] type). I will not build array-sizes in, because arrays can associate with array-like allocations already present in the underlying environment (OS, etc.), which may have it's own rules about that.

(3) Get rid of $$ and make $ stricter.

The point is that having both just adds confusion (syntactically and semantically), and since the compiler ought to just optimize things pretty well anyway, there ought to just be one of these, and it should carry STRONG semantics with it. What I'd like to discuss are the following rules for $ in this case, which I propose as follows:

- Used on function-declarations (and calls to functions): The function is not only to be inlined, but also interpreted to the fullest extent. The compiler can otherwise tell when a very simple function ought to be inlined, and telling it JUST to inline a large function may just be promoting bloated programs.

- Used on variables: the value contained within the variable must predictable, and that value must be something that can be hard-coded as a literal value / object-instance. Other variables may not reference (point to) the variable, unless it can do so in a predictable way so that such references to it are known and circumventable.

- Used on flow-control constructs: the construct, AND everything within it, must be interpreted to the fullest extent (conditions on loops and ifs and switches must be predictable, and all statements must be circumventable or redirected to other interpreted entities).

- Use on expressions (e.g. x+$(y+z)): The result must be predictable as a literal value/instance.

...

Compare these proposals to "Structs", "Iterators", and "Interpreted" (respectively) within the [current] documentation: tinyurl.com/5wrpnaf

1. I'm not knowledgeable about this, and somewhat confused (I though that structs were data structures), but I say no.

2. Include them in a future version, but not now. A foreach loop is a very powerful and useful tool for any language, but if it adds too much unnecessary complexity, cut it, and do it some other time.

3. No idea.

1. I've already stated what I think

2. Reserve the foreach keyword, but don't add it yet.

3. I didn't really read the $ and $$ section. It all seemed unnecessary and complicated so I skipped it.

This is not for editing on-calc, right? I see it impossible to do so anyways if you use special characters(&,$,#,etc.)

1) The structs will go, once I resolve some issues (below)
2) The for-each will appear, but maybe not right away (we'll see)
3) I'll hammer out the details of $ and $$ later; but I like just one $

I can get rid of structs. However, I am faced with a couple options that may make class-descriptors a bit larger by default:

1) Have all classes inherit from some "Object" class (as in Java) which defines overridable functions "char[] toString()" and "bool equals(Object o)" (default for toString can just "object@ADDRESS" or something, and the compiler can insert 1 to 1 comparison of all values as a default equals function per class ... probably a universal function that does that given two addresses and a "size"). This would mean that every class descriptor would have these 2 entries added to it, and that ALL class-instances will have to have a reference to a class descriptor as part of its allocation.

2) Don't use a universal parent "Object" class; which means that if something wants to print objects, it would take a function pointer as a parameter (e.g. a "class Foo<E>" would request it in its own toString, like "char[] toString([E => char[] ] EToString)"). The downside is that this could be more overhead than just putting functions in the descriptors anyway (and hey, it's JUST in the descriptors, and not the instances that reference them), and it could be argued that all class instances would need a reference to a descriptor anyway for the "is" test ("instanceof" in Java) to work at all.

To compensate for the fact that class-instances are references by default, I could allow "final" instances to be actual allocations rather than references (not just by optimization, but by design). This would allow one to specify things like:

Foo[] // A reference to an array of Foo-references
final Foo[] // An allocated array of Foo-references
(final Foo)[] // A reference to an array of Foo-allocations
final (final Foo)[] // An allocated array of Foo-allocations

The problem with this design (other than it's odd syntax [but do you have something better?]) is that it disallows the declaration of final REFERENCES ... Perhaps the compiler can use it for either, and figure out where which is better (references are definitely better for function arguments). But the point is to be able to store an instance directly into a data-structure (or into an array in a data-structure). The only place I could see this distinction being very useful is when you want to reference a location in memory that has contiguous allocations of records, and you design a class to match the pattern ... of course, those allocations are not likely to contain references to class descriptors though (and the reason for keeping the class descriptor even in final allocations is so that they can be referenced by other variables. If this were never the case, then the descriptors could be pulled out because they type should be known at compile time).

...

The reason it matters to have toString and equals functions is so that generic containers can test for equality and stringafy themselves ... but function-pointers provide that functionality if it's really needed; though perhaps it's more efficient (and beneficial enough) to just use the parent "Object" class for everything.

SO, the new questions for now:

1) parent Object class?
2) A way to have non-reference instances of classes (w/o structs)?
3) Any justifications for when to remove descriptors from instance allocations?

1. YES YES YES!
2. [Classname].[meathod](); For example:

public void Foo{
static void doStuff(){//...}
}

//elsewhere in the code

Foo.dostuff();

3. Wha..?

One thing I am focused on is allowing arrays, classes, and strings to match data formats on the target platform:

Without a length built into an array, it can match any array-like allocation of any system. This can be dealt with by (1) passing a size along with an array, (2) making an Array class (as you showed; perhaps the autosizing can be set as a bool, or different versions of the class do/don't), or (3) using a protocol such as storing the size in the first element. Without the size built-in, you could discover than an array of pixel values is stored at memory-location "FOO" in the TIOS and just declare an array byte[] pixels @ "FOO", and then change them directly by manipulating pixels. Such a correspondence would not work otherwise.

You misunderstand what is meant by a non-reference instance. This is having a variable of some class-type which stores an instance of the class (rather than a REFERENCE to an instance of the class). This is not the same as going through the classname directly, because you could have multiple instances this way; just without the reference. The point is that, similar to the pixel example, perhaps there are records stored in memory in a contiguous manner; but declaring an array of a class type gives you an array such that each element is a reference to an instance; whereas the underlying system has the actual instances stored one after the other in memory. So you want to declare an array of actual-instances. The reason I was considering using "final" for that was that, since a final instance never changes, it might as well just drop the reference ... it seemed like a safe assumption (except when you pass a reference and you want that not to change). Perhaps some other keyword then (and "static" will not do either, since it means a variable is shared across instances or function calls; but we want a variable that can be per instance/call, just not a reference) ... Let's just say it is "inline" (there is probably a better choice). Thus, one could declare some "class ArrayList<E> { E[] data; }" and make an ArrayList<inline Foo>, which will create an array of instances (NOT references). Or perhaps you just want a plain array, and you can go "(inline Foo)[]" ... same as the example I gave previously, but with inline (or whatever a better keyword or operator is).

The point about removing descriptor references is about matching underlying storage. For example, say that the underlying system has an array-like allocation of values such that each is a byte value and a word value. The problem with trying to declare a class to match this is that, in order to allow for the Object inheritance and the "is" test, a "class Foo { public byte a; public word b; }" would not do, because each instance would look like this: {pointer to the descriptor, byte a, word b}. Making an array of those would not match what is stored in the system. I figured that perhaps a "final class" which inherits from nothing could just NOT have a reference to the descriptor, since the compiler would always know which functions to call on it; BUT, if such a class is used with a datastructure that holds generic values, and that class wants to call a tostring or check what the value is an instance of ("is"), it needs to assume that the first value in each is a reference to a descriptor!

...So I have a new proposal: I can allow the struct type, but ONLY as a collection of values. No inheritance, no constructors, no functions ... JUST values. Example: "struct Thingy { byte a; word b; }". A "Thingy" would then be a 3-byte value, period. ... If structs were allowed in this fashion, could anyone see a place where non-reference instances of classes would be needed? ... I personally think it would be nice to choose without having to decide one and for all that a type is a struct or a class; but I cannot think of a better way :/ ... perhaps "struct" can just be a keyword that attaches to a datatype to indicate that you want the "struct version" of it -- it would be allocated directly (not a reference), not contain a descriptor, and if the class is part of a hierarchical chain, it will require that instances NOT be sub-class instances, and it can therefor use the correct member functions by assumption (circumvent the vtables).

...About using toString though:

The thing is that all kinds of instances are created and destroyed with each appending of values into a string, especially if the function is recursive or calling the toString of internal members. If it were just to print, it would be more efficient to just print each part; but the toString is useful for ANY context (not just printing or whatever). Perhaps the toString function could be formatted so as to hand each peice to a processing function (which could choose to print each one or build a string with it, or whatever it pleases). Example:


Code:


(Perhaps there could be a built-in string-making function, and the compiler could treat ".toString()" as a shorthand to pass in that function and then return a reference to the built string).

The difference between doing it this way and just providing an iterator is that the iterator would give each value, whereas the toString would want to provide other strings as well (", " and "{" etc.) to format it nicely. One would suppose that just providing an iterator and letting the user print it how they like would do; however, this toString implementation would work perfectly even on generic types (because who knows how the type wants to print or iterate its contents?).

I have a solution for working with strings, an Object class, and a Comparable interface:


Code:


The compiler could also pick out where an object is assigned to (or used as) a string, and add in a ".toString()" call. So while is would still be better use o.printTo(print), one could still use print(o); (and maybe the compiler can look for special cases like that anyway).

This can also be viewed here: http://nopaste.info/bde8842da2.html

hmm, I cannot beleive I completely missed this topic O_o

I think this is a pretty cool idea, I think that, when the project is finished (or at least a beta version for download >.>) I will most likely use it as I program in C#. Looking at the sample code, I can understand most of it based on my C# knowledge. It is a great project and seems to benefit Java, C++, and C# users, good job

That's the idea; and thanks! ... keep your eye on it. I will only work on it bits at a time, because my life is about to get really busy. But if you want to be more closely aware/involved, email me (shkaboinka@gmail).

But most of all, watch this page (documentation; it updates as I update it): http://tinyurl.com/z80opia

Just for other people's reference (and my own), he was quoting the code and adding his comments to it. Just in case others get confused like I did. Seana, I assume at your first comment, you mean "==" instead of "=", right?