ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

Hey Iván,

First off, thanks a lot for taking the time to write thoughtful feedback
about ooc. I really appreciate it, and it's always useful.

Moving on to the heart of your e-mail, your wishlist really looks like our
TODO list! Except "Real closure support" oughta be there too.

The points you're discussing are raised regularly on the IRC channel (where
most of the development discussions happen), and have been answered partly
numerous time, but now is probably as good a time as any to sum it up in a
coherent post.

- Properties. We have a
proposal<http://github.com/nddrylliog/rock/blob/master/samples/upcoming/properties.ooc>for
that. rock is our upcoming ooc compiler, written all in ooc, and it's
bound to deprecate j/ooc (the java compiler implementation) in the next few
months, hence for now language evolutions are written in small example
sourcecode in the samples/upcoming directory of the rock distribution. Feel
free to comment on the proposal, if you have ideas for improvements, or
simply if it's good enough for you, which is nice to know too =)

- Metaclasses. rock goes a step further than j/ooc in that classes' class
are accessible from the ooc side directly (j/ooc used to hide all that in
internal C structs), but what's still missing is hashmaps of the variables,
functions, with type information, so it can be accessed entirely by
reflection. Also, one should be able to disable it for specific classes,
imho, to avoid unnecessary startup costs at runtime. This is unimplemented,
but planned. I'm not sure what you mean by "attaching some other classes to
it providing information" though, can you elaborate on that?

- Mixins. rock already has interfaces implemented (most of the functionality
is in), and from what I have seen, it'll be very, very easy to add mixin
support. It's just a matter of allowing bodies in interface definitions
(under the hood, interfaces are implemented with a class per interface, and
'fat pointers' with anonymous structs for interface function calling - read
the rock sourcecode if you really want more details, or wait for the GREAT
manual ;) )

- Dynamic message resolution operator: What I had in mind is some kind of
methodMissing method that one could define, and would turn any unresolvable
member method call into a call to this method with the name of the message,
and the args of course, so you can relay it to whatever you chose at
runtime. How does this sounds to you? Not an operator per se, but provides
the functionality you need imho, and integrates well. (In the same spirit,
maybe a fieldMissing method? To allow, for example, easy DOM traversal for,
say, XML documents)

- Macros: one of the most cruelly lacking part of ooc right now,
meta-programming is of course a major challenge for the (near) future. Dumb
text replacement is not an option, I've always wanted to make it AST
manipulation, which seems to correspond to what you are describing. The idea
of a "trigger sequence" and making chunks of the code parsed by "plugins",
then building the AST themselves, is a great idea too, which I look forward
to experiment with. It perfectly fits with the nature of ooc (slim by
default, but extensible/flexible at will), so this will definitely get
implemented. There will be discussion on the implementation though, as we
have to get it right almost the first time or people will complain (as they
always do, hehe)

