Re: [speagram] generacja kodu - problemy

[rzyjontko <rz...@op...>]

Lukasz Kaiser wrote:
>
> To nie jest takie proste. Jak to jest w jezyku to nie musisz tego pisac=
,
> robic dllki itp.=20

Zastanawia=B3em si=EA nad zmian=B1 nazwy makra i widz=EA, =BFe jest absol=
utnie
konieczna bo sugeruje, =BFe makro robi co=B6 innego.  Niestety ono nie
w=B3=B1cza pliku =BCr=F3d=B3owego nemerle, bo musia=B3oby umie=E6 go spar=
sowa=E6 -
makra zwracaj=B1 drzewa rozbioru.  To makro zwraca zawarto=B6=E6 pliku ja=
ko
string.  Przemianuj=EA je na IncludeAsString.

> Ok, mysle, ze to jest dobrze. Kod do wczytywania z dllek jest np.
> w speagram.n jesli nie chce ci sie pisac od nowa.

Poradzi=B3em ju=BF sobie.

> To mi sie natomiast wcale ni podoba. To powinno byc proste, powinno
> wystarczyc podac dla kazdego konstruktora funkcje, ktora go rozklada
> i wtedy powinny juz wszystkie patterny dzialac, tzn. np. dla integers
> musisz tylko rozlozyc pos i neg, dla naturals musisz rozlozyc na
> / 10 i % 10 (czy jakos tak) a dla floatow musisz podac czesc przed,
> po przecinku i expa. Chyba to bedzie prawie wszystko, czemu to jest
> problem ? Interface ITypeHandler tego nie robi ? Bo sam interface to
> nie wszystko, matching i tak musi byc generowany rekurencyjnie w pewien
> sposob, nie mozna zwalic calej tej rekurencji na interface.

Je=B6li chodzi o liczby ca=B3kowite, to faktycznie da si=EA to zrobi=E6. =
 Ale
to tylko z tego wzgl=EAdu, =BFe konstruktor do=B3=B1cza kolejn=B1 cyfr=EA=
 na
koniec liczby, a nie na pocz=B1tek.  Co prawda odzyskanie warto=B6ci
zmiennej z liczby nie b=EAdzie proste, ale wykonalne.

Natomiast z floatami jest gorzej, bo np. liczba 723 ma kilka
reprezentacji, wi=EAc je=B6li dopasuj=EA wzorzec cons_float (X, Y, Z) to
mo=BFe by=E6:
  X =3D 7
  Y =3D 23
  Z =3D 2
albo
  X =3D 72
  Y =3D 3
  Z =3D 1

=AFeby to zmieni=E6 trzebaby X zrobi=E6 digit zamiast integer.

--=20
rzyjontko
http://www.student.ii.uni.wroc.pl/~rzyj/