4 ms·

> (Also, don't Rust and Go have closures? Surely that would satisfy this requirement.) Indeed they do. It's completely unclear why they don't satisfy the OP's

> (Also, don't Rust and Go have closures? Surely that would satisfy this requirement.) Indeed they do. It's completely unclear why they don't satisfy the OP's requirement.

_veelo 8y ago
To be frank: I have never used Rust nor Go. Nevertheless, I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. The same argument is being discussed at reddit https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ https://www.reddit.com/r/programming/comments/8si75b/how_an_...
- jerf 8y ago
  Speaking at least for Go, the "different syntax" between closures and functions is that for closures, you don't give a function name. The only way they could be any more similar is if closures did take a function name, which is generally a bad idea because there's no single behavior I've seen that captures what programmers expect to happen in that case. (In general, for the code x = func blah() { ... } there is a conflict between "x is the only new binding we should have as a result of executing that line" and "the function name 'blah' should do some sort of binding".) If that's enough to throw your translation process, you've got bigger problems.... (Cards on the table, D is probably a good choice and I'm not advocating for Go here.)
- kibwen 8y ago
  > I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. It's unclear where the root of that confidence lies. The translation is just as mechanical in either language as it would be otherwise: see an inner function, replace it with the one thing that can capture variables. Speaking for Rust, it would actually be even easier to do the translation using closures, because Rust closures can have their signatures inferred whereas Rust functions cannot.
  - comex 8y ago
    I can see at least two issues. I'm sure you're aware of these, but: - Rust closures don't really support recursion, at least without serious hacks. - Rust closures borrow the variables they reference as soon as the closure is created; you can never write to those variables again as long as the closure is alive, and if the closure mutates the variable (resulting in a mutable borrow), you can't read from them either, outside the closure itself. The latter isn't as a big a deal for some other use cases for closures, but if you want to use them to emulate nested functions, you're probably creating the closure at the beginning of the outer function and keeping it in scope for the whole function; this means that what you can do with mutable variables is severely limited. Both issues could be worked around if the mechanical translator liberally sprinkled the code with Cell/RefCell – which would also be necessary to deal with pointers in the source language. But the result would be highly unidiomatic and verbose Rust code. (In any case, I'm not sure I'd have recommended Rust to OP as they claim to put a high priority on fast compile times, but that's a separate issue.)
robocat 8y ago
From: https://www.reddit.com/r/programming/comments/8si75b/comment/e0zw6su https://www.reddit.com/r/programming/comments/8si75b/comment... "In Rust, only lambdas (unnamed functions) can be closures". The OP's post seems to show they didn't spend much time understanding whether Go closures could serve their need. Although from my own superficial understanding, D is "closer" to Pascal than Go.

> (Also, don't Rust and Go have closures? Surely that would satisfy this requirement.) Indeed they do. It's completely unclear why they don't satisfy the OP's requirement.

_veelo 8y ago

To be frank: I have never used Rust nor Go. Nevertheless, I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. The same argument is being discussed at reddit https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ https://www.reddit.com/r/programming/comments/8si75b/how_an_...

jerf 8y ago
Speaking at least for Go, the "different syntax" between closures and functions is that for closures, you don't give a function name. The only way they could be any more similar is if closures did take a function name, which is generally a bad idea because there's no single behavior I've seen that captures what programmers expect to happen in that case. (In general, for the code x = func blah() { ... } there is a conflict between "x is the only new binding we should have as a result of executing that line" and "the function name 'blah' should do some sort of binding".) If that's enough to throw your translation process, you've got bigger problems.... (Cards on the table, D is probably a good choice and I'm not advocating for Go here.)
kibwen 8y ago
> I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. It's unclear where the root of that confidence lies. The translation is just as mechanical in either language as it would be otherwise: see an inner function, replace it with the one thing that can capture variables. Speaking for Rust, it would actually be even easier to do the translation using closures, because Rust closures can have their signatures inferred whereas Rust functions cannot.
- comex 8y ago
  I can see at least two issues. I'm sure you're aware of these, but: - Rust closures don't really support recursion, at least without serious hacks. - Rust closures borrow the variables they reference as soon as the closure is created; you can never write to those variables again as long as the closure is alive, and if the closure mutates the variable (resulting in a mutable borrow), you can't read from them either, outside the closure itself. The latter isn't as a big a deal for some other use cases for closures, but if you want to use them to emulate nested functions, you're probably creating the closure at the beginning of the outer function and keeping it in scope for the whole function; this means that what you can do with mutable variables is severely limited. Both issues could be worked around if the mechanical translator liberally sprinkled the code with Cell/RefCell – which would also be necessary to deal with pointers in the source language. But the result would be highly unidiomatic and verbose Rust code. (In any case, I'm not sure I'd have recommended Rust to OP as they claim to put a high priority on fast compile times, but that's a separate issue.)

robocat 8y ago

From: https://www.reddit.com/r/programming/comments/8si75b/comment/e0zw6su https://www.reddit.com/r/programming/comments/8si75b/comment... "In Rust, only lambdas (unnamed functions) can be closures". The OP's post seems to show they didn't spend much time understanding whether Go closures could serve their need. Although from my own superficial understanding, D is "closer" to Pascal than Go.