Saturday 23 July 2011

Literal syntax

I've been thinking again about literal syntax- that is, defining type literals.

type t = new type;
t.public_functions.insert("DoStuff", [&](this) {
        return 1;
});

type t {
    DoStuff() {
        return 1;
    }
}


Is the first form really that bad? I could just cut the second form entirely. It would be a bit ... strange, I guess. The literal is more natural. But I honestly can't think of any reason to actually keep it, and ditching it would save the grammar from having to deal with it. I could also avoid having to deal with "this" as a keyword- along with many other keywords I've managed to eliminate. Like, say, dynamic_cast, and new. I wonder if the other cast keywords can also be eliminated?

If I went with form 1 instead of form 2, I could have public/private/protected just as strings.

Could it also be used to remove declarations/definitions? I mean as an implementation detail. When a function is added to the type, then it doesn't have to make full semantic sense until the pass is complete and the type is instantiated. Adding the function would effectively "declare" it. If all functions were written in Form 1 instead of Form 2, then I would never need declarations.

The problem is that some devs may well find it unintuitive. It's one thing to attract people with "You can do whatever the hell you want" and another to say "You have to write in this new crazy syntax". And what about free functions? Whilst it would be great to transform Form 2 into Form 1, I'm not sure that dropping Form 1 would actually be a smart idea.

No comments:

Post a Comment