[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