- A GREAT manual: I cannot agree more with you. So far, I've been
concentrating on improving the toolchain, e.g. compiler work (which I think,
is where I'm the most efficient/useful), and holding back on documentation,
waiting for the language to stabilize. We haven't made all the good choices
the first time, and I'm glad we've kept the option to change things for the
better. That said, I'm trying to encourage documentation writing, and I'm of
course available for explanations on pretty much every part of the language,
its implementations, etc. I must mention the work of
fredreichbier<http://github.com/fredreichbier>,
who has done an outstanding job with
ooc-docs<http://github.com/nddrylliog/ooc-docs>,
with Sphinx integration, mirroring of the docs and automatic uploading on
our website <http://docs.ooc-lang.org/>, and documenting parts of the SDK.
As for the manual itself, I'll probably spend more time on it as soon as we
have an official release of rock (that, and a few announces on news sites)

Among the things you haven't mentioned but are in the works,
joshthecoder<http://github.com/joshthecoder>has been adding networking
APIs <http://github.com/nddrylliog/ooc/tree/master/sdk/net/> in the SDK
(he's looking to do serious server work), and as I said earlier,
showstopper<http://github.com/showstopper>and I will be working on
proper closure support, using the yajit
project <http://github.com/nddrylliog/yajit>.

If you want to do English->Spanish translation for the future manual, you're
welcome, I'll keep you posted =)

As for an ETA concerning the various features above, it's hard to tell.
Could be anywhere from "tomorrow night" to "in a few months", depending on
my inspiration, current needs and projects, motivation, and free time of
course. Still, things happen surprisingly fast in ooc-land, so stay tuned.
I'm kinda holding back on new features at the moment, trying to make rock
compile itself (yes, you read me right - we're going self-hosting very
soon), but this is only temporary.

Thanks again for the awesome feedback & advice!

Amos Wenger, aka nddrylliog

2010/2/24 Iván Hernández Valmisa <ivanhv77@xxxxxxxxxxx>

>  Hi, everyone.
>
> Recently I found ooc. It's amazing how it molds to some language syntax
> ideas I had for a language (messaging with no dots like in IO, lambda
> functions syntax, an easy to type symbol for method chaining, type inference
> in preference of dynamic types, an easy way -like covers- for ffi and c code
> interoperation...)
>
> But, being an active C# programmer, a previous C++ expert (yes, I know
> that's not possible ;)) and a lisp/scheme
> don't-get-the-whole-point-but-looks-like-if-it-rocks I find some real
> missings on current ooc language. It would be great to know what are the
> expectations for implementing this on the specs of ooc (I assume ooc
> language definition is no actually carved in stone):
>
> - Properties (or getters/setters). They can be treated as a syntax trick if
> reflection on these is not a requirement. So easy to implement (as syntax
> sugar) and so easy to read on written code... They work like methods (they
> would be c functions in translated code, in fact), but they taste in ooc
> like regular attributes of an object.
>
> - Metaclasses (like c# class attributes or java adornments). When you
> declare a class, you can attach some other classes to it providing
> information (and functionality) related to this class. In c#, the most
> pragmatic example is the class XmlSerialization, that states a class can be
> serialized to Xml and provides the necessary code for doing it at start
> time. By the way, I find Python or Lua style metaclasses much less useful in
> a static language.
>
> - Mixins. In a language with single inheritance, they are required if you
> don't want to pollute your namespaces with little classes with lots of
> common code for providing interface implementation. (There are other
> solutions, but mixins like in D language seems to me the most effective way)
>
> - Dynamic message resolution operator. In a static language it seems a bit
> weird to provide something like this, but being able to dynamically change
> message calls functionality is eventually so useful, that being able to do
> it with an special syntax feels great (even on a language that was supposed
> to work with static typing). Fan is a recent language that incorporates
> this.
>
> - Macros (can they be hygienic, please?). In a language that it's not
> homoiconic, could be difficult to implement and use, but they are designed
> to do what c++ templates were forced to do and allow for code generation in
> static time. That means all the previous points in the list could be
> implemented in terms of compiler macros. As a weird alternative, I was
> thinking in the possibility of having something like "compiler plugins". The
> programmer declares a word/sequence of symbols as a kind of trigger, that
> will make the compiler look for it's corresponding plugin: an external
> process that will parse itself the associated code and that'll generate occ
> code on it's standard output, being captured by the compiler and replacing
> the original macro call text. It would be like having an external macro
> processor (as m4 is), but embedded within the compiler. All this would open
> ooc to the world of DSLs and something like LINQ could be implemented in
> terms of macros, instead of having to incorporate it to the compiler.
>
> - A GREAT manual. "Great" in caps. It should describe the language, so
> there's no doubt what it can do and how.
>
> That's my point of view of what would be great to see in a modern language
> like ooc. I really feel the manual is a requirement and properties and
> mixins are a "must have", being the other options great features everyone
> could pass without but would enrich any language.
>
> Is there any thoughts about incorporating any of these in ooc in a future
> (let's say from "just now" to "your grandsons will see all those")?
>
> By the way, I'm from Spain, and must apologize for my loose English.
> Anyway, I hope it's good enough to properly translate an English text to
> Spanish. Even a GREAT manual. So if you need some help with this some day...
>
> Greetings.
>
>
> ------------------------------
> Elige un juego de Messenger. Reta a un amigo. ¡Pruébalo ya!<http://www.messengergamesclub.com/spain/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> More help   : https://help.launchpad.net/ListHelp
>
>