Odp: [nem-pl] My i Haskell

Kamil nazgul at omega.pl
Tue Dec 23 19:40:47 CET 2003


To moze ja sobie odpowiem:

> - druga sprawa jest delikatniejsza:
> <[ f (x) { x } ]>
> u nich za x i f jest podstawiana unikalna nazwa

Oni to robia duzo mniej elegancko niz myslalem - znaczenie <[ x ]> zalezy od
kilku czynnikow:
- jesli zmienna jest zwiazana wewnatrz quotowania, to jest wlasnie
traktowana jako lokalna dla quotowania i automatycznie nadawana jest
unikalna nazwa
- jesli zmienna jest zwiazana gdzies w otwartym module, to nazwa jest
zostawiana, przy czym pelna nazwa modulu jest do niej dodawana
czyli <[ E_ref (..) ]> przeksztalcana w <[ Nemerle.Compiler.Parsetree.E_ref
(..) ]>
- gdy jest zwiazana wewnatrz funkcji ktora definiujemy, to jest w wyrazenie
wstawiana zliftowana wartosc
def x = 1; <[ x ]> tlumaczą na def x = 1; <[ $(x : int) ]>

Chyba nie musze tlumaczyc ze nie jest to ladne roziązanie, choć trzeba
przyznać, że w praktyce może być wygodne :)

I jeszcze jedna rzecz sie okazala, kiedy dotarlem do konca pracy:
Oni zeby uruchomic makro musza pisac $, np.
$(printf "%d %s") i str
ciągle wydawalo mi sie to dziwne, a oni dzieki temu mogą traktować makra,
jako first class citizens - to sa zwykle funkcje, o ktorych momencie
uruchomienia decyduje programista.
Jakos niby to fajne, a jednak mi sie nie podoba - my mozemy zrobic to samo w
postaci jakby eta-dlugiej i przynajmniej jest to bardziej czytelne (choc w
sumie nie wiem, moze jednak przekazując makro jako fukcje mozna cos wiecej)

Pytanie co myslicie o pierwszym punkcie, bo drugiego raczej nie bedziemy
wdrażać - mamy ładniej wyglądające i bardziej zrozumiałe sposoby.

Kamil

> tzn. ze jak ktos przekaze tam czegos uzywajacego x lub f, to nie bedzie
> konfliktow
> u nas w tym celu robimy np. <[ def _N_whileloop ()... ]>
> i to byla swiadoma decyzja zeby dalo sie latwo pisac
> <[ Nemerle.Complier.Parsetree.E_ref .....]>
> i zeby to E_ref w srodku to bylo E_ref, a nie jakas podmieniona zmienna
>
> gdyby wprowadzic podmienianie, to trzebaby pisac jakos
> <[ $("Nemerle" : var).$(... ]>
> ale chyba jednak korzysci z tego sa wieksze
> bo czesciej ludzie uzywaja makr w takim kontekscie, ze nie uzywaja
> konkretnych nazw tylko chca miec automatycznie nowe
> przynajmniej tak pisza w H., ze to jest dobre i ze u nich jest slabo, bo
nie
> we wszystkich konstrukcjach udaje im sie to wprowadzic
>
> u nas tez sie da zrobic przemianowanie
> def x = newsymbol; <[ (x: var) ]>
> ale zawsze jedno ze znaczen bedzie trudniejsze (dluzsze) do napisania
> i pytanie ktore powinno byc krotsze, a ktore dluzsze
>
> Pawel proponuje, zeby
> napisać %x i wiadomo, że to jest def x = newsymbol <[ (x : var) ]>
> czyli kolejny krzak, ktory by to zalatwial
> i oczywiscie umozliwic oba sposoby, ale to jeszcze nie rozwiazuje
> wszystkiego
> bo % bylby wazny tylko w obrebie jednego quotowania:
> jak napisze <[ %x ]> :: <[ %x ]> :: []
> to to juz bedzie inny x
>
> na pocieszenie mamy, ze jak by bylo <[ x...]> jako nowa zmienna, to oni
tez
> maja problem z <[ x]> :: <[ x]> :: []
> wiec luz, co bysmy nie zrobli, i tak bedziemy lepsi od H.
>
> pytanie (Łukasz) - czy da sie to zrobic ladniej
>
> A ogólenie to wiadomosci z frontu powalania Haskella na lopatki sa jak
> najlepsze.
>
> Wesołych Świąt
> Kamil
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-pl
>





More information about the devel-pl mailing list