[go-nuts] Re: Experience report on a large Python-to-Go translation

[Brian Candler]

Very insightful.

I am relatively new to go, but I would like to make a few observations.

1. When the issue of keyword arguments has come up before, usually someone 
suggests passing a struct as the function argument.  Did you try this?  It 
might be worth mentioning in your analysis, if only to give an example of 
why it wasn't a good match.

2. I notice some potential overlap between a couple of features you 
mention.  The first is map(f,x) for mapping a slice of arbitrary type 
(incidentally it couldn't be called "map" for obvious reasons)  The second 
is using generator functions as ranges.

It occurs to me that if you could initialize a slice from a generator 
function, you'd have another way to achieve your map. The generator 
function could also do filtering, making it more like a comprehension.

3. A generator function would have to maintain its own thread of execution 
independent from the recipient - much like a goroutine.  So this might end 
up looking very similar to a function which stuffs values down a channel, 
which is option 3 in the linked article 
.

The problem with garbage collection needs to be dealt with, which at the 
simplest could be that the receiver closes the channel when done. Today 
this would cause the sender to panic, so that would need to be dealt with - 
perhaps some sort of "soft close".

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fdd4882f-0c17-42f2-b301-ab65e5ce08a7%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Saturday, January 25, 2020 at 5:43:24 AM UTC-5, Brian Candler wrote:
>
> 1. When the issue of keyword arguments has come up before, usually someone 
> suggests passing a struct as the function argument.  Did you try this?  It 
> might be worth mentioning in your analysis, if only to give an example of 
> why it wasn't a good match.
>

I'm picky about when I'll do that.  I view putting a bunch of items in a 
structure as a promise to people reading the code that the structure isn't 
just a vacuous shim but captures an interesting chunk in the ontology of 
the program.  "They're all arguments to this function" isn't interesting 
enough. 

2. I notice some potential overlap between a couple of features you 
> mention.  The first is map(f,x) for mapping a slice of arbitrary type 
> (incidentally it couldn't be called "map" for obvious reasons)  The second 
> is using generator functions as ranges.
>
> It occurs to me that if you could initialize a slice from a generator 
> function, you'd have another way to achieve your map. The generator 
> function could also do filtering, making it more like a comprehension.
>

Perhaps. But map-over=sequence seems to me like a simpler primitive idea 
than "comprehension" and thus preferable.
 

> 3. A generator function would have to maintain its own thread of execution 
> independent from the recipient - much like a goroutine.  So this might end 
> up looking very similar to a function which stuffs values down a channel, 
> which is option 3 in the linked article 
> .
>
> The problem with garbage collection needs to be dealt with, which at the 
> simplest could be that the receiver closes the channel when done. Today 
> this would cause the sender to panic, so that would need to be dealt with - 
> perhaps some sort of "soft close".
>

And that's the insight that led be to the extension I proposed. I asked 
myself what the most natural way to pass out a soft close might be.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/04b5ee2c-40d0-4275-a53a-eaad9828c849%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Tom Payne]

Really interesting post, thank you.

On iterators without leaking goroutines, have a look at the standard library's 
bufio.Scanner and database/sql.Rows. These provide easy iteration over 
arbitrary sequences in a compact idiomatic form.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6811412c-cf53-4626-b26b-70e868610d59%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

I spotted a typo:

On Saturday, January 25, 2020 at 3:46:19 AM UTC-5, Eric Raymond wrote:
>
> The Go translation of reposurgeon is better - more maintainable - code
> than the Python original, not just faster.  And this is because I
> rewrote or refactored as I went; as I've explained, I tried very hard
> to avoid that. It's that Go's minimalistic approach actually...works.
>

Missing "not": "And this is not because" 

The strategy of writing as literal as possible a translation of the Python 
first, 
at the cost of generating Go code that was initially clunky  and 
unidiomatic,
worked quite well.  It actually took effort and discipline to refrain from 
trying
to improve the code as it passed through translation, but I am very glad I 
expended that effort.  It kept the translation process sane and 
controllable,

I should note that a prerequisite for a translation like this is an 
excellent test 
suite.  At 22KLOC, reposurgeon now has 52 unit tests, 177 round-trip tests, 
218 end-to-end functional tests, and a miscellany of special tests that add
up to a total of 502 reporting items.  Only around 20 of these were added
during the translation itself.  All these tests are run by continuous 
integration
on every commit.

That translation phase was completed In November 2019 when the Go code
first passed the full test suite. The two months since has been sufficient 
to
polish the literalistic mock-Python it was at that time into what is now, I 
believe,
pretty clean idiomatic Go.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/760a6b1d-d3e2-4eeb-a074-19ea568b2449%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[pboampong5]

> ===  Catchable exceptions require silly contortions ===

I think the community is aware of the problem but still trying to find a 
more Go-like solution. Take a look at some of the proposals if you haven't:
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md
https://github.com/golang/go/labels/error-handling

As you know, what we usually use now is a chain of:
x, err = f(y); if err != nil { /* handle err */ }
where *handle err* usually involves a return/goto/break, so that the 
nesting level is independent of the number of steps.

But one can also use the panic/recover mechanism locally to shorten the 
above into something like this:
x, err = f(y); check(err)
Example here: https://play.golang.org/p/Gli8_bgyuDS
(Variations are possible, including error decoration and callback handlers.)

Sometimes panic/recover across different functions (like you did) is more 
appropriate. The convention is not to use it across package boundaries.

> And all it would take to get there is two minor loosenings of 
restrictions.
> 
> 1. The panic function has a new property, "terminating". [...]

log.Fatal and os.Exit have the same problem. They are not "terminating 
statements", so if you want them at the bottom of a function with result 
parameters you have to add a panic("unreachable").
But I think it's very rare not to have one of the "success" paths at the 
end; in 8 years it happened to me like a couple of times. Do you really 
expect to have throw() at the bottom of functions?

> 2. A recover() call is no longer required to be within the lexical frame 
of a defer().

Would it be less ugly like this? (with recover in the catch func.)

| defer catch("recoverable", func(err error) {
| fmt.Println("Recover:", err)
| })

> === Absence of iterators ===

Interesting proposal. The new expression accepted by "range" would be of 
type "func() (T, bool)", called repeatedly to get the next element until 
false.
While the available solution is verbose and uses 2 more variables, I don't 
think its readability is so bad:

| for f := repo.commits();; {
| commit, ok := f()
| if !ok {
| break
| }
| do_stuff_to(commit)
| }

Of course if you need the index you have to add yet more cruft.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d5115a08-aadb-420e-912c-9145ea7ae611%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote:
>
> log.Fatal and os.Exit have the same problem. They are not "terminating 
> statements", so if you want them at the bottom of a function with result 
> parameters you have to add a panic("unreachable").
>

Excellent point.  But contemplating being able to declare library functions 
terminating - as opposed to making it a property the compiler deduces from 
knowing how panic works - opens up a bigger can of worms...

But I think it's very rare not to have one of the "success" paths at the 
> end; in 8 years it happened to me like a couple of times. Do you really 
> expect to have throw() at the bottom of functions?
>

Absolutely.  Consider a parser in which your handler function for a given 
token or subtree consists of  a bunch of if/then returns, and not matching 
one of them means you should throw upwards to an error handler.
 

> > 2. A recover() call is no longer required to be within the lexical frame 
> of a defer().
>
> Would it be less ugly like this? (with recover in the catch func.)
>
> | defer catch("recoverable", func(err error) {
> | fmt.Println("Recover:", err)
> | })
>
> Maybe I'm being dim. but I don'r understand your counter-question. Can you 
> unpack it a bit? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9aac4872-b90a-4c95-9220-04b7c8acacb8%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Manlio Perillo]

