Don't have an account? Register now to chat, post, use our tools, and much more.
Latest Headlines
Online Users
There are 104 users online: 3 members, 74 guests and 27 bots.
Members: Ashbad, JamesV, Svenne.
Bots: VoilaBot (4), MSN/Bing (1), Magpie Crawler (2), VoilaBot (1), Googlebot (18), MSN/Bing (1).
RSS & Social Media
SAX
You must log in to view the SAX chat widget
|
| Author |
Message |
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
 Posted: 11 Jul 2012 08:40:27 pm Post subject: |
 |
|
| elfprince13 wrote: | | merthsoft wrote: | | Recursive acronyms are so lame. |
Shaun, between this and your Doctor Who bashing, it's like you WANT the Internet to stab you in the face with pitchforks. |
I don't jump on the internet bandwagon every time it rolls by. Sue me.
| blue_bear_94 wrote: | | TiLP=TiLP is Linking Program |
What an insightful post.
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 12 Jul 2012 05:54:32 pm Post subject: |
|
|
Enough with the acronyms; let's keep on topic -- but do take a CLOSER look at my last post 
I did fix the antelope image though:
 |
|
| Back to top |
|
|
Ashbad
... I think redheaded girls are kind of cool
Joined: 01 Dec 2010
Posts: 2418
Location: Stomp Stomp Stomp, The Idiot Convention
|
| Posted: 12 Jul 2012 06:08:28 pm Post subject: |
|
|
Nice vector! If you ever need a small raster of that for an icon of sorts, I'd be willing to make one 
_________________
-Ashbad |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 12 Jul 2012 06:15:14 pm Post subject: |
|
|
| Ashbad wrote: | | Nice vector! If you ever need a small raster of that for an icon of sorts, I'd be willing to make one |
That would be awesome! I'd like something with more straight lines, so that it can be easily imitated as a Doors/etc icon. Something akin to this  , though that is both too large to be an on-calc icon  , and too small to be drawn very well; but that should give you the gist (rectangle legs, etc.). Hopefully you can come up with something a little better than I did.
Last edited by shkaboinka on 12 Jul 2012 07:05:16 pm; edited 5 times in total |
|
| Back to top |
|
|
Ashbad
... I think redheaded girls are kind of cool
Joined: 01 Dec 2010
Posts: 2418
Location: Stomp Stomp Stomp, The Idiot Convention
|
| Posted: 12 Jul 2012 06:18:47 pm Post subject: |
|
|
| shkaboinka wrote: | | Ashbad wrote: | | Nice vector! If you ever need a small raster of that for an icon of sorts, I'd be willing to make one |
That would be awesome! Perhaps a slightly more rigid version though (e.g. straight rectangular legs with the bottoms colored black for hooves. Something that could easily be displayed as an icon on a TI device, but perhaps a bit smoother than the TI icon would actually be). |
Sounds good, sounds relatively easy to pull off in a timely fashion. Size requirements?
_________________
-Ashbad |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 12 Jul 2012 07:02:27 pm Post subject: |
|
|
| Ashbad wrote: | | shkaboinka wrote: | | Ashbad wrote: | | Nice vector! If you ever need a small raster of that for an icon of sorts, I'd be willing to make one |
That would be awesome! Perhaps a slightly more rigid version though (e.g. straight rectangular legs with the bottoms colored black for hooves. Something that could easily be displayed as an icon on a TI device, but perhaps a bit smoother than the TI icon would actually be). |
Sounds good, sounds relatively easy to pull off in a timely fashion. Size requirements? |
Sorry, I kept editing my post after that. I included a couple of samples. The color one should be a bit bigger so that it can still look nice, but still have the same blocky feel. I'd like it just large enough so that it's not very pixely looking (perhaps a bit bigger than the one I posted above). The on-calc icon might need some work; but that's a more trivial matter I suppose (perhaps it can just be the head or just the antlers; though I'd like the color icon to be the whole antelope).
EDIT: Here is a 15x15 head:  |
|
| Back to top |
|
|
Compynerd255
Power User
Joined: 08 Apr 2011
Posts: 397
|
| Posted: 13 Jul 2012 09:56:14 am Post subject: |
|
|
| KermMartian wrote: | | Antelope! I think that's a perfect solution to this ridiculous debate, even if I would have enjoy programming in Ketchup. Also, cute Antelope. |
When the language is close to release and you're thinking about a logo or something, you should totally take some stylized picture of that antelope (e.g. take a mid-to-low shot of the antelope so as to emphasize its masculine chin ( ), then Photoshop it so that it's stark black and white). Oh, and when people ask "Why Antelope?" be sure to give kudos to your wife!
_________________
Visit Betafreak Games: http://www.betafreak.com
Help Me Pay for College:
- Sign up for Fastweb through my referal link! |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 13 Jul 2012 03:37:28 pm Post subject: |
|
|
| Compynerd255 wrote: | | KermMartian wrote: | | Antelope! I think that's a perfect solution to this ridiculous debate, even if I would have enjoy programming in Ketchup. Also, cute Antelope. |
When the language is close to release and you're thinking about a logo or something, you should totally take some stylized picture of that antelope (e.g. take a mid-to-low shot of the antelope so as to emphasize its masculine chin ( ), then Photoshop it so that it's stark black and white). Oh, and when people ask "Why Antelope?" be sure to give kudos to your wife! |
I am not worried about a logo right now. I am fine with some minor tweaks to what's already been made, unless somebody wants to refine something and make it look very nice (I think someone might already being doing so). Thanks for the suggestion though, and I will certainly give credit to my wife |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 18 Jul 2012 03:34:13 am Post subject: An UHOH... |
|
|
I discovered a problem worth some discussion (sorry this is so long!):
With the switch from a C# style to a Go style, I figured that interfaces provide enough dynamic behavior to be alright without providing parametric types ("templates" in C++, "generics" in Java), since you can just use an interface to store data of any type. The empty interface ("interface any{ }") acts as a pointer to anything without any method requirements (like "void*" in C++ or "Object" in Java).
The problem is that using a more complete interface means that each entry is larger, since the relevant function pointers are stored alongside them. For example, each item in "data" below contains a pointer to some object, AND pointers to all the methods of the interface:
Code:
interface Printer { Print(); }
struct Foo { []Printer data; }
One solution would be to use Parametric types as a convention for storing the method-pointers separately. It would look something like this, with "<T:Printer>" designating that the struct separately stores ONE copy of method-pointers for the "Printer" interface, and designating "T" as a stand-in for something that counts as a "Printer" (i.e. something with a Print method, but not an actual "Printer" itself):
Code:
interface Printer { Print(); }
struct Foo<T:Printer> { []T data; }
This would require each "T" to be stored as a pointer (rather than a whole "Printer") so that the same struct (or any parameterized entity)can be used for anything. Otherwise there would have to be a different "version" for each type, and it would be pointless to actually store implicit method pointers for the interface, since each version could have the "right one" hard-coded in. In either case though, this struct would be used with a datatype plugged into it, which the compiler would use to restrict what can be stored in it:
Code:
Foo<int> list; // list may only work with ints (and stores an int.Print pointer)
Foo<Bar> list2; // list2 only works with Bars (stores a single Bar.Print pointer)
The issue is two things (and a couple of trivial things that I will leave out):
The first is that it does not parse well ("x<y,z>w" could be a tuple of two boolean comparisons, it it could be saying that "w" is somthing of type "x<y,z>"). This can be solved by using an unconventional syntax, or by requiring the "tuple version" to use extra parenthesis to work properly, or by reparameterizing each parametric type (e.g. "x<y><z>").
The second is just whether to use the "generic" form (all parametric types are pointers) or the "template" form (the compiler makes a copy of everything for EACH type used). The first only uses one version of everything and provides true dynamic entities. The second makes multiple copies which are hard-coded per type, but each is more efficient; however, the copies depend on what is used per compile, and there cannot be one precompiled version (set of methods), so it could not exist as a runtime library unless the "generics" setup is used. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 24 Jul 2012 04:12:34 pm Post subject: Some Changes |
|
|
*Bump* - Here are some new changes:
I have reverted the "cofunc" syntax back so that they cannot be embedded within structs, but they can hold data like structs. This is slightly less flexible (only because bizarre"siamese" cofuncs are no longer possible), but is more intuitive:
Code:
// Old setup:
struct Counter { int n; cofunc( ):int { n++; return n; } }
c := Counter{5};
c(); c(); c(); // 6, 7, 8
// New setup:
cofunc Counter { int n; } ( ):int { n++; return n; }
c := Counter{5};
c(); c(); c(); // 6, 7, 8
I have also decided to go with the "Templating" form of parametric types (though I still need to choose an unambiguous syntax for multiple parameters), but I will have templated things share the same functions when they are the same. This means that you can still use POINTERS to keep things generic for all types
Code:
struct Link<T> { T value; *Link<T> next = null; }
struct List<T> { *Link<T> head = null, tail = null; length = 0; }
func Tree<T>.Size<T>():int { return length; }
func Tree<T>.add<T>(T val) {
l := new Link<T>{val};
if(head == null) { head = tail = l; }
else { tail = tail.next = l; }
length++;
}
List<int> list; // an int list
list.add(1); ist.add(1); ist.add(3);
If it were "*T value" rather than "T value" in Link, then there'd only one version of everything, since pointers are the same size. Also, you can be specific, such that a "func List<int>.Foo()" would take ONLY int-lists (which is why the extra "<T>" is needed in "List<T>.add<T>").
I have also added the option of an extra "this" for cofuncs, removed the empty parenthesis from no-argument lambdas, allowed lambdas to have full {bodies}, ... and in the process, I have discovered that passing a function-pointer is MUCH more efficient than using a cofunc as an "iterator". Here is an example of all (riding off that "List" code):
Code:
List<int> list;
cofunc List<T>.Iterator<T>():*T {
for(l := head; l != null; l = l.next) yield l.value;
}
func List<T>.Each<T>(func(*T) process) {
for(l := head; l != null; l = l.next) process(l.value);
}
// Cofunc iteration (uses two loops!)
for(int i: list.Iterator{}) { ...do stuff with i... }
// Func-pointer iteration (much more efficient)
list.Each(i => {...do stuff with i...});
The only thing is that you cannot encapsulate everything into a function; though perhaps I can allow direct access to local variables, but then disallow such funcs from "escaping" the embedded function by restricting their use (e.g. cannot be assigned to external variables or passed into external routines).
Last edited by shkaboinka on 24 Jul 2012 04:20:39 pm; edited 2 times in total |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 24 Jul 2012 04:19:06 pm Post subject: |
|
|
All these changes seem sensible.
I hate not giving more detail after such detailed posts, but that's really all I've got. These things make sense and I approve
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 26 Jul 2012 04:13:49 pm Post subject: |
|
|
I have made all recently mentioned changes to the grammar!
- Templated types (e.g. Foo<T:Printer> { ... } )
- Extra "this" type for cofuncs.
- No more embedding of funcs or cofuncs within structs or cofuncs (enforces clarity)
- You can now be more liberal with the "dot" access (A.func(...), B.(*type), etc.).
Have a look |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 27 Jul 2012 03:22:37 pm Post subject: |
|
|
| (At Omnimaga) BlakPilar wrote: | Does this mean we have to use C++ style method declaration? I.e.
Code:
struct Foo { ... }
func Foo::Bar() : byte { ... }
|
Yes, this has always been the case (so that you can add new methods you as needed, without affecting the "definition" of a struct). Allowing them inside of structs was something I had added for familiarity with Java/C# as well. However, since you can embed function pointers inside structs (and make them act as virtual methods as well), I thought it would minimize confusion (and simplify the language) to just stick with one convention:
Code:
struct Foo {
func(*Foo,...) fp; // embedded function pointer
func(this,...) mp; // just like fp, but counts as a "method"
}
func f(*Foo,...) { ... } // function (not embedded in Foo)
func Foo.m(...) { ... } // method (same as f, but is a method)
Foo foo, foo2;
foo.fp(foo,...); // foo EXPLICITLY passed as 1st arg
foo.fp(foo2,...); // same deal (can pass ANY Foo)
foo.mp(...); // "method" = foo IMPLICITLY passed as 1st arg ("this")
f(foo,...); // same deal as fp, but not a func-pointer
foo.m(...); // same deal as mp, but not a func-pointer
// They all STORED as func(*Foo,...) though;
// and since fp and mp are pointers, you can do this:
foo.fp = foo.mp = f; foo.fp = foo.mp = m;
I honestly prefer the "inside" form myself; but it's not hard to get used to, and you have the following benefits:
* The struct JUST contains what it actually consists of (e.g. it "is" its "constructor"; the end).
* This is simpler than in C++: You use "." insteaf of "::", and only declare it once (no "headers").
If enough people are not appeased by these benefits (and my other reasoning), then I might reconsider. I do want to make a language that people like as well. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 29 Jul 2012 10:48:40 am Post subject: |
|
|
*Bump* - I have made changes to the Overview, with the following changes:
- Tuples can now have empty items (e.g. use "(,x,)" instead of "(_,x,_)").
- Added a detailed section just for namespaces.
- Changed the preprocessor directives to be more traditional
- Elaborated on how default values work (not the same as in other languages!)
- Gave example of how anonymous entities in a namespaces take on the namespace name. |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 08 Aug 2012 07:14:01 am Post subject: New Syntax for OOP idioms! |
|
|
NEW SYNTAX FOR OOP IDIOMS!
To test the feel of everything, I compared a simple OOP example from Java/C# with the "equivalent" Antelope code, and found it to be bulky and nasty. Therefor, I am wanting to rework some of the syntax relating specifically to "inheritance" idioms, as follows (with "..." indicating "no change"):
Code:
PSUEDO-JAVA/C# | | ANTELOPE (new syntax) | | ANTELOPE (old syntax)
========================================================================
class Fooer { | | struct Fooer { | | ...
void Foo() { <1> func Foo() { <1> func(this) Foo = func(this) {
Print("Foo "); | | Print("Foo"); | | ...
} | | } | | }
} | | } | | ...
| | | | ...
class FooID : Fooer { <2> struct FooID { <2> ...
int id; | | int id; | | ...
| | | | ...
<3> Fooer { <3> Fooer = Fooer {
void Foo() { <4> func Foo() { <4> func(this) {
Print("Foo "); | | Print("Foo "); | | ...
Print(id); | | Print(id); | | ...
} | | } | | }
| | } | | }
} | | } | | ...
1) I'd previously given the "func(this..." syntax for declaring function-pointers "as methods" (i.e. "f.Foo(f)" shortens to "f.Foo()"), which allowed "virtual" (late-bound) methods to be "simulated". However, letting these be declared directly as "internal methods" looks much cleaner, matches the common OOP idiom/paradigm, and still gives control over where they are stored in the struct.
2) Antelope rejects traditional "inheritance" in favor of composition. Instead, anonymous members provide transparent access to their internals, as if they were "inherited" directly into the containing struct. Thus, the "inherited" Fooer appears in the body of the struct rather than at the top (as in 3).
3) Since anonymous members exist soley to "simulate inheritance", it is just redundant to have to repeat the anonymous type twice when a more compact form will do. This form is suggestive of embedding an "anonymous class" within a struct, which is exactly the intent (as in 6).
4) Since "inheritance" is simulated by composition, the new "Foo" function must be embedded directly in the anonymous Fooer. However, the only safe option is to use a "Fooer" method (since a "FooID" method could have misalignment issues) declared anonymously (to hide it from "Fooers" outside of FooID) and then type-cast to "FooID" within the method. This new form takes a non-method function definition for overriding (replacing) "inherited" methods, which then does these things automatically (using offsets if necessary). These can be given anywhere in the initialization list, and are skipped if omitted.
Code:
PSUEDO-JAVA/C# | | ANTELOPE (new syntax) | | ANTELOPE (old syntax)
======================================================================
Fooer foo = Fooer(); <5> Fooer foo = Fooer{}; <5> ...
FooID fid = FooID(5); | | FooID fid = FooID{5}; | | ...
| | | | ...
Fooer moo = Fooer() { <6> Fooer moo = Fooer { <6> ...
void Foo() { | | func Foo() { | | func(*Fooer f) {
super.Foo(); | | Fooer.Foo(this); | | Fooer.Foo(f);
Print(" Moo!"); | | Print(" Moo!"); | | ...
} | | } | | }
} | | } | | ...
5) Initialization values are given directly "{...}" rather than via a constructor "(...)". The first variable declaration can be simplified to either "Fooer foo = {5};" or "foo := Fooer{5};" for conciseness.
6) "Inner" methods are normally skipped in initialization, but new versions can be defined for them (in any order) (as in 4). This very closely resembles an "abstract class" declaration in Java, which likewise creates an instance with "new" methods (only the Antelope version does not require a "new version" of the struct: this is merely a regular initialization which passes an anonymous function to the function-pointer "Foo").
Code:
PSUEDO-JAVA/C# | | ANTELOPE (nothing new here)
=============================================================
void FooFooer(Foo f) { <7> func FooFooer(*Foo f) {
f.Foo(); | | f.Foo();
} | | }
| |
FooFooer(foo); // "Foo" <8> FooFooer(foo); // "Foo"
FooFooer(fid); // "Foo 5" | | FooFooer(fid); // "Foo 5"
FooFooer(moo); // "Foo Moo!" | | FooFooer(moo); // "Foo Moo!"
7) In Java/C#, pointers ("references") are automatic. In Antelope you have to use them specifically (and you should, because they are more efficient).
8) The compiler will automatically pass the address of these variables so as to match the type. Otherwise, this code is exactly the same. Alternatively, FooFooer could have been written as a method ("func Fooer.FooFooer()") and called as such ("foo.FooFooer();")
EDIT: Although there were short forms (e.g. "Foo :=" rather than "func(this) Foo =" (at 1), or "Foo := Fooer{5}" or "Fooer Foo = {}" (at 5)), I used the fully expanded forms for a more complete comparison of the fully written out forms.
Last edited by shkaboinka on 08 Aug 2012 02:00:39 pm; edited 2 times in total |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 08 Aug 2012 09:10:58 am Post subject: |
|
|
I like these changes, they simplify the code, and I'm always for that. If I had to write func(this) Foo = func(this) { every time I wanted to declare a method, I would stop using the language right quick.
_________________
Shaun |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 08 Aug 2012 01:30:57 pm Post subject: |
|
|
| merthsoft wrote: | | I like these changes, they simplify the code, and I'm always for that. If I had to write func(this) Foo = func(this) { every time I wanted to declare a method, I would stop using the language right quick. |
Of course, that was not the case with static methods, which are 90% of the case. The old setup provided means so that virtual methods "could" be simulated "if necessary" by setting up the function-pointers manually. However, being able to use virtual methods cleanly and directly is essential, because there are countless applications where it's totally necessary.
I am glad that you agree, and I am very pleased with how this new setup ended up looking so similar to other OOP idioms (e.g. overridden functions and "anonymous classes"), especially since that is a result of common design goals rather an attempt to blindly mimic the idioms of another language -- The similarities totally came second-hand!
EDIT: I have updated the Grammar to reflect these changes (but will update the Overview later). |
|
| Back to top |
|
|
shkaboinka
Power User
Joined: 30 Jun 2010
Posts: 371
Location: Spokane, WA
|
| Posted: 21 Aug 2012 06:07:11 pm Post subject: |
|
|
*bump* - Some notes about current/future progress:
I am revising some of the framework to make it more flexible. For one thing, I introduced a "TokenSource" interface with a "nextToken" method, and replaced the corresponding method in the Token class with a public inner class which does this. This way, one can plug-in an alternative "source" to parse from. I've not yet uploaded the modified source code yet, as I am making other changes as well.
Also, I discovered that the "preprocessor" layer can be removed, and just rely on the syntax-tree-making portion to handle preprocessor directives (e.g. #include, #define, #if). The basis for this is that most of them would need to be spat right back out anyway, since they affect program aspects rather than JUST modifying the source code directly. As a result, I am adding grammar rules for preprocessor directives rather than keeping them as a "separate" aspect. You can see these changes as I make them.
I also changed the Token class a bit by changing some of the "types" around (so that keywords count as identifiers, but you can still pick out user-defined identifiers; this is better for syntax parsing). I also removed the preprocessor directives as tokens (but added the "#" token) and will just parse them syntactically. I've also revised some of the "Formatting" (now "Annotation") tokens so that they remain consistent across phases (e.g. line-numbers and file-markers remain separate).
One big-ish change I want to make is to change the grammar so that it does NOT use the widest rules possible, because that will require a lot more method calls than are needed as it parses. (For example, some things which require an identifier were asking for a whole expression and then requiring the result to be an identifier, with the justification that it would produce "cleaner error messages" and pick out "whole things" where they should not be). Instead, I think I will just use other tricks, such as jumping to the next semicolon or bracket, etc. |
|
| Back to top |
|
|
merthsoft
File Archiver
Joined: 09 May 2010
Posts: 2735
|
| Posted: 22 Aug 2012 10:28:30 am Post subject: |
|
|
Sounds like this is coming along nicely! Can you explain a little more what you mean by "This way, one can plug-in an alternative 'source' to parse from."
Also, what kind of extendability will the compiler have? For example, will it be easy to make it spit out something other than z80 asm?
_________________
Shaun |
|
| Back to top |
|
|
|
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
|
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
|
© Copyright 2000-2013 Cemetech & Kerm Martian :: Page Execution Time: 0.052363 seconds.
|
![[t]](/forum/templates/Cemetech6/images/twitter.png)
![[t]](/forum/templates/Cemetech6/images/fb.png)
![[RSS]](/forum/templates/Cemetech6/images/rss.png)
