Category talk:Go: Difference between revisions
Update on exception task, added notes on remaining omitted tasks.
(→In general, non-solutions: "... so long as there is an explanation of the caveats") |
(Update on exception task, added notes on remaining omitted tasks.) |
||
Line 40:
Similar reasoning to Create an object/Native demonstration. You could wrap an int in a struct, but you'd lose all the syntax and--worse for ints--type compatibility.
===Dynamic variable names
No variable names exist at runtime. Even the reflect package doesn't have them. (Field names, but not variable names.)
===Exceptions/Catch an exception thrown in a nested call (Solved!)===
The specific wording of the task description excludes Go. It specifies that foo call bar, bar call baz, and foo catch U0. The only execption-like mechanism we have is panic/recover. If foo defers a function that uses recover, it can catch a panic, but it ''cannot continue executing.'' Deferred means deferred to the end and foo is ending one way or another the first time a panic gets to it.
Line 51 ⟶ 50:
:: OK, with hindsight, the task might be better ''described'' as "Exceptions/Catch one of two exceptions thrown in a nested call"; but it is unwieldly for a title. I think the title is not misleading, just a precis of the task requirements. --[[User:Paddy3118|Paddy3118]] 11:43, 30 April 2011 (UTC)
Update: Solution posted! After some gnashing of teeth, and ultimately eating of words, I settled on a pretty good rendition of the try/catch pattern to post for this task. It doesn't meet the task to the letter, but I think certainly does in spirit. —[[User:Sonia|Sonia]] 01:45, 3 May 2011 (UTC)
===Extend your language===
Go isn't extendable natively, and standard libraries aren't quite yet up to the task of implementing Go in Go.
===Introspection===
This one might be doable...have to play with the debug/gosym package...
===Jensen's Device===
Sure you can do something similar with closures, but they won't walk or quack like call by name.
===List comprehensions===
Go is low-sugar. I think a valid solution to this one should have readable syntax. Go function literals cobbled together in a variadic function call would look hideous and not look anything like set-builder notation.
===Matrix-exponentiation operator===
No operator definition or overloading. Pretty cut and dried.
===Memory layout of a data structure===
Again, maybe with debug/gosym...
===Metaprogramming===
The Wikipedia entry on metaprogramming says it encompasses cross-translation, so for example, use of the go template library to generate HTML might count. The task definition however, specifically cites changing the host language, what the WP article calls reflexive metaprogramming. This puts it in the category of the Extend your language task, which I don't believe is doable currently in Go.
===Named parameters===
While it's tempting to use the struct-as-argument-list trick I showed with the Optional parameters task, this task is pretty specific about use normal function call syntax. It also mentions safety critical applications, and the struct trick, which allows arguments to be omitted, would seem a step in the opposite direction of safety.
===Partial function application===
Lots of good discussion on the talk page. I had a closure-based solution submitted at one point that involved repeated type definitions, but in discussion it came out that the task author felt correct solutions did type manipulation to derive one function type from another. Go has no features for this, either at compile time or run time. I happily retracted my submission.
===Pattern matching===
My reading of the WP algebraic data type article is that Go has no way to do this.
===Respond to an unknown method call===
Static, static, static. Go is static.
===Shell one-liner===
Go has no standard interpreter...yet.
| |||