On Saturday, January 25, 2020 at 9:46:19 AM UTC+1, Eric Raymond wrote:
> [...]
 

> An early reviewer pointed out that if the Go code were an entire
> function it could be expressed something like this:
>
> ---
>
> func pipeline(source T)  {
> {
> result1, err1 := transform1(source)
> if err1 != nil {
>   return err
> }
>
> result2, err2 := transform2(result1)
> if err2 != nil {
>   return err
> }
>
> result3, err3 := transform3(result2)
> if err3 != nil {
>   return err
>
> return nil
> }
>
> ---
>
> That's still a lot of eyeball friction compared to functional-style with
> exceptions. And it gets worse faster as the number of stages rises.
>
>
What about introducing a support type. As an example (not tested)
https://play.golang.org/p/WkHyEI52xKu

> [...]

Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/82c572c8-b419-479f-b266-6ade6ab461eb%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Manlio Perillo]

On Monday, January 27, 2020 at 11:18:50 AM UTC+1, Manlio Perillo wrote:

> [...] 

>
> What about introducing a support type. As an example (not tested)
> https://play.golang.org/p/WkHyEI52xKu
>
>
Here is an updated version of the Pipeline type, with error handling:
https://play.golang.org/p/Qs6_fIDZjki
 

Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/89394121-f9fa-42e4-9e95-2a6fcce3258f%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Liam]

