ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

Not answering to everything here, but I'd like to bounce on a particular
subject that was brought up: meta-programming syntax.

It's true that not using '#' for macros does make sense, and would allow fun
things, such as gist.github.com/429803

// namespaced import so we can replace sin/cos with our own fast versions
import lang/math into math

// constants
pi := const 3.14159; precision := const pi/48

// this will end up like huge array literals filled with the values of compute
sinTable := compute(math sin, 0, 2*pi, precision)
cosTable := compute(math cos, 0, 2*pi, precision)

// macros don't have return types - they aren't symbols, don't need to check
compute: macro (f: Func (Float) -> Float, min, max, step: Float) {
  // next line actually creates an array literal
  out := []
  for(x := 0.0; x < max; x += step) {
    // macro-specific semantics: means add something to the array literal
    out += f(x)
  }
  out // last expression is used as a 'macro return value'
}

sin: macro (f: Float) { sinTable[f / precision] }
cos: macro (f: Float) { cosTable[f / precision] }


This is probably a stupid
example<http://stackoverflow.com/questions/1588000/make-a-cosine-table-with-the-gcc-preprocessor>,
but it gives you an idea of what I have in mind, ie. syntax that
is parsable by the current rock (except the 'macro' instead of 'func'
thingy), but with semantics adapted
to macros (e.g. for building array literals), macro calls that are run at
compile time, etc.

Another imaginary example off the top of my head, showing other
suggestions/problems gist.github.com/429801

Vector: macro (N: Int, T: Type) {
    if(N < 1) {
        error("Vectors of less than 1 elements are forbidden")
    }


    VectorN: class {


        init: func {}

        length: func -> T {
            sqrt(
                \(+, for(i in 0..N) {
                    acc := VariableAccess new("e" + i)
                    (acc * acc) // last expression 'returned' implicitly
                })
            )
        }

        normalize: func {
            length := length()
            if(length == 0) return // don't normalize a null vector.

            \for(i in 0..N) {
                VariableAccess new("e" + i)
            } /= length
        }

    }


    for(i in 0..N) {
        VectorN += VariableDecl new(T, "e" + i)
        VectorN init args += AssArg new("e" + i)
    }


    VectorN name = T name + N
}

Vector(Float, \[2, 3])
Vector(Int, 256)

println("sqrt(2) = " + Float2 new(1, 1) length())


You can try to guess the semantics if you want =) Or there's a longer,
annotated version here: gist.github.com/429802

I reckon it all looks quite crazy - but hey, one can dream. I'm listening
for your crazy suggestions as well. Shoot!

Amos (nddrylliog)

2010/6/3 Iván Hernández <ivanhv77@xxxxxxxxxxx>

>
> >         try
> >         to program a Java to ooc translator (just to have some fun
> >         trying to
> >         port SWT to ooc language, like it was done with D)
> >
> >
> > That would be interesting - they really did it that way with D? Seems
> > quite complicated. (Especially since the foreign interfaces of D/Java
> > look different)
> >
> In fact there were two or three different approaches to SWT in D. Java
> translator was one of them. The problem with that approach is
> translating semantics and libraries. Translating syntax can be automated
> within relative ease, but whe you find something like:
>
> StringBuilder s = new StringBuilder("foo"); s.add("bar");
>
> You must change the type and it's methods in target language, so it
> adheres to existing ones (in ooc you would declare a String type and
> accumulate more strings into it with the appropiate method)... or else,
> you create a compatibility layer, by adding types similar to those of
> Java (implementing the interface part you are interested on) and making
> their implementations employ target language's types (something like a
> Bridge Pattern). A project that takes this approach is, at some extent,
> is ikvm.net (although it implements jvm on .net runtime, some parts of
> it are translated for the sake of efficiency).
>
> Of course it's a hard hard work, but think on the benefits: by
> translating java.lang functions, you could progresively incorporate java
> libs into ooc (think on iText, hibernate or log4j).
>
> >          -- this is a comment
>
> >
> > Well - even though they look nice, why add them since we already have
> > '//' ?
>
> Of course. I read some discussion about one line comments previously and
> I stated my preference here. Actually, I'm mainly a C# programmer,  so
> '//' look just right for my eyes.
> >
> >         Sharp as macros are not (in my opinion) a good idea. ...
> >
> > That's true but it would be potentially easier to read/to understand
> > like "what is it he's calling here? is it a function? a macro?"
> >
> I don't believe that's a real problem. The great about macros (and just
> to be sure about what's the topic here, I'm thinking in macros like in
> scheme with higyene and all) is that you can forget about what they are
> most of the time. That's not true with C #defines, where you must be
> careful not to catch some variable, not to generate wrong syntax code).
> >
> > Yeah I'm not sure about pragmas - what would they really be used for?
> > I mean, most settings can be controlled with compiler command-line
> > flags, so.. I don't know.
> >
> Of course, pragmas should not be used instead of compiler commands. It's
> nonsense to think they're going to replace them. But think the useful it
> would be to disable a warning in a point of the code, changing the byte
> packing size on a single structure or even declaring directives for C
> compiler (like if it should do C, pascal or stdcall calling styles on a
> function)
> >
>
> Greetings
>
> > P.S: Hit 'Reply All' next time, your answer was only sent to me.
> >
> I'll try not to forget it, thank you.
>
>
>