This is beyond most translation systems. Interestingly, the exceptions are themselves old in origin.
The LISP compiler, emerging after interpretation was the universal environment for LISP, was able to “execute” the program being compiled to discover what could be evaluated to a static conclusion, or a simpler case of the general one. >From about the same time, the early symbolic algebra systems had this same notion in their runtimes of iteritavely evaluating expressions until a fixed point In code terms was reached. REDUCE and MACSYMA are in my thoughts here. Mathematica has a sense of this too in some of its programming modes, an organic rule-driven rewrite system. (It is brilliant at the task) Not something seen in general languages very much. Some flavor of it in C metaprogramming. On Wed, Jun 10, 2020 at 11:28 AM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > when you have functions that return multiple values, because its more > efficient to generate in one go when you are using ALL returned values; > > like in math, where you have Sin(), Cos() and Sincos() > > and when you also don't use all the returned values (using '_') does the > compiler optimise? does it compile multiple times so dead code is removed > from the version used with some return values unneeded? > > i would guess it doesn't, but i wanted to check, because i seem to keep > coming over this, probably the way i think, seems to me to reduce the > solution space. > > also this seems to, in some ways, overlap with generics, particularly if > there were new language features that let you specify some high > level/simple code path changes, things specific to the problem that the > compiler could never determine. > > i guess with code generation its possible, but that doesn't feel like the > best way to go. > > i could have tested for this but am also interested in all > architectures/future developments/other ways to achieve this. > > thanks. > > > -- > 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/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/3369daf2-2cbd-4390-875b-e62eb4fab73ao%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.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/CALoEmQxHLbLcbs84rUc-09gR8j4nm-jQH7yqU9BrHSnC_iM4%3Dg%40mail.gmail.com.