That was a great read, thank you.

Re throw/catch, this is one of the few Go2 error handling proposals still 
open, tho it hasn't yet seen substantive feedback from the Go team:
https://github.com/golang/go/issues/27519

I'd suggest re-posting this on golang-dev; I almost missed it as I rarely 
read -nuts.


On Saturday, January 25, 2020 at 12:46:19 AM UTC-8, Eric Raymond wrote:
>
> Most of the remainder of this post is asciidoc source, because that's easy 
> to quote.  If you want to look at a nicely rendered version, see
>
> https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc
>
> = Notes on the Go translation of Reposurgeon =
> version 1.8, 2020-01-25
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0fb5c9d3-a4a8-435b-8409-7a7516f1f2d4%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jason E. Aten]

I miss named function arguments too.

The closest replacement I've discovered in Go is pass a struct literal, or 
pointer to such, which can then document or leave out arguments as desired. 
e.g.

type temperature struct {
  fahrenheit float64
  celciusfloat64
}

func set(temperature{celcius: 38.5}) {
   ...
}

which reads rather nicely. No need to fill in all the unused arguments, as 
they get zero values.



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f1f6e3e1-dbc8-48cb-847e-fac7cb7b46db%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jason E. Aten]

I miss named function arguments too.

The closest replacement I've discovered in Go is pass a struct literal, or 
pointer to such, which can then document or leave out arguments as desired. 
e.g.

type temperature struct {
  fahrenheit float64
  celciusfloat64
}

// define
func set(t temparature) { ... }

// call
set(temperature{celcius: 38.5})

which reads rather nicely. No need to fill in all the unused arguments, as 
they get zero values.

It would be nice if there was language support for this idiom.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/323fda0c-5478-463e-beac-963c5d61dccb%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Brian Candler]

On Saturday, 25 January 2020 22:16:26 UTC, Eric Raymond wrote:
>
>
> And that's the insight that led be to the extension I proposed. I asked 
> myself what the most natural way to pass out a soft close might be.
>  
>

Suppose we continue with the idea of an iterator being a goroutine which 
stuffs values down a channel, like https://tour.golang.org/concurrency/4

It occurs to me that the idiomatic way to signal termination and cleanup is 
with a Context.  Suppose "for ... range" acted on a function which returned 
two values: a channel of arbitrary type T, and a cancel function.

It would iterate over the values on T, but when the for loop terminates 
(either normally or abnormally) would call the cancel function.  That's 
basically the pattern from https://tour.golang.org/concurrency/5

Prototype: https://play.golang.org/p/rU7sulJqxaE

When playing with this, I found of course that after cancelling the 
context, the cleanup in the goroutine happened asynchronously (it's a 
goroutine, after all).  That would be fine in many cases - but it's also 
possible to make the cleanup synchronous by wrapping the cancel function so 
that it waits for the goroutine to exit.

Version with synchronous cleanup: https://play.golang.org/p/hsYqU_jaViI

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9fae3d58-ac58-4908-929f-38a236a93227%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jon Conradt]

