Shortcut syntax idea for catch

[Charles]

Now I challenge you to implement it.

Hints:
-- Enhance the expression portion of the CobraParser to accept the new try expression.
-- Make a new TryExpr class in Expr.cobra which the parser will create.
-- Also add TryExpr to SharpGenerator.cobra in BackEndClr
-- Look at other expression classes like IfExpr to get an idea of what's needed. Monkey see, Monkey do.
-- I believe you'll also need a helper method in Cobra.Lang\Native.cs. You'll see other helper methods used to implement features that C# does not have.
-- I believe the key to delaying the execution of the expressions is to use delegates.

You may wish to log into Trac (using the same user id and password as here on the forums) and accept ticket:86. Or not, if you're not sure how far you'll get and don't mind if someone happens to work on this too.

If you get that far, see HowToSubmitAPatch. Or even check that out ahead of time for information on coding style, testing, etc. Attach the patch to the ticket.

Also, see Developer\ImplementationNotes.text in the workspace.

I'm still in the middle of streams right now and after that will likely be cues...

[helium]

Oh, haven't seen that the thread has a second page.

I'm sorry. I don't have time to help you out. I currently have a big hobby project on my own.

[hopscc]

I've been taking a look at implementing this and it seems that for the case of an arbitrary embedded tryCatch expression , given the .Net2.0 base and lack of cobra method type inference, its not readily doable ( or at least not without large transforms of the AST or some complex cross communication and code munging at code generation level ).

( The problem is wrapping the trycatch expression in generated code so that it returns just the expressions value at the point the expression is called:
closures - simply Net2.0 closures, need explicit method signatures or csharp type inference (var). However even .Net3.5 csharp type inference doesnt do this for methods - or at least not for the cases I tried...
Using a compiler generated helper method generation needs to be able to detect the input values into the try-d expression to pass them to a wrapping helper,
combinations of the above need either or all of above or autogen or discovered method signatures
...
)

However what is readily simply doable is support of a simplified case where the trycatch expression is (only) the target of an assignment which fortuitously seems the most normal case and is in fact all that has been discussed in the examples previously.

At worst it just means a arbitrarily nested expression has to be broken out some

i.e

degC = try int.parse(inputString) catch FormatException get -373 
degF = 32 + degC * 5 / 9
assert degF > -273

is good

degF = 32 + try int.parse(inputString) catch FormatException get -373  * 5 / 9  #   compile error
assert degF > -273
# or something like
.displayStore('PercentDone', try String.format('{0:P}', reading) catch FormatException get "---")

Is not.

A partial solution but preferable to nothing.

Patch coming on ticket:86

[vmavra]

That's ok in my opinion, but in large code it could make it harder to spot the 'catch' statement, with 'try' you at least know you'll find a 'catch' statement later in the code.

Anyway i love the features and syntax of Cobra so looking forward to it and thanks for all your work, Charles!

[Charles]

Hops, I edited your message to use the <cobra> </cobra> tags instead of <code> </code>. We get syntax highlighting that way which is easier to read and it also revealed a missing quote for a string literal.

For getting this to work in the general case, I largely agree with your analysis. But aren't the delegates required for the try-part and get-part fairly straightforward? I think they would take one parameter of the expression type and return the same type. Other than "sharp code literals", Cobra knows the type of an expression at compile time.

I have to think about it some more. I need some food and sleep right now.

[hopscc]

Ta - sorry bout that - I keep forgetting about the cobra syntax tags

Re the delegate part type capture:
Its easy enough to get/determine the expression return type (and get-part expr type) for a synthesized method and call - the problem are the arg values/types

You cant use the type of the expression because then you'd have to evaluate it as the delegate/method is called (losing the try-catch wrap and the point of the exercise).
Instead you need to explicitly or automatically (back end support closure) capture the (local) variables used in the expressions

e.g In the preceding example the try and get expression types are ints but the bit needed for any delegate/method call is the string arg to int.parse - so in this instance a wrapped call should gen something like

#degF = 32 + try int.parse(inputString) catch FormatException get -373  * 5 / 9
# Using a autogen method should generate to code roughly like  
degF = 32 + _tryCatchExpr_666( inputString) * 5 / 9
...
def  _tryCatchExpr_666( inputString as String) as int is private 
    retVal as int = 0
    try
         retVal = int.parse(inputString) 
    catch FormatException 
        retVal = -373 
    return retVal

# more generally if the get values wasnt a literal it would be evaluated at the method call and passed in as well
degF = 32 + tryCatchExpr_666( inputString, -373) * 5 / 9
...
def  _tryCatchExpr_666( inputString as String, getExpr as int ) as int is private 
    retVal as int = 0
    try
         retVal = int.parse(inputString) 
    catch FormatException 
        retVal = getExpr
    return retVal

To do this you'd need to walk the try-part expr AST, extract out use of any variables/Ids, pass them to the synthesized method and synthesize a method with the same types and names that are then used in the wrapper synthesized method

My original thinking about this was that you;d need to capture all the variables and calls used and pass them as args to the synthesized method/expression wrapper
I balked at the tree-walk analysis and capture which seemed liable to be needlessly complex and error prone.

(Coming back to it again now I think capture of just the local variables is sufficient - everything else - literals and fields and call expressions are all fine - can be used as is in a synthesized method.

[Charles]

But C# already supports anonymous methods so you can leverage that instead of re-implementing it. See Anonymous Methods (C# Programming Guide) and imagine generating something like:

Code: Select all

// C# code
// rough sketch here
x = _tryCatchExpr_666(delegate() { return s.Length; }, delegate() { return 5; });


I haven't tried this out yet, so I could be missing something. But note that Cobra's C# back-end is already using anonymous methods for such delayed execution. See the implementation of ForExpr code gen in SharpGenerator.cobra for an example.

And if you'll be generating Cobra nodes for this instead of C# text, you can probably instantiate our AnonymousMethodExpr node which then generates a C# anon method.

[hopscc]

OK - got a full version using that working for .Net
- all it needs is a signature and couple of genericised helper methods in CobraLang.dll and the code generator to provide the return type to
instantiate the generic call and make the delegates.
The C# compiler (ver 2.0) then infers the correct type on the delegate without it needing to be specified and makes a closure correctly,
capturing any local variables....

The Java backend doesn't do any of this as it doesn't have closures yet so that's limited only to simple assignments still.

patch will be appearing on ticket:86 momentarily

[Charles]

Thanks to hopscc this is now available. Patch applied.