Category talk:Go: Difference between revisions

m
Note a couple of omitted tasks.
(update after solution of shell one-liner.)
m (Note a couple of omitted tasks.)
 
(4 intermediate revisions by the same user not shown)
Line 28:
Go has no dynamic type defintion. All data types are determined and fixed at compile time.
 
===Calendar - for "real" programmers===
===Arena storage pool===
Starting with "package," Go programs use lower case.
Go uses a single arena, created at program load and managed by the Go runtime. Mmap is available as a syscall, but Go offers no support for initializing a raw block of memory like this as a usable heap and no support for working with multiple managed heaps. Its multiple stacks, I believe, are created within this one arena.
 
===Call a function in a shared library===
Line 41:
 
===Dynamic variable names===
No variable names exist at runtime. Even the reflect package doesn't have them. (Field names, but not variable names.) Of course the task does mention "Eval in environment," so perhaps a solution using go-eval would be acceptable.
 
===Executable library===
Go offers no way to do this. All Go code relies on the Go runtime, which is initialized at program startup.
 
===Extend your language===
Go isn't extendable natively, and standard libraries aren't quite yet up to the task of implementing Go in Go.
 
===IntrospectionFirst class environment===
There's been some great work done towards Go evaluators, but this isn't really even on the horizon.
This one might be doable...have to play with the debug/gosym package...
 
===Include a file===
The Go authors would be quite dismayed if it were discovered that this was possible.
 
===Jensen's Device===
Line 57 ⟶ 63:
===Matrix-exponentiation operator===
No operator definition or overloading. Pretty cut and dried.
 
===Memory layout of a data structure===
Again, maybe with debug/gosym...
 
===Metaprogramming===
Line 66 ⟶ 69:
===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.
 
===RespondStart tofrom ana unknownmain method callroutine===
From the task description: "Languages that always run from main() can be omitted from this task."
Static, static, static. Go is static.
 
===Topic variable===
Not in Go. Go's pretty explicit about most things.
 
==Once omitted, now solved!==
===Arena storage pool===
Go uses a single arena, created at program load and managed by the Go runtime. Mmap is available as a syscall, but Go offers no support for initializing a raw block of memory like this as a usable heap and no support for working with multiple managed heaps. Its multiple stacks, I believe, are created within this one arena.
 
Update: Solution posted using sync.Pool. It's no mmap solution, but I think it satisfies the general wording of the task. An mmap solution, probably with cgo, might still be interesting some day.
 
===Exceptions/Catch an exception thrown in a nested call===
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 86 ⟶ 94:
 
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)
 
===Introspection===
This one might be doable...have to play with the debug/gosym package...
: okay, definitely doable. I've figured out how to load the symbol table and locate the symbols, now just to decode the type information, do the manual type checking, and set up and execute a function call... —[[User:Sonia|Sonia]] 04:23, 29 May 2011 (UTC)
 
Update: Solution posted. It's kind of a partial solution because I didn't decode the types, but I'd had this code sitting around and I wanted to post what I had. —[[User:Sonia|Sonia]] 13:25, 9 June 2011 (UTC)
 
===Memory layout of a data structure===
Again, maybe with debug/gosym...
 
Update: Solution posted. On closer reading of the task, all it wants is symbolic references to bit positions. Go does this with constants.
 
===Shell one-liner===
Line 91 ⟶ 110:
 
Update: Solution posted. The task really just says ''avoid'' relying on the shell. Doesn't say you can't, if that's the only way to do it. Two solutions posted, one kind of a hack and the other practical, using a popular external command that can be installed. —[[User:Sonia|Sonia]] 22:18, 27 May 2011 (UTC)
 
===Respond to an unknown method call===
Static, static, static. Go is static.
 
Update: Solution posted. An anonymous comment on the ''Send'' an unknown method call talk page mentioned reflection, and I thought, "a-ha! Go can do that." A solution to this task seemed possible as well.
 
==Once solved, now omitted==
===Inverted syntax===
Go had this quirk at one point. The language was changed before Go 1 and is now free of any inverted syntax. [http://rosettacode.org/mw/index.php?title=Inverted_syntax&oldid=123161#Go The removed solution]
 
===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. [http://rosettacode.org/mw/index.php?title=Partial_function_application&oldid=104758#Go The removed solution]
 
===Proof===
It was a frustrating exercise.
 
Go has long had a Peano number program in its test suite. Without consulting it first, I tried coding up my own version from scratch. Checking my work then against the program from the Go test suite, I decided the test program was lacking rigor. Wanting my program to not only be better, but to represent some sort of "proof," I studied the Peano axioms, the Go language specification, beefed up my implementation and added lots of comments showing how the axioms were met by either language guarantees or the code.
 
Also—perhaps incorrectly—I added a mechanism so that equal Peano numbers could be compared equal with the built in == operator. The conventional way, I believe, would be by recursive function. But by registering each Peano number visited in a map, objects representing numbers could be maintained uniquely, so that a given number would have only a single object in memory. This added to the complexity of the program and perhas obscured some issues.
 
A second obscuring issue is that on the talk page someone was explaining how the task might be solved in C++ and stated, "The proof is whether or not the proper code compiles." As seen in later discussion on the talk page, this approach was not seen as credible.
 
Oh, and then I mixed up some variable names...
 
Finally, at the time I posted my implementation, "dependent types" was not mentioned in the task description but only in a comment on the talk page. I had read the comment, but being unfamiliar with the term, did not appreciate the meaning from the context. Only later was the task description updated with a WP link, educating me that a ''dependent type'' is one where the type of an object is determined by its value.
 
[http://rosettacode.org/mw/index.php?title=Proof&oldid=124926#Go The removed solution]
 
In retrospect, I still don't know if an acceptable solution can be written in Go. The one mechanism it has that might be used as a dependent type is the interface type. An interface type holds as its "value", both a concrete object and the type of the concrete object. Thus the type stored inside can change depending on the value stored inside. My solution used interface types, but did not mention dependent types. I do think a valid solution to the would have to clearly point out how it was using interface types as dependent types.
 
Also, the now-linked WP pages mention things like Curry–Howard correspondence and constructive proofs, things I am unfamiliar with. If the task intent is to "do what the proof assistants do" then I suspect a valid Go solution would need to explain in the proper terminology that it is doing something analgous. The task remains for someone who understands such things.
1,707

edits