[nem-pl] in_tail_position

[Kamil Skalski]

Friday 12 of March 2004 14:28, Lukasz Kaiser wrote:
> Atrybut do konstruktorow w zasadzie nie jest konieczny, wystarczy
> ze beda go mialy automatycznie generowane konstruktory dla variantow
> i rekordow, tych jest i tak dosc duzo.

Tak, to zdecydowanie (na razie) lepszy pomysł. Lepiej nie atakować użytkownika 
tego typu atrybutami, zanim nie będziemy pewni, że to w jakimś dość ogólnym 
schemacie działa. A w wewnętrznych obliczeniach kompilatora możemy szaleć do 
woli.

>
> Wtedy mozna sie pokusic o taka optymalizacje, ze jesli sideefectless
> konstruktor jest in tail position, to zostaje przesuniety wczesniej
> a rzeczy wywolywane w jego srodku sa podstawiane w odpowiednie miejsca.
> To znaczy Cons ( f(x), g(y) ) zamienia sie na def y = Cons ( null, null ),
> y.a <- f(x); y.b <- g(y);. Oczywiscie to sie dzieje przy generacji kodu,
> to znaczy tak, zeby elementy konstruktora mogly byc immutable w systemie
> typow, ale mimo to zeby miec do nich dostep jak do wskazniow (malo
> eleganckie, wiem, ale moze wydajne).

Tak, to mi się zaczyna nawet podobać. Widzę w tej chwili takie problemy:
- nie mamy refów, które są niezbędne do tego (to znaczy to co napisałeś musi 
wyglądać tak - def z = Cons (null, null); g (y, ref z.a, ref z.b)
- powinno rzeczywiście być robione na razie dla podzbioru języka, o którym 
wiemy, że jest bezpieczny

> Pierwsza optymalizacja powinna spowodowac, ze to bedzie ogonowe,
> czyli zamiast wywolania { v <- append ( zs, y ); Cons ( z, v ) ; }
> bedzie { v <- Cons ( null, null ) ; v.hd <- z ; v.tl <- append ( zs, y );
> }. Tutaj jeszcze bedzie problem, zeby nie pomieszac kolejnosci.

append (zs, y, ref v.tl)

> Myslicie, ze to jest rabialne czy zupelnie bez sensu ?

Próbować chyba warto. Choć sądząć po tym ile rzeczy do zrobienia się pojawiło 
od kiedy wszyscy zaczęli sobie odpoczywać od grzebania w kompilatorze, to 
trochę pewnie potrwa zanim ktoś się zajmie tym.

Kamil