While names arguments like foo(x= 1.0, y = 23) may look like syntactic 
sugar, I think you are right that they improve readability, especially of 
long argument lists. The counter argument I suppose if that you could pass 
structs around, but that gets ugly fast. 

Thinking about how this would be implemented in Go, I wonder if it would be 
better for unnamed arguments (assuming they are allowed) to adopt the 
default values, or whether the function definition should include default 
values like Python. I find the default values in the function definition to 
be hard to discover, but that is mostly because I find Python docs hard to 
read.

Thank you for posting this very interesting experience report.

Jon 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a8b2896a-19e3-4b94-8a5d-811a43ec4f45%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Brian Candler]

On Monday, 3 February 2020 23:10:01 UTC, Jon Conradt wrote:
>
> While names arguments like foo(x= 1.0, y = 23) may look like syntactic 
> sugar, I think you are right that they improve readability, especially of 
> long argument lists. The counter argument I suppose if that you could pass 
> structs around, but that gets ugly fast. 
>
>
There are some open proposals which would make this less ugly: e.g.
https://github.com/golang/go/issues/12854
https://github.com/golang/go/issues/35304
 

> Thinking about how this would be implemented in Go, I wonder if it would 
> be better for unnamed arguments (assuming they are allowed) to adopt the 
> default values, or whether the function definition should include default 
> values like Python. I find the default values in the function definition to 
> be hard to discover, but that is mostly because I find Python docs hard to 
> read.
>

I think the natural approach would be to default to zero values, just like 
structs do.

In a similar vein, I observe that Protobuf v2 included the ability to 
specify default values for missing fields, but these were removed in 
Protobuf v3.  Now all fields are optional, and all default to the zero 
value.

Python-style kwargs have the advantage over passing a struct that you can 
mark some arguments as mandatory (checked at compile time).  You could of 
course pass regular arguments followed by a struct of optional arguments, 
but that's rather messy.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56557a43-d0d3-4487-a76f-cf890d25343c%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jason E. Aten]

Here's an idea for named arguments. Given:

type fArg struct {
  x float64
  y float64
  i int
}

func f(a fArg) {
 ...
}

func f2(a *fArg) {
 ...
}

## Then, consider call example 1:

 f(x:1.9, i:2)

-> this would be translated into an implicit struct creation either value 
or value plus a pointer:

 f(fArg{x:1.9, i:2})


## call example 2:

f2(x:1.9, i:2)

-> is translated implicitly into

f2(&fArg{x:1.9, i:2})

additional advantages:
a) very easy to implement in the compiler; it is so simple that could 
almost be done with a macro.
b) could be very useful in initializing structs too, using a simple helper 
function that also returned the structure:

func helper(a *fArg) *Arg {
   return a
}

so that 

  b := helper(i: 2)

would give you the whole new &fArg{x:0, y:0, i:2} back in b.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/444577f7-9c1c-41d3-b1fc-fa5f4b40cf54%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Thursday, January 30, 2020 at 2:05:17 AM UTC-5, Liam wrote:
>
> I'd suggest re-posting this on golang-dev; I almost missed it as I rarely 
> read -nuts.
>

That's a good idea.  I think what I'll do is revise it lightly in view of 
some of the feedback I've gotten here and post it there.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/152ab11e-2a6d-4ec7-83a4-4feccf66eca7%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

This is a belated addition to my notes on the Go translation of 
reposurgeon. I'll be adding it to the revised version I post to golang-dev.

One extremely positive thing I must say before closing.  Translation from 
Python, which is a dreadful language to try to do concurrency in due to its 
global interpreter lock, really brought home to me how unobtrusively 
brilliant the Go implementation of Communicating Sequential Processes is.  
The primitives are right and the integration with the rest of the language 
is wonderfully seamless.  The Go port of reposurgeon got some very large 
speedups at an incremental-complexity cost that I found to be astonishingly 
low.  I am impressed both by the power of the CSP part of the design and 
the extreme simplicity and non-fussiness of the interface it presents.  I 
hope it will become a model for how concurrency is managed in future 
languages.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/abc51fb9-0f98-47e6-91a3-d8950953bfdd%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Doug Clark]

