Cobra Forums

Want to influence the direction of Cobra?
Cast your vote for the next delivered major feature.

as a Java backend would bring us one step closer to a D backend, i voted for .. .. JVM ^^

Closures. A modern language cannot miss them.

Difficult choice here!

I voted for DLR because it makes much sense with coming IDynamicObject from the perspective of cobra being a .NET language.

However I can't see the implication of such changes (I presume it may be huge) and maybe would steer cobra away for multiple back-end which also seems a great thing (I mean multiple backend).

If this wasn't proposed, I would have voted for closure.

Just to be clear, I expect all the items in the survey to eventually be done. So this is just about which to deliver next.

Please don't add curly braces.

I didn't mean we would lose the current syntax. I meant that you would have the choice between the current syntax or the curly. This has been requested more than once.

Kurper wrote:Please don't add curly braces.

I agree here. What is the point? I can understand that you lose cool features from cobra as: contracts, inline tests, etc. But you have so many OO curly braces languages to choose from: C#, Java, Groovy, Scala, C++, D, ... most of them work on .Net and/or JVM and are getting or already have some of those features.

Besides that, code sharing/reuse may be harmed a lot, unless you do a --no-curly syntax similar to --correct-case

Also trend is quite the opposite, languages as Wirbel (http://mathias-kettner.de/wirbel.html ) and Shed-skin (http://code.google.com/p/shedskin/) are trying to make it easy to code as C++ with "python" syntax.

By the way I chose JVM as a step for D so we cover all those platforms (.Net, JVM, native) and code (and maybe reuse some code from other platforms) in cobra whatever the task you need to accomplish.

agustech wrote:

Kurper wrote:Please don't add curly braces.

I agree here.

totally agree with everything agustech said

that could destroy this language. imagine all the curlybracers start sharing their 'cobra' codes..

Closures are local functions that capture their scope (they enclose their context) independet of whether they are named or unnamed. The technical term for anonymous functions is normaly lambda function, or lambda expression (from lambda calculus). Unnamed local functions that aren't closures aren't very interesing, so you won't find them in many languages, and lately as many languages get lambdas that are closures the term seems to be more and more abused.
See for example Scheme that only has anonymous functions (defined with ... "lambda" ).

Code: Select all

(define foo 10)
(define bar (lambda (arg1 arg2) body))


It went a little confusing in C# lately as they have anonymouse functions as "delegate(args) {...}" and as "(args) => ..." and Microsoft calls the latter "lambda expression" the former "anonymous methods". And C# additionally has the (a bit Lisp-macro-like) ability to interprete a lambda-expression as it's syntax tree, and now some people seem to think that this ability is something that has to be there to call something lambda (which of course is wrong).
Lambda simply comes from the lambda-calculus.

Anyway, I vote for closures and anonymous functions.