[nem-pl] skladnia
Michal Moskal
malekith at pld-linux.org
Wed Oct 29 14:07:02 CET 2003
On Wed, Oct 29, 2003 at 11:51:15AM +0100, Lukasz Kaiser wrote:
> Hej.
>
> Tak patrze i patrze na ten list.n i bardzo mi sie nie podobaja rozne
> rzeczy. Ale moze sprobuje byc bardziej konstruktywny, wiec mam jakies
> propozycje:
>
> 1) dodac = przed { e defach, tzn. nie
> def i (dummy : int, e : 'a) : int { f (e); dummy };
> tylko
> def i (dummy : int, e : 'a) : int = { f (e); dummy };
Można pisać z =.
> 2) zrobic dodatkowy kontener na czyste funkcje nazywajacy sie jakos,
> np. funclass, i niech bedzie mozna zrobic
> funclass List {
> def 'a append (x : list ('a), y : list ('a)) : list ('a) = ...
> }
module M {
'a append (x : list ('a) ....) = ...
}
Myślę, że to da radę.
> 3) wywalic zmienne typowe przed definicjami funkcji polimorficznych,
> czyli
> def append (x : list ('a), y : list ('a)) : list ('a) = ...
> bo koniecznosc wielokrotnego ich pisania zniecheca do polimorfizmu a
> odtworzenie ich jak sie ma typy wpisane to banal
Zmienne typowe mogą przywędrować z wyższych poziomów (mogą być
zadeklarowane w typie). Oczwiście trywialne jest założenie, że pierwsze
użycie definiuje zmienną, ale może to prowadzić do błędów. Podobnie
wymagamy definiowania zwykłych zmiennych.
Mam nadzieję zmusić w końcu kompilator do inferencji typów, przynajmniej
w tych przypadkach, gdy poradziłby sobie z tym kompilator ML'a.
--
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h
More information about the devel-pl
mailing list