Thanks for the follow up Eric. Your experience with the concurrency 
primitives lines up with my experience porting projects from various 
languages into Go. The ability to maintain exceptionally low cognitive 
overhead when adding concurrency is pretty amazing.

On an unrelated note, if in the future you find yourself converting more 
projects and need the advanced regexp features you can use this regexp 
implementation: https://github.com/dlclark/regexp2
It's closer to what you're used to with Python (or C#, or Javascript, etc), 
but those advanced features do have a cost that shouldn't be entered into 
lightly.

- Doug


On Friday, February 21, 2020 at 11:08:53 AM UTC-6, Eric Raymond wrote:
>
> This is a belated addition to my notes on the Go translation of 
> reposurgeon. I'll be adding it to the revised version I post to golang-dev.
>
> One extremely positive thing I must say before closing.  Translation from 
> Python, which is a dreadful language to try to do concurrency in due to its 
> global interpreter lock, really brought home to me how unobtrusively 
> brilliant the Go implementation of Communicating Sequential Processes is.  
> The primitives are right and the integration with the rest of the language 
> is wonderfully seamless.  The Go port of reposurgeon got some very large 
> speedups at an incremental-complexity cost that I found to be astonishingly 
> low.  I am impressed both by the power of the CSP part of the design and 
> the extreme simplicity and non-fussiness of the interface it presents.  I 
> hope it will become a model for how concurrency is managed in future 
> languages.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0113e65f-c809-476b-a9b4-c0ab4830134f%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Robert Engels]

Very in-depth and interesting. 

Although I agree with most of the points, I think a better use of interfaces 
would address some of your concerns, and have more maintainable code. 

Whenever I see a type switch it screams to me “use an interface and 
restructure. “

>> On Jan 25, 2020, at 4:43 AM, Brian Candler  wrote:
> 
> Very insightful.
> 
> I am relatively new to go, but I would like to make a few observations.
> 
> 1. When the issue of keyword arguments has come up before, usually someone 
> suggests passing a struct as the function argument.  Did you try this?  It 
> might be worth mentioning in your analysis, if only to give an example of why 
> it wasn't a good match.
> 
> 2. I notice some potential overlap between a couple of features you mention.  
> The first is map(f,x) for mapping a slice of arbitrary type (incidentally it 
> couldn't be called "map" for obvious reasons)  The second is using generator 
> functions as ranges.
> 
> It occurs to me that if you could initialize a slice from a generator 
> function, you'd have another way to achieve your map. The generator function 
> could also do filtering, making it more like a comprehension.
> 
> 3. A generator function would have to maintain its own thread of execution 
> independent from the recipient - much like a goroutine.  So this might end up 
> looking very similar to a function which stuffs values down a channel, which 
> is option 3 in the linked article.
> 
> The problem with garbage collection needs to be dealt with, which at the 
> simplest could be that the receiver closes the channel when done. Today this 
> would cause the sender to panic, so that would need to be dealt with - 
> perhaps some sort of "soft close".
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fdd4882f-0c17-42f2-b301-ab65e5ce08a7%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C1720736-D9CC-4D98-9D54-5EF69CF1B9CD%40ix.netcom.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Saturday, January 25, 2020 at 10:04:19 AM UTC-5, Robert Engels wrote:
>
> Whenever I see a type switch it screams to me “use an interface and 
> restructure. “
>

You may be right.  On the other hand, I think I've already gone far enough 
down the  interface road to have collected most of the gains from that 
tactic.

Interfaces are fine when you have a bunch of disparate types with similar 
external interfaces and are at a stage of processing where you can 
disregard the differences.  You end up in type-switch land when the point 
is that they have *dissimilar* external interfaces but you have to cope 
anyway.

Not ideal, but sometimes necessary.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/88b8c01c-b70e-41dc-a1e7-fb412b831f50%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Robert Engels]

I think trying to write Python in Go is problematic. You say you intentional 
did and didn’t worry about “improving” the code. Using interfaces and Go design 
patterns is not improving - it’s writing proper Go imo. 

