← Back to team overview

ooc-dev team mailing list archive

Re: Fwd: OOC best practices


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

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.


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

Follow ups