ooc-dev team mailing list archive

[Wander Nauta <info@xxxxxxxxxxxxxx>]

Again, greenhorn here...

Maybe it's a little offtopic, but I was thinking a while back of something
you could call 'compiler-run functions' or macros if you wish. These
functions should look like regular ones when used, but are not converted
into C but instead recognized by the compiler. So...

if (version("windows")) {
    // do something windows-specific
}

shouldn't converted to a real if, but is instead recognized by rock to mean
'Only parse the following code if compiler is on Windows'. You could also
think of something like...

if (hasFeature("ACS"))) {
    // Use closure oneliners
}

if (!hasModule("lang/types") {
    This really never happens, so I can put anything I want here (except a
curly brace of course)! It's not parsed, see.
}

match statements, negation, 'and', 'or', should all work like they do
normally.

I think reusing existing 'if's and 'match'es would be cleaner then using yet
another keyword.

Again, this is just my 2c, and thank y'all reading.

Wander

On Wed, May 12, 2010 at 23:44, Scott Olson <scott@xxxxxxxxxxxxxxx> wrote:

> I think macros should be kept as much "just ooc" as they can be. We don't
> want
> a separate preproccessor like C has, but macros more like Lisp, which are
> within the language itself. I think I've heard nddrylliog mention macros
> that
> could do things with AST nodes, etc. They could possibly be defined just
> like
> functions:
>
>        Vector: macro { ... }
>
> On Wednesday 12 May 2010 06:34:15 Amos Wenger wrote:
> > I'm not sure. #foo macro vs # comment seems to confusing / easy to make a
> > mistake.
> >
> > Ideally one could use # in any context, such as:
> >
> > Vector3f := #Vector(3, Float)
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>