[dangelder]

Well, I've been a long time Mac developer since the days of Hypercard. I've been obsessed with a particular project for the last couple of months and have been working on the code every day. And I think I'm far enough along that I'm ready to go public and start looking for people who might want to help or just watch.

The project is to write a user friendly scripting language that can be compiled. The scripting language is supposed to support all the stuff available on its native platform, like Realbasic is supposed to do (I don't know if it actually does in practice.)

So, how did I approach this massive project?

I wrote a set of classes, templates, and macros in a set of header files! That's right: you can compile the language right in xCode, and you always will be able to. Although debugging can be a little bit of a pain.

The language, which I like to call "iC" or "Lightyear", has the features:

* It looks kind of like JavaScript since it uses the usual C operator/function syntax.
* It's absolutely deterministic so there is no syntax ambiguity.
* It's typed (integer, string, logic, floating, nothing, list<..>). The types are very nice.
* There is a great variant class simply called "data"
* There are no pointers -- instead all objects are accessed through refcounted handles.
* You can declare and define new object types almost on the fly.
* Functors (if you don't know functors, think late-binding) are a basic type and have very simple syntax.
* There's a set of GUI classes in Carbon. It's slim so far but getting better.

And the greatest feature of all:

* Since it's implemented using standard C++ tricks, you can use iC objects as regular C++ or ObjC types without any issues!

I'm going to develop this to the point that there will be a real opensource alternative to RealBasic...and it'll follow the Mac Way.

Does this sound interesting to anyone? I'm just wondering if I should make the effort to go public now...or wait a while. I guess it'll be another month of work on the GUI stuff at least, plus I guess I'll learn YACC, Lex, and some other stuff, to get a proper interpreter (the one I have now just does expressions.)

Dan

[itistoday]

Umm... I don't really understand the extent of this. Perhaps some examples of what you can do with it would help?

[Chuckit]

Yeah, I'm kind of just confused.

[dangelder]

Buddha said, if you want to know the realm of buddhahood, you must make your mind as clear as empty space and leave false thinking and all grasping far behind, causing your mind to be unobstructed where it may turn. The realm of buddhahood is not some external world where there is a formal "Buddha": it's the realm of the wisdom of a self-awakened sage.

Did that help?

[Chuckit]

Everything's clear now...except what, exactly, the language "iC" is. Even the Buddha is left scratching his head, although he much appreciates the shout-out.

[dangelder]

Time to revisit the original message, then, perhaps.

[Samad]

Lex and Yacc are great tools to use. Switching to lex and yacc to write language parsers is recommended over writing them by hand because:

* Lex & Yacc is very fast and optimized
* Lex & Yacc will produce code that will be more reliable and bug-free
* Lex & Yacc code is more easily maintainable
* Writing code for Lex & Yacc takes far less time than by hand

However, learning them was rather difficult for me; that may not be the case for you. The biggest difficulty with lex and yacc is trying to find some good tutorials or books. Here's some information I've collected over the years:

* Check out http://www.epaperpress.com/lexandyacc/index.html. This is a great start. Go through the material here first.

* Go through http://www.flipcode.com/articles/scr..._issue01.shtml. This is a great crash-course in how to write scripting language parsers. After you go through this, you'll feel pretty comfortable.

* Get "Lex and Yacc" by John R. Levine, Tony Mason, and Doug Brown. The book does, frankly, a shitty job of explaining the power of lex and yacc, however it is a great resource as a reference book.

The problem with lex and yacc tutorials is that most of them are how to write your own algebraic calculator. However, the material above, especially the flipcode tutorial, will teach you a lot. The important thing to realize about lex and yacc is that it can do a lot more than create scripting/programming language parsers. If you're still not satisfied, look for popular compiler theory books, as any good compiler theory book will mention lex and yacc. Hope this helps.

[dangelder]

Ooh, that flipcode article is cool...

[Samad]

The flipcode tutorial is great because it goes beyond lex & yacc and into the world of parser trees and even into the world of virtual machines. If you really want to get into designing a good virtual machine and an opcode specification for it, check out "Designing Virtual Machines in C/C++" by Bill Blunden. The author goes through tirades against Microsoft and Linux distributions, but just wade through the ******** because there's plenty of great information. Once you know how to create a parser tree, a fairly easy task, creating an opcode specification and a virtual machine is straightforward.

[dangelder]

Actually I've written a number of interpreters before, but never with the formalized process of Lexx and YACC.

The thing about iC is that it really compiles using some C++ templates and headers and there's enough sugar to do some great stuff. For example I have a property class that basically does this (although there's way more to it):

template <typename T> struct Property
{
T value;
operator T() { return value; }
Property<T> operator =(T& newValue)
{
value = newValue;
DoComplicatedValueChangingFunction(newValue);
}
}

And then you can have for example a property in a window:
struct Window
{
property<string> title;
}

And then:

Window newWindow;
newWindow.title = "Super Great Window";

And that causes the title to change on the screen. That's the kind of language I want!

If you want to get in on it just for fun, join my new yahoo group...groups.yahoo.com/group/dgic

Thanks
Dan