surely simply recompiling a chunk of code with particular result(s) unused, allows dead code removal from that version?
On Wednesday, 10 June 2020 21:43:14 UTC+1, Michael Jones wrote: > > 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 < > golan...@googlegroups.com <javascript:>> 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 golan...@googlegroups.com <javascript:>. >> 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. jonesmichae...@gmail.com <javascript:>* > -- 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/43333296-d199-4386-b4fb-c6eb41654309o%40googlegroups.com.