> On Jan 26, 2020, at 6:14 PM, pboampo...@gmail.com wrote:
> 
> 
> > ===  Catchable exceptions require silly contortions ===
> 
> I think the community is aware of the problem but still trying to find a more 
> Go-like solution. Take a look at some of the proposals if you haven't:
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md
> https://github.com/golang/go/labels/error-handling
> 
> As you know, what we usually use now is a chain of:
> x, err = f(y); if err != nil { /* handle err */ }
> where *handle err* usually involves a return/goto/break, so that the nesting 
> level is independent of the number of steps.
> 
> But one can also use the panic/recover mechanism locally to shorten the above 
> into something like this:
> x, err = f(y); check(err)
> Example here: https://play.golang.org/p/Gli8_bgyuDS
> (Variations are possible, including error decoration and callback handlers.)
> 
> Sometimes panic/recover across different functions (like you did) is more 
> appropriate. The convention is not to use it across package boundaries.
> 
> > And all it would take to get there is two minor loosenings of restrictions.
> > 
> > 1. The panic function has a new property, "terminating". [...]
> 
> log.Fatal and os.Exit have the same problem. They are not "terminating 
> statements", so if you want them at the bottom of a function with result 
> parameters you have to add a panic("unreachable").
> But I think it's very rare not to have one of the "success" paths at the end; 
> in 8 years it happened to me like a couple of times. Do you really expect to 
> have throw() at the bottom of functions?
> 
> > 2. A recover() call is no longer required to be within the lexical frame of 
> > a defer().
> 
> Would it be less ugly like this? (with recover in the catch func.)
> 
> | defer catch("recoverable", func(err error) {
> | fmt.Println("Recover:", err)
> | })
> 
> > === Absence of iterators ===
> 
> Interesting proposal. The new expression accepted by "range" would be of type 
> "func() (T, bool)", called repeatedly to get the next element until false.
> While the available solution is verbose and uses 2 more variables, I don't 
> think its readability is so bad:
> 
> | for f := repo.commits();; {
> | commit, ok := f()
> | if !ok {
> | break
> | }
> | do_stuff_to(commit)
> | }
> 
> Of course if you need the index you have to add yet more cruft.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d5115a08-aadb-420e-912c-9145ea7ae611%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/E0B2E0BE-00CC-4447-A81E-DB2A9DE91911%40ix.netcom.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Sunday, January 26, 2020 at 9:06:47 PM UTC-5, Robert Engels wrote:
>
> I think trying to write Python in Go is problematic. 
>

Of course it is. If I were starting a Go program from scratch I certainly 
wouldn't try to code as though the language were Python.

The real burden of my experience report is that *after I got past* the 
initial and somewhat herky-jerky translation, some of the expressiveness 
problems I tripped over *continued* to be expressiveness problems in 
idiomatic Go.

Perhaps this would be more obvious if you had seen some of the gripes I had 
in early drafts that I removed because I realized they were artifacts of 
Pythonic thinking. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d810807f-a1ab-4fb6-a303-439ec456c7b5%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Philip Boampong]

> > log.Fatal and os.Exit have the same problem. They are not "terminating 
> > statements", so if you want them at the bottom of a function with result 
> > parameters you have to add a panic("unreachable").
>
> Excellent point.  But contemplating being able to declare library functions 
> terminating - as opposed to making it a property the compiler deduces from 
> knowing how panic works - opens up a bigger can of worms...

Of course. And with your proposal it would be easy to make os.Exit
"terminating" by adding a panic at the bottom (the only exit path,
theoretical), which would make log.Fatal "terminating" in turn (the
property would have to be guaranteed though).

Anyway, I probably got the frequency I write panic("unreachable") and
the frequency I have failure at the bottom of a function mixed up. The
second is not so uncommon after all, I'm just not used to the throw
paradigm.

> Maybe I'm being dim. but I don'r understand your counter-question. Can you 
> unpack it a bit?

You called this ugly:
| defer func() {
| fmt.Println("Recover:", catch("recoverable", recover()))
| }()

And this reasonable / less ugly:
| defer func() {
| fmt.Println("Recover:", catch("recoverable"))
| }()

