== Introduction == This is the wish list. Don't be shy. Jot down your wishes here, or if it's something that really needs to fixed or done, [http://cobra-language.com/trac/cobra/report fill out a ticket]. You can also start by mentioning these things on the discussion forum or IRC. == Support .NET Extension Methods == Cobra has its own extension methods. It does not, however, pick up on extension methods declared in C#. == Partial Classes and Debugging == Debugging information for partial classes gives the wrong filename for every partial class declaration except the first encountered. This makes for incorrect stack traces and makes interactive debugging impossible. == Support multiline Strings == Multiline (including embedded newlines) for templating or literal text chunks with or without substitution expression support[[BR]] [http://cobra-language.com/trac/cobra/ticket/120 ticket:120] == Finish Type Inference == Type inference of method references and lambdas is currently not done requiring specification of an explicit (sig) type.[[BR]] This should be (better) supported[[BR]] [http://cobra-language.com/trac/cobra/ticket/39 ticket:29] and [http://cobra-language.com/trac/cobra/ticket/204 ticket:204] == Builtin support for Regular expressions and literals == Language support (expressions and literals) for Regular expressions[[BR]] [http://cobra-language.com/trac/cobra/ticket/174 ticket:174] == Proper Timeout mechanism == as part of simplifying the complicated things: a timeout keyword. the semantics and what it should actually do are debatable, but there should be an option for each scenario. for example, closing down a bad request, or maybe just resuming the code flow, maybe forcefully releasing resources, etc. I saw timeout integrated in the TCL language. (they had the os be the external "superviser" managing the time) I think erlang also has it, I don't remember maybe it was called 'after'. ofcourse erlang is a very different language, and its design and constructs reflect that. with the advent of c#5 it is now easier for the developer: async, await .. it's harder to get this wrong. ideally, the language can help the developer not even get to deadlock situations, race conditions etc. no shared state was erlang's solution, there are coroutines, mailboxes and message-passing in other languages. making the right constructs go a long way in this regard. in Eiffel, they now have scoop, which as i understand is something like a locked access to a resource, without manually wrapping the value in a class to do the locking. it solves a different part by (sort of) declaring dependencies. I think it is too complicated for a novice programmer to get right in C#. maybe cobra can provide an alternative way, where the tricky parts will be done by a library or compiler. == Eliminate argument repetition in lambdas == Like many languages with lambda expressions, Cobra requires you to repeat arguments at least twice; once for the parameter declaration and once for using it: {{{ #!cobra .foo(do(a, b)=a + b) }}} I propose a "succinct" form for lambdas where the lambda is implied by prefixing the arguments with a tilde (~): {{{ #!cobra .foo(~a + ~b) }}} This will look extra sweet when stacking up multiple LINQ calls or any other API that makes heavy use of lambda expressions. Note that one disadvantage is that if the expression needs to use the arguments in a different order then you will have to use the full "do" form. comment:[[BR]] this is a cool idea, if the order is implied by convention, then the full do will not be needed.[[BR]] for example some languages have $1, $2 or %1 %2, so you can refer to the correct ones.[[BR]] but a, b, c would be far better. since it's a lambda it's presumed to be short, and not general, so arguments like a b c work fine.[[BR]] e.g: {{{ .foo(~b / ~a + ~c) }}} comment:[[BR]] If its using a convention anyway lets go the full route and just use a,b,c,... ( or something 'conventional') for the ordered lambda args and can lose the tilde prefix entirely. == Language support for multiprocessing == Language level support for creation, spawning and management of tasks or co-Routines and a safe communication mechanism between them.[[BR]] Perhaps something along the lines of [http://golang.org go] [[BR]] as in [http://golang.org/doc/articles/concurrency_patterns.html go concurrency patterns] and [http://golang.org/ref/spec#Channel_types go Channels] == Conversion Tools == Tools to assist in converting source code from C# and Python to Cobra. Not nec. perfect, but even 90-95% would be awesome. comment:[[BR]] For C# this is mostly removal/simplification/pruning, 90% of which can be done with a relatively simple (multiline) sed script.[[BR]] (thought I'd done this already but evidently not). For the operations see the wiki:PortingC page.[[BR]] Python may be a bit more problematical around converting its inbuilt library calls to .Net (from !IronPython though?) == See Also == * HelpWanted * [http://cobra-language.com/trac/cobra/report Tickets] * LanguageTopics * WikiStart