| Version 10 (modified by hopscc, 12 years ago) |
|---|
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, 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
ticket:120
Finish Type Inference
Type inference of method references and lambdas is currently not done requiring specification of an explicit (sig) type.
This should be (better) supported
ticket:29 and ticket:204
Builtin support for Regular expressions and literals
Language support (expressions and literals) for Regular expressions
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:
.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 (~):
.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:
this is a cool idea, if the order is implied by convention, then the full do will not be needed.
for example some languages have $1, $2 or %1 %2, so you can refer to the correct ones.
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.
e.g:
.foo(~b / ~a + ~c)
comment:
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.
comment by Charles on 2012-12-12:
You cannot lose the tilde prefix because then you could not use local variables in the expression.
Also, see conversation in the discussion forum starting with heading "Lambda Syntax".
Comment by hops 2012-12-14:
Sure you can - just cant use local variable names that collide with the arg naming convention
(so the lambda arg naming needs to be an unconventional naming convention (:-))
Language support for multiprocessing
Language level support for creation, spawning and management of tasks or co-Routines and a safe communication mechanism between them.
Perhaps something along the lines of go
as in go concurrency patterns and 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:
For C# this is mostly removal/simplification/pruning, 90% of which can be done with a relatively simple (multiline) sed script.
(thought I'd done this already but evidently not). For the operations see the wiki:PortingC page.
Python may be a bit more problematical around converting its inbuilt library calls to .Net (from IronPython though?)
comment:
I also started on a tool like this (for C#), but like most of my projects, I get sidetracked. In any case, I was thinking it would be a big coup to have converters for both. Regarding IronPython?, I think that is a good idea (although not sure how to proceed intelligently), and there is even an IronPython? project from a few years back that allowed for importing a number of pyd files as well, so arguably there may be a way to not have to port the Standard Libraries.
REPL
It is possible I'm not aware of an existing implementation, but a command line interpreter for Cobra would be awesome. Perhaps something along the lines of http://www.mono-project.com/CsharpRepl.
Comment by hops 2012-12-14:
Theres some starting points for this on ticket:172.
think there was a forum topic we could reanimate as well.