I assumed the ugliness is about the recover logic being exposed in the
catch signature and in the handler function. If you change catch to
take the exception handler as a callback you can hide the recover
logic without language changes. But maybe there's something you want
to do that I can't see from the example.

| defer catch("recoverable", func(err error) {
| fmt.Println("Recover:", err)
| })


On Mon, Jan 27, 2020 at 5:23 AM Eric Raymond  wrote:
>
>
>
> On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote:
>>
>> log.Fatal and os.Exit have the same problem. They are not "terminating 
>> statements", so if you want them at the bottom of a function with result 
>> parameters you have to add a panic("unreachable").
>
>
> Excellent point.  But contemplating being able to declare library functions 
> terminating - as opposed to making it a property the compiler deduces from 
> knowing how panic works - opens up a bigger can of worms...
>
>> But I think it's very rare not to have one of the "success" paths at the 
>> end; in 8 years it happened to me like a couple of times. Do you really 
>> expect to have throw() at the bottom of functions?
>
>
> Absolutely.  Consider a parser in which your handler function for a given 
> token or subtree consists of  a bunch of if/then returns, and not matching 
> one of them means you should throw upwards to an error handler.
>
>>
>> > 2. A recover() call is no longer required to be within the lexical frame 
>> > of a defer().
>>
>> Would it be less ugly like this? (with recover in the catch func.)
>>
>> | defer catch("recoverable", func(err error) {
>> | fmt.Println("Recover:", err)
>> | })
>>
>> Maybe I'm being dim. but I don'r understand your counter-question. Can you 
>> unpack it a bit?
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/u-L7PRa2Z-w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9aac4872-b90a-4c95-9220-04b7c8acacb8%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEvMKD9O7uwh_xDbmBFt2Hk2YujmV%2BcL59Sm5qGWvDzJoMxB-g%40mail.gmail.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Monday, January 27, 2020 at 9:51:43 AM UTC-5, Philip Boampong wrote:
>
> I assumed the ugliness is about the recover logic being exposed in the 
> catch signature and in the handler function. If you change catch to 
> take the exception handler as a callback you can hide the recover 
> logic without language changes. But maybe there's something you want 
> to do that I can't see from the example.
>

You're right. I will experiment.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d365f80b-c41e-4d44-947c-e4b9b9a3e546%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Nigel Tao]

On Mon, Jan 27, 2020 at 3:23 PM Eric Raymond  wrote:
> Consider a parser in which your handler function for a given token or subtree 
> consists of  a bunch of if/then returns, and not matching one of them means 
> you should throw upwards to an error handler.

FWIW, 
https://github.com/google/wuffs/blob/db87fa6bd18de9de563f3bb352eaabee3616916a/lang/parse/parse.go#L290
is such a parser, written in Go, that just returns an error instead of
trying to twist panic/recover into throw/catch.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNWJL%3DNpNcCX%3DxcDU8Fcjx8TUs8ukUhxE0mkyJpTaEtanw%40mail.gmail.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Nigel Tao]

On Tue, Feb 4, 2020 at 8:56 PM Jason E. Aten  wrote:
>   b := helper(i: 2)
>
> would give you the whole new &fArg{x:0, y:0, i:2} back in b.

I'm not sure how helpful that really is, given that you can already write:

b := &fArg{i: 2}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNVp29ccJwAPcQYH98NUQ3skE3XYfPdVgAVOB5L73NR9pw%40mail.gmail.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Nigel Tao]

On Sun, Jan 26, 2020 at 9:16 AM Eric Raymond  wrote:
> And that's the insight that led be to the extension I proposed. I asked 
> myself what the most natural way to pass out a soft close might be.

If you're proposing combining generators and exceptions, be aware of
how complicated the exact semantics can be. Look for what follows `The
statement "RESULT = yield from EXPR" is semantically equivalent to
...` in https://www.python.org/dev/peps/pep-0380/

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNXvMpaRJpUQZo3VeQm%2BP0fdgHzrHX-Ov5ik6OH%2BMy_ksA%40mail.gmail.com.