[nem-pl] in_tail_position

[Lukasz Kaiser]

Hej.

> Nie zrozumialem na jakiej podstawie chcialbys rozpoznac jakich akumulatorow 
> trzeba uzyc, przeciez matching moze byc skomplikowany i obudowany w rozne nic 
> nie znaczace smieci". No ale nic, pewnie dla jednego przypadku, ktory sie 
> zaimplementuje to bedzie dzialac. 

Napisalem dokladnie dla jakiej klasy przypadkow wiem jak policzyc dobre 
akumulatory. Mozna sie zastanowic jak ta klase rozszerzyc, pewnie ze nigdy
to nie bedzie pelna klasa wszystkiego, ale zawsze cos.

> accumulable (match (..) { .... })
> accumulable (def f (...) { .... })

OK, rozumiem, poprobuje.

> > f = | 0 => Cons ( B, B ) | x => Cons ( f (x-1), B )
> > to pewnie ta druga galaz sie przeklada na
> > x => { y <- f(x-1) ; z <- Cons (x, 1) ; Cons ( y, z ) }.
> 
> co to za Cons(x, 1)? nie ma tego w oryginalnym kodzie....

Mialo byc B, pomylilem.

> miales na mysli
> mutable nptr <- null;
> ptr <- ConsM ( ref nptr, BM);
> f_prt (ref nptr, x-1)
> ?

Pewnie tak.

> Pamietaj, ze u ciebie nptr jest przekazany jako wartosc. (refow jeszcze nie 
> mamy)

Hmm, brak refow moze byc pewnym problemem, ale jakies wskazniki sa wiec pewnie
da sie to zrobic.

> ptr <- ConsM (null, BM);
> f_ptr (ref ptr.a, x -1)

Pewnie wlasnie tak.

> i teraz moze mialoby jakis sens, ale jest to raczej dosc nieeleganckie 
> hakowanie przekazywaniem przez referencje.

Dla mnie to jest wlasnie bardzo eleganckie. Caly problem polega w koncu 
na tym, ze bez uzycia referencji to sie nie stanie ogonowe a my chcemy 
dac programiscie mozliwosc uzycia makra tak, zeby makro robilo cale to 
nieeleganckie hackowanie pod dywanem a on dostawal elegancka ogonowa funkcje.

> Natomiast roznego rodzaju optymalizacje dotyczace podobnej tematyki 
> omawialismy w kontekscie rekordów:
> https://nemerle.org/mailman/pipermail/devel-en/2004-February/000003.html

To jest raczej co innego IMHO, chociaz tez przydatne, ale nie zwiazane
z wywolaniami ogonowymi.

> Z tego co zrozumialem, twoja propozycja opiera sie na dosc imperatywnym 
> podejsciu z przekazywaniem wskaznikow, ktore ktos moze zmodyfikowac. Jaki 
> jest zatem sens robienia powyzszej funkcji i optymalizowania jej w ten 
> sposob, skoro mozna napisac
> match (x) {
> | Leaf => x <- Tree (n, Leaf, Leaf)
> | Tree (i, l, r) => if (i < n) f (n, ref l) else f (n, ref r)

Sens jest wlasnie taki, ze dzieki napisaniu makra tych wskaznikow nikt nie
moze zmodyfikowac, sa one ukryte gdzies tam pod kolorem higienicznego makra
i nikt poza tworca makra nie musi o nich wiedziec, natomiast dostaje
dzieki uzyciu makra funkcje ogonowa.

- lk