🚀 go-pugleaf

Dnia 14 May 2007 10:29:38 -0700
pawellt@gazeta.pl napisał(a):

> Witam,
> 
> No wlasnie :) Szukam bardzo czytelnego, eleganckiego jezyka
> funkcyjnego z
> elementami obiektowosci i czesciowo mechanizmami jezykow imperatywnych
> (nie tylko rekurencja). Zalzy mi zeby byl wybitnie czytelny - bo to ma
> byc jezyk
> do nauki dla gimnazjalisty.
> Wrecz idealnym kandydatem jest Dylan (bardzo intuicyjna i prosciutka
> skladnia,
> szczegolnie elementy obiektowe - jak definicje klas, dziedziczenie
> itp) - ale jezyk
> ten praktycznie umarl. Prawie zadna ilosc bibliotek, dostepnych IDE na
> Linuksa itp.
> - a zalezy mi jednak zeby byl to jezyk w ktorym mozna poprogramowac
> "na powaznie"
> (wiadomo ze jezyk ktorego sie nauczylo na samym poczatku pamieta sie
> najdluzej)
> 
> Moglibyscie cos doradzic ?
> 
> 
> pozdrawiam
> 
Francuzi do uczenia używają Caml Light. Nie ma to obiektów. Ale tutaj
z pomocą wchodzi OCaml.

Generalnie jest czytelny. Jak na język funkcyjny. Ma mechanizmy
imperatywne, obiektowe też. BYŁ używany do tego celu. No na co czekać?

IDE są. Emacs ma ładne i eclipse ma wtyczki (kolega się zdeklarował
wrzucić tutaj link zaniedługo. ;d)

Jakieś przykłady to mogę co najwyżej polecić: bla.thera.be/ocaml
Jestem w trakcie przenoszenia tego tekstu na wikibooks.

Pozdrawiam,

-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl 
pgp: 0x90746E79 @ pgp.mit.edu

pawellt@gazeta.pl napisał(a):

> No wlasnie :) Szukam bardzo czytelnego, eleganckiego jezyka
> funkcyjnego z
> elementami obiektowosci i czesciowo mechanizmami jezykow imperatywnych
> (nie tylko rekurencja). Zalzy mi zeby byl wybitnie czytelny - bo to ma
> byc jezyk
> do nauki dla gimnazjalisty.

O... jakbym czytał opis Common Lispu :-) Ale do nauki polecałbym raczej 
Scheme (inny dialekt Lispu, w ostatnich latach dość popularny, właśnie 
wychodzi R6RS).

Istnieje dobre środowisko dla tego języka:

http://www.plt-scheme.org

Dużo darmowych materiałów do nauki. W tym całkiem niezłe wykłady z MIT:

http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures

> Wrecz idealnym kandydatem jest Dylan (bardzo intuicyjna i prosciutka
> skladnia,
> szczegolnie elementy obiektowe - jak definicje klas, dziedziczenie
> itp)

Chyba sobie żartujesz...


mp

> O... jakbym czytał opis Common Lispu :-) Ale do nauki polecałbym raczej
> Scheme (inny dialekt Lispu, w ostatnich latach dość popularny, właśnie
> wychodzi R6RS).

Ale te wszystkie nawiasy. Sa prawie tak samo wkurzajace jak wcięcia w
Pythonie :)
No i te operacje na listach, gdzie jednak troche moga zaciemniac te
nieco "malo przejrzyste":

	( car ( cdr ( cdr ( blabla ) ) ) )

Poza tym sama kwestia obiektowosci. W Scheme masz cos w stylu:

(define samochod-class
  (make-standard-class
   'superclass #t
   'slots '(frame parts size)
   'method-names '()))

> Chyba sobie żartujesz...

Dlaczego? Chociażby kwestia definicji klas w Dylanie:


define class <kolor-okna> (<okno>)
end class;


... i już masz definicje klasy "kolor-okna" dziedziczącą po klasie
"okno".
Chcesz to samo z atrybutuami (slotami) - wystarczy:

define class <kolor-okna> (<okno>)
  slot typ_koloru;
  slot kod_koloru;
end class;

Chcesz dodać do powyzszego metode, wystarczy:

define method hello-world() => ();
  puts("Hello, world!");
end method;

Albo wygodne funkcje/metody w stylu:

define method rozmiar_buta(osoba :: <string>)
  if (osoba = "Jasio")
    14;
  else
    11;
  end if;
end method;

Czy można jeszcze prosciej? :) Ostatnio widzialem w sieci taki projekt
duzego sniffera
pisanego w Dylanie ( http://www.networknightvision.com/ ) to mimo że
znam podstawy tego
jezyka  - to rozumiem praktycznie caly kod zrodlowy wiekszosci
modulow. Nie mowie ze jestem
w stanie sprawnie w tym pisac - ale czyta sie to jak opowiadanie :)

pozdrawiam

pawellt@gazeta.pl napisał(a):
>> O... jakbym czytał opis Common Lispu :-) Ale do nauki polecałbym raczej
>> Scheme (inny dialekt Lispu, w ostatnich latach dość popularny, właśnie
>> wychodzi R6RS).
> 
> Ale te wszystkie nawiasy. Sa prawie tak samo wkurzajace jak wcięcia w
> Pythonie :)

Dlaczego ? Przynajmniej wszystko jest zuniformizowane do jednej postaci. 
Patrząc na dany kawałek kodu, zawsze wiesz, że jest to aplikacja 
operatora do argumentów. Nie musisz się zastanawiać nad priorytetami i 
sposobem wiązań różnych dziwnych znaczków (zazwyczaj różnie przez 
różnych ludzi nawiasowanych).

http://groups.google.pl/group/comp.lang.lisp/msg/6f52a3ddc61d6028?hl=pl&

> No i te operacje na listach, gdzie jednak troche moga zaciemniac te
> nieco "malo przejrzyste":
> 
> 	( car ( cdr ( cdr ( blabla ) ) ) )

Tak się _nie_ pisze w Lispie. Tak się pisało w Lispie z lat 50-tych. I 
nawet rzadko wtedy (po pierwsze - używaj zmiennych zamiast składać 
tasiemcowe wołania, po drugie - do przechowywania ustalonej liczby 
elementów używaj tablic/struktur/klas - a jeżeli to powyższe jest 
klasyczną operacją listową, to taki kod i tak nie działa, bo musisz 
sprawdzać, czy przypadkiem po drodze lista się nie kończy, po trzecie - 
powyższe równoważne jest "(caddr (bla))", po czwarte - nie piszemy 
spacji pomiędzy nawiasami a wyrażeniem).

> Poza tym sama kwestia obiektowosci. W Scheme masz cos w stylu:
> 
> (define samochod-class
>   (make-standard-class
>    'superclass #t
>    'slots '(frame parts size)
>    'method-names '()))

???

W Common Lispie wyglądało by to tak:

(defclass samochod ()
   ((frame :accessor samochod-frame
           :initarg :frame)
    (parts :accessor samochod-parts
           :initarg :parts)
    (size  :accessor samochod-size
           :initarg :size)) )

(gdzie oczywiście definiowanie akcesorów i inicjatorów można pominąć).

Scheme nie ma ustandaryzowanego systemu obiektów, ale wiele 
dostarczanych jako biblioteki. W PLT np. tak:

http://download.plt-scheme.org/doc/360/html/mzlib/mzlib-Z-H-4.html#node_chap_4

Albo z propozycji Christiana Queinneca:

http://www-spi.lip6.fr/~queinnec/WWW/Meroon.html

Albo dokładne tak jak w CL'u.


Nie obraź się, ale wydaje mi się, że większość obiekcji jakie masz do 
Lispu wynikają z nieznajomości tego języka (lub przynajmniej nieobycia).

>> Chyba sobie żartujesz...
> 
> Dlaczego? Chociażby kwestia definicji klas w Dylanie:

Napiszę wieczorem jak znajdę chwilkę.


mp

Dnia 15.05.2007 pawellt@gazeta.pl <pawellt@gazeta.pl> napisał/a:

> Ale te wszystkie nawiasy. Sa prawie tak samo wkurzajace jak wcięcia w
> Pythonie :)

Wcięcia w pythonie denerwują tylko na początku. Później dostrzega się
więcej plusów niż minusów ;)
-- 
Adam              "Prawda jest prosta - gdyby było inaczej
                   każdy głupiec mógłby ją zrozumieć".

Dnia 15 May 2007 15:33:42 -0700
pawellt@gazeta.pl napisał(a):


> Poza tym sama kwestia obiektowosci. W Scheme masz cos w stylu:
> 
> (define samochod-class
>   (make-standard-class
>    'superclass #t
>    'slots '(frame parts size)
>    'method-names '()))
> 
> Chociażby kwestia definicji klas w Dylanie:
> 
> define class <kolor-okna> (<okno>)
> end class;
> 
> ... i już masz definicje klasy "kolor-okna" dziedziczącą po klasie
> "okno".
> Chcesz to samo z atrybutuami (slotami) - wystarczy:
> 
> define class <kolor-okna> (<okno>)
>   slot typ_koloru;
>   slot kod_koloru;
> end class;
> 
> Chcesz dodać do powyzszego metode, wystarczy:
> 
> define method hello-world() => ();
>   puts("Hello, world!");
> end method;
> 
No to może przykład w Camlu:

open Printf

class pojazd model =
  object
    val model = model; (* Nie zmienny po utworzeniu... *)
    val mutable predkosc = 0; (* Musi być zainicjalizowane *)

    method gaz n = 
      predkosc <- n;
      printf "%s ma prędkość %d\n" model predkosc;

    method stop =
      predkosc <- 0;
      printf "%s zatrzymany\n" model
  end;;

(* Wykorzystanie *)
let rower = new pojazd "Rower";;
rower#gaz 5;;
rower#stop;;

(* Klasa dziedzicząca *)
class samochod model =
  object
  inherit pojazd ("Samochód " ^ model)

  method swiatla w = 
  	if w = true then 
		printf "Światła włączone\n"
	else	printf "Światła wyłączone\n";

  end;;

let volvo = new samochod "Volvo";;
volvo#swiatla true;
volvo#stop;;


> Albo wygodne funkcje/metody w stylu:
> 
> define method rozmiar_buta(osoba :: <string>)
>   if (osoba = "Jasio")
>     14;
>   else
>     11;
>   end if;
> end method;
> 
let rozmiarButa osoba =
  if osoba = "Jasio" then
    14
  else
    11;;

print_int (rozmiarButa "Jasio")


W sumie program wyświetli:
Rower ma prędkość 5
Rower zatrzymany
Światła włączone
Samochód Volvo zatrzymany
14

IMHO czystszy w obiektowości i od Dylana i od Lispa. ;)

-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl 
pgp: 0x90746E79 @ pgp.mit.edu

Adam Mikuta <adammikutaWytnij@gmail.wyt.nij.com> wrote:
> Dnia 15.05.2007 pawellt@gazeta.pl <pawellt@gazeta.pl> napisał/a:
> 
>> Ale te wszystkie nawiasy. Sa prawie tak samo wkurzajace jak wcięcia w
>> Pythonie :)
> 
> Wcięcia w pythonie denerwują tylko na początku. Później dostrzega się
> więcej plusów niż minusów ;)
	... BTW, podobno MIT odpuscil sobie Scheme na rzecz Pythona ...
Z powazaniem
								Adam Przybyla

Dnia 16-05-2007, śro o godzinie 11:32 +0200, Michał Przybyłek
napisał(a):

> Dlaczego ? Przynajmniej wszystko jest zuniformizowane do jednej postaci.

To zmniejsza czytelność, a nie zwiększa. Jeśli wszystkie konstrukcje
wyglądają podobnie, to trudniej je rozróżnić na pierwszy rzut oka
i trzeba bardziej wczytywać się w słowa.

Oczywiście przesada w drugą stronę, kiedy każda funkcja miałaby własną
gramatykę argumentów, też jest zła. Lepiej wypośrodkować i dać
charakterystyczną składnię podstawowym konstrukcjom.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowałczyk napisał(a):

>> Dlaczego ? Przynajmniej wszystko jest zuniformizowane do jednej postaci.
> 
> To zmniejsza czytelność, a nie zwiększa. Jeśli wszystkie konstrukcje
> wyglądają podobnie, to trudniej je rozróżnić na pierwszy rzut oka
> i trzeba bardziej wczytywać się w słowa.

Nie. W Lispie wszystkie konstrukcje wyglądają podobnie, bo są podobne - 
a nawet identyczne. Nie trzeba ich rozróżniać. Zawsze (w uproszczeniu 
nieistotnym dla tej dyskusji) jest to aplikacja operatora do argumentów.

To właśnie w innych językach widząc napis:

x + ++ y * * z * v >> - w == s > t

trzeba porozróżniać operatory i pokontemplować nad ich łącznością i 
priorytetami, aby zrozumieć jak owy napis w ogóle sparsować. Zauważ, że 
ja powyższego nie zapisałem w jakieś złośliwej konwencji, tylko w 
naturalnej dla klasycznych języków formie - z wykorzystaniem niejawnego 
nawiasowania wyrażeń.

Zwróć uwagę na samą filozofię wprowadzania do języka priorytetów i 
wiązań. To jest dokładnie w jej duchu.


BTW, zapomniałeś odnieść się do linka, którego podałem.

mp


ps. I o ile pamiętam, to mieliśmy umowę, że nie będziesz publicznie 
krytykował Lispu :-)

> Nie obraź się, ale wydaje mi się, że większość obiekcji jakie masz do
> Lispu wynikają z nieznajomości tego języka (lub przynajmniej nieobycia).

Ja nawet nie ukrywam, że znam tylko podstawy Scheme - ale powyższe
konstrukcje
przewijaja sie w tutorialach dotyczacych tego jezyka ktorych sporo w
sieci.
Analogiczne sa tez w slynnej przeciez dla schemersów ksiazce -
"Struktura i interpretacja programow komputerowych" (Abelson).

Inna sprawa (byc moze sie myle. Jesli tak - to prosilbym o
sprostowanie), ze
Lisp wydaje mi sie dojrzalym, powaznym jezykiem wykorzystywanym miedzy
innymi
w A.I, sieciach neuronowych itp, natomiast Scheme jakos duzo "mniej
powaznie sie
prezentuje". Oczywiscie w LISPie spora wada, szczegolnie dla
poczatkujacego jest
brak konstrukcji imperatywnych.
Czy jest jakas implementacja Scheme z porzadna iloscia sensownych
bibliotek (parsery,
sockety, WWW), mozliwosca latwego budowania GUI (cos jjak defaultowo
dzialajacy
Tkinter w Pythonie chociazby) itp? MrED z PLT wydaje sie raczej tylko
zestawem kilku
prostych widgetow dla celow edukacyjno-demonstracyjnych, a chodziloby
o cos,
w czym mozna robic rowniez wieksze i powazniejsze aplikacja z GUI

> Napiszę wieczorem jak znajdę chwilkę.

No wlasnie.. bo ciekaw jestem Waszej opinii na temat Dylana.
Skladnie ma na prawde klarowna i raczej pozbawiona udziwnien.

Dnia 17-05-2007, czw o godzinie 23:19 +0200, Michał Przybyłek
napisał(a):

> > To zmniejsza czytelność, a nie zwiększa. Jeśli wszystkie konstrukcje
> > wyglądają podobnie, to trudniej je rozróżnić na pierwszy rzut oka
> > i trzeba bardziej wczytywać się w słowa.
> 
> Nie. W Lispie wszystkie konstrukcje wyglądają podobnie, bo są podobne - 
> a nawet identyczne.

Nie są identyczne. Definicja lokalnej zmiennej jest czym innym niż
arytmetyka na liczbach, arytmetyka na liczbach jest czym innym niż
indeksowanie macierzy, indeksowanie macierzy jest czym innym niż
przypisanie zmiennej, przypisanie zmiennej jest czym innym niż
stworzenie lokalnej funkcji. Te konstrukcje mają cechy wspólne,
ale zdecydowanie są różne.

Analogia: znaki drogowe mają różne kształty, żeby można było je łatwiej
rozróżnić na pierwszy rzut oka. A przecież teoretycznie wszystkie
mogłyby być prostokątne.

Analogia: niektóre małe litery alfabetu łacińskiego odstają w górę albo
w dół od głównego ciągu. Cóż za niekonsekwencja!

Analogia: dobrze zaprojektowane ikony na paskach narzędziowych mają
różnorodne kształty.

Przy tworzeniu dzieła, które człowiek będzie czytał, należy
wykorzystywać dostępną różnorodność form. Oczywiście bez przesady.

Nawet Lisp stosuje kilka skrótów: ' ` , ,@
bez których notacja byłaby bardziej spójna, ale mniej wygodna.

> Nie trzeba ich rozróżniać.

Ale warto.

> Zawsze (w uproszczeniu nieistotnym dla tej dyskusji) jest to aplikacja
> operatora do argumentów.

No to co?

W dodatku Common Lisp rozróżnia wyrażenia, które są do siebie bardziej
podobne niż np. wzięcie wielkości tablicy jest podobne do definicji
lokalnej zmiennej - a mianowicie aplikację globalnej funkcji i aplikację
funkcji przekazanej jako parametr:
   (f x)
   (funcall f x)

> BTW, zapomniałeś odnieść się do linka, którego podałem.

Tam nie było żadnych argumentów.

> ps. I o ile pamiętam, to mieliśmy umowę, że nie będziesz publicznie 
> krytykował Lispu :-)

Nie przypominam sobie.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

pawellt@gazeta.pl napisał(a):

 > Oczywiscie w LISPie spora wada, szczegolnie dla
 > poczatkujacego jest

Są konstrukcje imperatywne.

W Scheme nie są jakoś szczególnie wspierane (trzeba doładować 
odpowiednie biblioteki), ale w CL'u np. sam mechanizm pętli jest bez 
porównania wygodniejszy i potężniejszy od tego co masz w klasycznych 
językach programowania (poszukaj semantykę rozszerzonego loop'a).

 > Czy jest jakas implementacja Scheme z porzadna iloscia
 > sensownych bibliotek (parsery, sockety, WWW), mozliwosca
 > latwego budowania GUI (cos jjak defaultowo dzialajacy
 > Tkinter w Pythonie chociazby) itp?

Wszystko to jest przy PLT. Nie wiem na ile wygodne.

>> Napiszę wieczorem jak znajdę chwilkę.
> 
> No wlasnie.. bo ciekaw jestem Waszej opinii na temat Dylana.
> Skladnie ma na prawde klarowna i raczej pozbawiona udziwnien.

Nie mogę znaleźć pewnego artykułu. Jeden z współtwórców Dylanu 
wypowiadał się właśnie o tym jak w Dylanie zwalili składnię i system 
makr. Jak znajdę to podeślę.

BTW, wśród Lispowców krąży takie przekonanie, że "Dylan to byłby nawet 
niezłym językiem, gdyby miał normalną składnię (tj. Lispową)" :-)


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

> W dodatku Common Lisp rozróżnia wyrażenia, które są do siebie bardziej
> podobne niż np. wzięcie wielkości tablicy jest podobne do definicji
> lokalnej zmiennej - a mianowicie aplikację globalnej funkcji i aplikację
> funkcji przekazanej jako parametr:
>    (f x)
>    (funcall f x)

To jest nieprawda. Rozróżnienie dotyczy tego, w której przestrzeni nazw 
siedzi dany symbol, a nie czy funkcja jest globalna, czy nie. Pierwszy 
argument (tj. operator) w formie aplikacyjnej _zawsze_ brany jest z 
przestrzeni funkcyjnej, a pozostałe (tj. argumenty) z przestrzeni zmiennych.

Nie rozumiem w ogóle dlaczego miałyby być brane z tej samej przestrzeni, 
ani dlaczego to miałoby być to "bardziej spójne". W końcu tak czy 
inaczej jest asymetria pomiędzy pierwszym elementem formy, a 
pozostałymi. Są też jeszcze inne przestrzenie - np. dla punktów 
nielokalnych zmian przebiegu wykonania programu, albo dla nazw klas.

To są po prostu różne rzeczy i nie ma sensu wpakowywać ich do tego 
samego worka.

I, zresztą, ułatwia to pisanie kodu utrudniając przypadkowy clash 
różnych konceptów. Gdyby wszystko siedziało w jednej przestrzeni nie 
mógłbyś mieć żadnych dwóch z następujących rzeczy:

- typu "list",
- konstruktora listy "list"
- zmiennej lokalnej przekazanej jako "list" (dokładniej, nei było by to 
dobrym pomysłem i tak jak w innych językach używałbyś nazw typu "ls", 
zamiast "list", "len" zamiast "length" itp.).


Zauważ też, że rozgraniczenie przestrzeni nazw jest spotykane w wielu (w 
większości) językach programowania. Niektóre języki stosują jeszcze 
dziwną regułę nie/kapitalizowania pierwszych liter w zależności od tego, 
jakiego konceptu dana nazwa dotyczy, lub w zależności od tego czy 
zmienna jest najbardziej zewnętrzna leksykalnie, czy nie, co zawsze mnie 
bawiło (nawet kiedyś zaproponowałem, że można by kapitalizować ostatnią 
literę nazwy w zależności od tego, czy jest najbardziej wewnętrzna 
leksykalnie, ale przeszło bez echa...).


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

> Analogia: znaki drogowe mają różne kształty, żeby można było je łatwiej
> rozróżnić na pierwszy rzut oka. A przecież teoretycznie wszystkie
> mogłyby być prostokątne.
> 
> Analogia: niektóre małe litery alfabetu łacińskiego odstają w górę albo
> w dół od głównego ciągu. Cóż za niekonsekwencja!
> 
> Analogia: dobrze zaprojektowane ikony na paskach narzędziowych mają
> różnorodne kształty.

Fruwasz w powietrzu zamiast stąpać po ziemi. Analogie są wtedy 
użyteczne, kiedy nie mamy dostępu do wejściowego zagadnienia.

Skoro kształty znaków drogowych są dobrą analogią składni Lispu, to 
dlaczego musiałeś się uciekać do pokazania przykładu przechodząc przez 
analogię, zamiast bezpośrednio pokazać taki przykład w Lispie - tj. 
dlaczego  przepuściłeś przez analogię tylko konkluzję, a nie cały problem ?


W ten sposób można łatwo manipulować i fałszować, nie dociekać prawdę.


m

Marcin 'Qrczak' Kowalczyk napisał(a):

>> ps. I o ile pamiętam, to mieliśmy umowę, że nie będziesz publicznie 
>> krytykował Lispu :-)
> 
> Nie przypominam sobie.

Ale ja pamiętam.

Była rzecz przy onejś okazji, kiedy to zgodziłeś się słusznie, że 
krytyka Lispu w pewnych środowiskach przynosi działanie praktycznie 
wyłącznie destrukcyjne na delikatne umysły z cielsk zamieszkujących owe 
środowisko. Bardzo prosta podniesiona wtedy przyczyna takiego stanu 
rzeczy została - nie ma drugiego takiego języka programowania na tej 
obserwowalnej części świata, który uczyłby tak wiele dobrych nawyków 
programistycznych, nie ucząc przy tym jakichkolwiek złych.


mp

pawellt@gazeta.pl napisał(a):

> Inna sprawa (byc moze sie myle. Jesli tak - to prosilbym o
> sprostowanie), ze
> Lisp wydaje mi sie dojrzalym, powaznym jezykiem wykorzystywanym miedzy
> innymi
> w A.I, sieciach neuronowych itp, natomiast Scheme jakos duzo "mniej
> powaznie sie
> prezentuje".

Prawda jest taka, że główna siła ludzi zajmujących się rozwojem Lispów 
skupiona jest teraz wokół Scheme. Standard Common Lispu ma już 10 lat z 
hakiem i praktycznie zerowe szanse na ponowne otwarcie (z wielu względów 
- także takiego, że proces standaryzacyjny tego języka jest wyjątkowo 
trudny).

Mówię to z pewną dozą smutku - dla mnie Common Lisp jest językiem 
nieporównywalnie lepiej zaprojektowanym i przemyślanym niż Scheme.

 > Oczywiscie w LISPie spora wada, szczegolnie dla
 > poczatkujacego jest brak konstrukcji imperatywnych.

Tutaj masz kilka prostych przykładów konstrukcji wykorzystującej pętle w 
Common Lispie:

(defun fact (n)
   (loop with acc = 1
         for i from 1 to n
           do (setq acc (* acc i))
     finally (return acc) ) )


(defun zip-2 (list-1 list-2)
   (loop for e1 in list-1
         for e2 in list-2
           collect (cons e1 e2) ) )


(defun inject-position (list)
   (loop for e in list
         for n from 0
           collect (cons e n) ) )


Pokaż mi jak to zapiszesz w C++/Javie, to zobaczymy, czy jest zwięźlej 
lub wygodniej :-P


mp

Dnia 18-05-2007, pią o godzinie 00:59 +0200, Michał Przybyłek
napisał(a):

> > W dodatku Common Lisp rozróżnia wyrażenia, które są do siebie bardziej
> > podobne niż np. wzięcie wielkości tablicy jest podobne do definicji
> > lokalnej zmiennej - a mianowicie aplikację globalnej funkcji i aplikację
> > funkcji przekazanej jako parametr:
> >    (f x)
> >    (funcall f x)
> 
> To jest nieprawda. Rozróżnienie dotyczy tego, w której przestrzeni nazw 
> siedzi dany symbol, a nie czy funkcja jest globalna, czy nie.

To nie przeczy temu, co napisałem. Globalna funkcja siedzi w przestrzeni
nazw funkcji. Parametr funkcji siedzi w przestrzeni nazw zmiennych.
Opisałem praktyczny skutek, a nie mechanizm.

> Nie rozumiem w ogóle dlaczego miałyby być brane z tej samej przestrzeni,

Bo funkcja jest szczególnym przypadkiem wartości. Nie jest odrębnym
bytem, który wartością nie jest. Nazwana funkcja bywa przekazywana jak
inne wartości, a wartości bywają aplikowane jako funkcje (bez statycznej
wiedzy o tym, czy są funkcjami).

> ani dlaczego to miałoby być to "bardziej spójne".

Użyłem argumentu spójności dlatego, że Ty go wcześniej użyłeś odnośnie
składni, a więc powinieneś uważać spójność za ważną.

> I, zresztą, ułatwia to pisanie kodu utrudniając przypadkowy clash 
> różnych konceptów. Gdyby wszystko siedziało w jednej przestrzeni nie 
> mógłbyś mieć żadnych dwóch z następujących rzeczy:
> 
> - typu "list",
> - konstruktora listy "list"
> - zmiennej lokalnej przekazanej jako "list" (dokładniej, nei było by to 
> dobrym pomysłem i tak jak w innych językach używałbyś nazw typu "ls", 
> zamiast "list", "len" zamiast "length" itp.).

Jak wiesz, do rozwiązywania tego problemu stosuję konwencję wielkości
liter: LIST, List, list. Nie potrzeba więc osobnych przestrzeni nazw.

> Zauważ też, że rozgraniczenie przestrzeni nazw jest spotykane w wielu
> (w większości) językach programowania.

Moim zdaniem oba rozwiązania mają podobną popularność. Wspólna
przestrzeń nazw dla zmiennych i funkcji jest szczególnie sensowna
w języku, który ułatwia przekazywanie funkcji i aplikację ich pośrednio,
a więc tam, gdzie to ma sens semantycznie.

Funkcje i zmienne w tej samej przestrzeni nazw:
- C, C++, Haskell, JavaScript, Python, OCaml, Scheme, SML

Funkcje i zmienne w różnych przestrzeniach nazw:
- C#, Common Lisp, Java, Perl, Prolog, Ruby, Smalltalk

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia 18-05-2007, pią o godzinie 23:33 +0200, Michał Przybyłek
napisał(a):

> (defun fact (n)
>    (loop with acc = 1
>          for i from 1 to n
>            do (setq acc (* acc i))
>      finally (return acc) ) )
> 
> 
> (defun zip-2 (list-1 list-2)
>    (loop for e1 in list-1
>          for e2 in list-2
>            collect (cons e1 e2) ) )
> 
> 
> (defun inject-position (list)
>    (loop for e in list
>          for n from 0
>            collect (cons e n) ) )
> 
> 
> Pokaż mi jak to zapiszesz w C++/Javie, to zobaczymy, czy jest zwięźlej 
> lub wygodniej :-P

Nie będę bronił C++ ani Javy. W każdym razie w moim Kogucie wygląda to
tak:

def Fact n {
   Between 1 n->Fold 1 '*'
};

// Zip już jest standardowo. Gdyby nie było:
def Zip seq1 seq2 {
   Map seq1 seq2 ','
};

def InjectPosition seq {
   Zip seq (From 0)
};

więc składnia Common Lispa pod tym względem nie robi na mnie wrażenia.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk napisał(a):

[...]

> więc składnia Common Lispa pod tym względem nie robi na mnie wrażenia.

To był przykład na kod _imperatywny_. Użyj pętli, a nie generatorów i 
wtedy się pochwal :-P


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

>>> W dodatku Common Lisp rozróżnia wyrażenia, które są do siebie bardziej
>>> podobne niż np. wzięcie wielkości tablicy jest podobne do definicji
>>> lokalnej zmiennej - a mianowicie aplikację globalnej funkcji i aplikację
>>> funkcji przekazanej jako parametr:
>>>    (f x)
>>>    (funcall f x)
>> To jest nieprawda. Rozróżnienie dotyczy tego, w której przestrzeni nazw 
>> siedzi dany symbol, a nie czy funkcja jest globalna, czy nie.
> 
> To nie przeczy temu, co napisałem. Globalna funkcja siedzi w przestrzeni
> nazw funkcji. Parametr funkcji siedzi w przestrzeni nazw zmiennych.
> Opisałem praktyczny skutek, a nie mechanizm.

Napisałeś nieprawdę:

(defun foo () nil)

(defvar *foo* #'foo)

Powyżej zdefiniowana jest jedna globalna funkcja (w pustym środowisku 
zewnętrznym) i może być ona wołana zarówno:

(foo)

jak i:

(funcall *foo*)

Dlatego, bo rozróżnienie _nie_ jest po globalności/lokalności danej 
funkcji, a po środowisku, w którym siedzi zmienna odnosząca się do niej.

Zgadzam się, że gdyby było tak jak to napisałeś, to byłoby niespójnie i 
bezsensownie.

>> Nie rozumiem w ogóle dlaczego miałyby być brane z tej samej przestrzeni,
> 
> Bo funkcja jest szczególnym przypadkiem wartości. Nie jest odrębnym
> bytem, który wartością nie jest.

Klasa też jest szczególnym przypadkiem wartości. Kontynuacja też. Co z 
tego ?

Rozróżnienie nie jest po _wartości_ danego obiektu, a po sposobie jego 
użycia. Funkcje używa się inaczej niż zwykłe wartości, inaczej niż 
wartości będące typami i inaczej niż wartości będące kontynuacjami. 
Skoro są używane w różnych kontekstach, to nie widzę dlaczego miałoby 
być "logiczniej" trzymać to wszystko w jednym środowisku.

To jest raczej kwestia wygody a nie "logiczności", czy "spójności". I 
jedni uważają, że tak jest wygodnie, inni, że inaczej.

BTW, czy np. etykiety dla "goto", też powinny siedzieć w tej samej 
przestrzeni co pozostałe rzeczy ?


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

> def Fact n {
>    Between 1 n->Fold 1 '*'
> };

Tą strzałkę tak jak uważałem za ohydztwo, tak uważam nadal. Dobry 
przykład jak wielkie cierpienie w klasycznych językach sprawia choćby 
para dodatkowych nawiasów:

Fold (Between 1 n) 1 '*'

Masz objawy silnej parenthophobi (nie mylić z parthenophobią) :-)

> // Zip już jest standardowo. Gdyby nie było:
> def Zip seq1 seq2 {
>    Map seq1 seq2 ','
> };
> 
> def InjectPosition seq {
>    Zip seq (From 0)
> };

BTW, Kogut jest już praktycznie martwy. Jego autor i główny koder 
znudził się tą zabawką jakiś czas temu.


mp

Dnia 19-05-2007, sob o godzinie 01:37 +0200, Michał Przybyłek
napisał(a):

> Powyżej zdefiniowana jest jedna globalna funkcja (w pustym środowisku 
> zewnętrznym) i może być ona wołana zarówno:
> 
> (foo)
> 
> jak i:
> 
> (funcall *foo*)

Natomiast parametr funkcji (ogólniej: funkcja, która jest dana inaczej
niż jako nazwa przypisana konkretnemu ciału funkcji albo lambda) może
być wołany tylko przez funcall.

Tylko mi nie radź, żebym w ramach spójności wołał każdą funkcję przez
funcall. Nie interesuje mnie takie rozwiązanie, żeby wszystkie przypadki
były jednakowo niewygodne.

> Dlatego, bo rozróżnienie _nie_ jest po globalności/lokalności danej 
> funkcji, a po środowisku, w którym siedzi zmienna odnosząca się do niej.

Kłótnia o nazwanie kryteriów jest nieciekawa. Ważne, że rozdzielenie
tych środowisk jest mało praktyczne.

> Rozróżnienie nie jest po _wartości_ danego obiektu, a po sposobie jego 
> użycia. Funkcje używa się inaczej niż zwykłe wartości,

Nieprawda. Funkcję mogę przekazać jako argument innej operacji albo
zaaplikować do argumentów. Parametr funkcji mogę przekazać dalej jako
argument innej operacji albo zaaplikować do argumentów.

> Skoro są używane w różnych kontekstach,

Ależ są używane w tych samych kontekstach. Wystarczy niepusta część
wspólna.

Przyznaję tylko tyle, że jeden z kontekstów jest częstszy w przypadku
funkcji, a drugi jest częstszy w przypadku innych wartości. Ta częstość
nie jest jednak tak duża, żebym nie zauważał #' i funcalli.

> BTW, czy np. etykiety dla "goto", też powinny siedzieć w tej samej 
> przestrzeni co pozostałe rzeczy ?

Jeśli nie są first class values, to są używane w różnych kontekstach,
więc mogą być w różnych przestrzeniach nazw.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk napisał(a):

> Tylko mi nie radź, żebym w ramach spójności wołał każdą funkcję przez
> funcall. Nie interesuje mnie takie rozwiązanie, żeby wszystkie przypadki
> były jednakowo niewygodne.

Jakiej spójności ? Przecież jest spójnie - zawsze masz ewaluację 
pierwszego argumentu w środowisku funkcyjnym, pozostałych w środowisku 
zwykłych wartości i aplikację pierwszego argumentu, który musi być 
funkcją (operatorem) do pozostałych, które muszą być zwykłymi wartościami.

Także oczywiście:

(funcall arg-f arg-1 arg-2)

Poddaje się temu schematowi. Operator "funcall" aplikowany jest do 
trzech argumentów wartościowanych w zwykłym środowisku, a wynikiem tej 
aplikacji jest sprawdzenie, czy wartość pod arg-f jest obiektem 
funkcyjnym i jeżeli tak to aplikacja tego obiektu do pozostałych argumentów.

>> Dlatego, bo rozróżnienie _nie_ jest po globalności/lokalności danej 
>> funkcji, a po środowisku, w którym siedzi zmienna odnosząca się do niej.
> 
> Kłótnia o nazwanie kryteriów jest nieciekawa.

Nie chodzi o nazywanie kryteriów, a o zrozumienie istoty rzeczy. 
Zarzucasz, że 1000 + 1000 = 2001 jest niekonsekwencją w dodawaniu, a 
kiedy Ci pokazuje, że to nieprawda, bo 1000 + 1000 = 2000, odpierasz, że 
to nie ma znaczenia, bo liczby są tak duże, że ta jedynka na końcu nie 
robi różnicy.

> Ważne, że rozdzielenie
> tych środowisk jest mało praktyczne.

Nie jest.

>> Rozróżnienie nie jest po _wartości_ danego obiektu, a po sposobie jego 
>> użycia. Funkcje używa się inaczej niż zwykłe wartości,
> 
> Nieprawda. Funkcję mogę przekazać jako argument innej operacji albo
> zaaplikować do argumentów. Parametr funkcji mogę przekazać dalej jako
> argument innej operacji albo zaaplikować do argumentów.

Prawda. Funkcji używa się inaczej niż pozostałych obiektów - tylko 
funkcje są aplikowane. Oczywiście _istnieją_ też konteksty, w których 
używa się funkcji tak jak zwykłych wartości.

>> Skoro są używane w różnych kontekstach,
> 
> Ależ są używane w tych samych kontekstach. Wystarczy niepusta część
> wspólna.

Nieprawda. Kwantyfikator jest ogólny.

> Przyznaję tylko tyle, że jeden z kontekstów jest częstszy w przypadku
> funkcji, a drugi jest częstszy w przypadku innych wartości. Ta częstość
> nie jest jednak tak duża, żebym nie zauważał #' i funcalli.

Nie traktuj dodatkowej ilości kodu jako zło, z którym trzeba walczyć, a 
jako przydatne komentarze. Np. w Adzie (jednym z najbardziej czytelnych 
i najlepiej zaprojektowanych klasycznych języków) jest wiele 
dodatkowego, czegokolwiek nie wnoszącego kodu.

>> BTW, czy np. etykiety dla "goto", też powinny siedzieć w tej samej 
>> przestrzeni co pozostałe rzeczy ?
> 
> Jeśli nie są first class values, to są używane w różnych kontekstach,
> więc mogą być w różnych przestrzeniach nazw.

Co rozumiesz przez bycie "first-class" ? Czy kontynuacja łapana przez 
"return" nie jest first-class, choć mogę owinąć ją w lambdę i przekazać 
dalej ?

Bo jeżeli dla Ciebie nie jest, to powiem, że rozróżnienie jest na 
poziomie syntaktycznym i w takim razie wtóre względem samej koncepcji. 
Tzn. wtedy, to, że dana rzecz nie jest "first class" możesz sobie 
zdefiniować jako "nie siedzi w środowisku zwykłych wartości".


mp

Michał Przybyłek napisał(a):

> Co rozumiesz przez bycie "first-class" ? Czy kontynuacja łapana przez 
> "return" nie jest first-class, choć mogę owinąć ją w lambdę i przekazać 
> dalej ?

Wyjaśnienie dla innych śledzących wątek:

(defun foo ()
   (flet ((escape ()
            (return-from foo 'a) ))
     (bar #'escape)
     'b ) )

(defun bar (fun)
   (funcall fun)
   'c )


Punkt wyskoku z funkcji "foo" (tj. kontynuacja) jest owijany w lokalne 
domknięcie "escape" i przekazywany do "bar". Kiedy "bar" odpali takie 
domknięcie, bieżący przepływ wykonywania programu zostaje przerwany i 
zastąpiony miejscem powrotu z "foo".


mp

Dnia 19-05-2007, So o godzinie 11:59 +0200, Michał Przybyłek napisał(a):

> Jakiej spójności ? Przecież jest spójnie - zawsze masz ewaluację 
> pierwszego argumentu w środowisku funkcyjnym, pozostałych w środowisku 
> zwykłych wartości i aplikację pierwszego argumentu, który musi być 
> funkcją (operatorem) do pozostałych, które muszą być zwykłymi wartościami.

Niespójność polega na tym, że jedne funkcje są dostępne w środowisku
funkcyjnym, a inne - w środowisku zwykłych wartości.

To jest poboczny temat. Zaczęło się od mnogości nawiasów, która irytuje
mnie bardziej niż #' i funcall/apply.

> > Nieprawda. Funkcję mogę przekazać jako argument innej operacji albo
> > zaaplikować do argumentów. Parametr funkcji mogę przekazać dalej jako
> > argument innej operacji albo zaaplikować do argumentów.
> 
> Prawda. Funkcji używa się inaczej niż pozostałych obiektów - tylko 
> funkcje są aplikowane. Oczywiście _istnieją_ też konteksty, w których 
> używa się funkcji tak jak zwykłych wartości.

Wystarczy, że istnieją takie konteksty, żeby była konieczność jawnego
importowania z jednej przestrzeni nazw do innej. Jawne importowanie jest
dla mnie wadą, bo każe programiście rozróżniać sytuacje, które mogą być
z powodzeniem traktowane jako to samo.

> Nie traktuj dodatkowej ilości kodu jako zło, z którym trzeba walczyć,
> a jako przydatne komentarze.

Dla mnie nieprzydatne. To, że dane słowo oznacza funkcję, nie jest tak
ważną informacją, żeby zmuszać programistę do jawnego zaznaczania tego
w każdym miejscu, w którym jest użyte.

W Perlu jest osobna przestrzeń nazw dla skalarów, osobna dla tablic,
osobna dla słowników, osobna dla funkcji i osobna dla uchwytów
wejścia-wyjścia. Też trzeba owinąć wszystko w skalar za pomocą jawnej
operacji, żeby przekazać obiekt pośrednio, a potem odwinąć w miejscu
użycia. To mi się nie podoba tak samo jak w Lispie. Tego też będziesz
bronił? Jeśli nie, to dlaczego chcesz wyróżniać funkcje, a nie chcesz
wyróżniać tablic? Przecież tablice też są szczególnymi wartościami:
tylko tablice są indeksowane.

> >> BTW, czy np. etykiety dla "goto", też powinny siedzieć w tej samej 
> >> przestrzeni co pozostałe rzeczy ?
> > 
> > Jeśli nie są first class values, to są używane w różnych kontekstach,
> > więc mogą być w różnych przestrzeniach nazw.
> 
> Co rozumiesz przez bycie "first-class" ? Czy kontynuacja łapana przez 
> "return" nie jest first-class, choć mogę owinąć ją w lambdę i przekazać 
> dalej ?

Mogę się zgodzić, że jest first class, więc mogłyby też być w tej samej
przestrzeni nazw. Przekazywanie etykiet pośrednio jest zapewne tak
rzadkie, że to, czy są w tej samej przestrzeni nazw, nie ma dużego
znaczenia praktycznego i nie będę tutaj naciskał w żadną stronę.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk napisał(a):

> To jest poboczny temat. Zaczęło się od mnogości nawiasów, która irytuje
> mnie bardziej niż #' i funcall/apply.

Pierwszy raz o czymś takim piszesz, choć przeczuwałem ten stan rzeczy od 
dłuższego czasu. Opowiedz mi o tym.

> W Perlu jest osobna przestrzeń nazw dla skalarów, osobna dla tablic,
> osobna dla słowników, osobna dla funkcji i osobna dla uchwytów
> wejścia-wyjścia. Też trzeba owinąć wszystko w skalar za pomocą jawnej
> operacji, żeby przekazać obiekt pośrednio, a potem odwinąć w miejscu
> użycia. To mi się nie podoba tak samo jak w Lispie. Tego też będziesz
> bronił?

Nie będę bronił czegokolwiek związanego z Perlem. Zauważ, że ja nie 
wyciągnąłem Perla kiedy mówiliśmy o operatorach, uważając, że byłoby to 
nie fair. Ale skoro Ty już go wyciągnąłeś, to może wyjaśnisz jednak jak 
składnia Perlu wpasowuje się w Twoją filozofię, hm... ?

> Jeśli nie, to dlaczego chcesz wyróżniać funkcje, a nie chcesz
> wyróżniać tablic? Przecież tablice też są szczególnymi wartościami:
> tylko tablice są indeksowane.

Jeszcze raz Ci powtarzam, że funkcje są tak czy inaczej już wyróżnione 
_syntaktycznie_. Tablice nie.

Ale może skupmy się na jednym aspekcie - rysuj za każdym razem co 
dokładnie zarzucasz temu podejściu - niespójność/nielogiczność, czy to, 
że jest niewygodne.

Z pierwszym nie wygrasz, a drugie, w dużej mierze, jest kwestią gustu. 
Ja wolę w Lispie rozdzielenie przestrzeni nazw (pomijając zupełnie 
kwestię kulawego systemu makr, który w jakimś stopniu wymusza takie 
podejście ; przy czym też wolę makra z Common Lispu niż ze Scheme).

> Mogę się zgodzić, że jest first class, więc mogłyby też być w tej samej
> przestrzeni nazw. Przekazywanie etykiet pośrednio jest zapewne tak
> rzadkie, że to, czy są w tej samej przestrzeni nazw, nie ma dużego
> znaczenia praktycznego i nie będę tutaj naciskał w żadną stronę.

Przekazywanie "return-from" ? Całkiem częste. Praktycznie nie ma innej 
możliwości złapania za kontynuację w CL'u.


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

[...]

Tak na marginesie - właśnie próbuję zdefiniować pewien nowy model 
współbierzności. Cała zabawa jest na poziomie semantycznym, ale używam 
dla wygody na wpół zdefiniowanego na papierze języka "funkcyjnego". W 
owym funkcyjnym języku nie ma w ogóle klasycznych funkcji - "funkcje" są 
płaskie i symetrycznie definiowalne - po prostu specyfikuje się, które 
"paramtery" w funkcji są wejściami, a które wyjściami (podobnie jak w 
Mercurym, lub typowanym Prologu, ale tutaj to pozostaje esencjalnie 
funkcją, a nie predykatem). Np. funkja Inc : Int -> Int u mnie ma typ 
Inc : Int x !Int i definiuje się mniej więcej tak:

Inc(x, y):
   Add(x, 1, y)


Zauważ, że teraz wszystkie pośrednie wyniki trzeba zapisywać w zmiennych 
(nie ma możliwości robienia jakichkolwiek kaskadowych składań ; na 
papierze czasami rysuję "rurki" przy komplementarnej parze wejść). To 
była raczej tylko konsekwencja wygody dla semantyki, ale koncepcja 
istnienia w języku tylko płaskich wołań jest całkiem interesująca.


mp

Dnia 19-05-2007, So o godzinie 15:56 +0200, Michał Przybyłek napisał(a):

> > To jest poboczny temat. Zaczęło się od mnogości nawiasów, która irytuje
> > mnie bardziej niż #' i funcall/apply.
> 
> Pierwszy raz o czymś takim piszesz, choć przeczuwałem ten stan rzeczy od 
> dłuższego czasu. Opowiedz mi o tym.

Nie jestem przekonany, czy tego chcesz. Taki flejm z reguły kończy się
stwierdzeniem, że różne są gusta.

Nawiasy najbardziej drażnią przy wprowadzaniu lokalnych zmiennych.
Dodanie zmiennej tam, gdzie do tej pory nie było żadnej zmiennej,
prowadzi do nieproporcjonalnie dużego narzutu składniowego (wcięcie
i objęcie dalszego ciągu nawiasami, sporo nawiasów w samym LET).
LET jest najbrzydszym elementem składni Lispa.

> Ale skoro Ty już go wyciągnąłeś, to może wyjaśnisz jednak jak 
> składnia Perlu wpasowuje się w Twoją filozofię, hm... ?

Też nie bronię składni Perla. Daję go tylko jako przykład świadczący
o tym, że powody ewentualnego wyróżniania funkcji nie są bardziej
fundamentalne niż powody ewentualnego wyróżniania tablic. To jest dość
arbitralna decyzja.

> Jeszcze raz Ci powtarzam, że funkcje są tak czy inaczej już wyróżnione 
> _syntaktycznie_. Tablice nie.

W Perlu tablice też są wyróżnione składniowo.

Zresztą to, że w jakiejś składni funkcja jest pod pewnym względem
wyróżniona składniowo, nie jest argumentem za tym, żeby wyróżniać ją
dodatkowo osobną przestrzenią nazw.

> Ale może skupmy się na jednym aspekcie - rysuj za każdym razem co 
> dokładnie zarzucasz temu podejściu - niespójność/nielogiczność, czy to, 
> że jest niewygodne.

Z reguły zarzucam, że jest niewygodne. Niespójność i nielogiczność
podnoszę kiedy kontruję argument, że inne rozwiązanie w przeciwieństwie
do mojego jest wyjątkowo spójne i logiczne.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk napisał(a):

>> Jeszcze raz Ci powtarzam, że funkcje są tak czy inaczej już wyróżnione 
>> _syntaktycznie_. Tablice nie.
> 
> W Perlu tablice też są wyróżnione składniowo.

W Lispie nie są. Obawiam się, że naprawdę ciężko Ci będzie zarzucić 
niespójność Lispu opierając się ledwie o niespójność Perla (już prędzej 
udało by Ci się w ten sposób udowodnić niespójność Koguta, jako, że on 
ma więcej wspólnego z Perlem niż Lisp ; szczególnie jeżeli chodzi o 
filozofię języka, to Lisp i Perl stoją na dwóch przeciwległych biegunach 
- reszta języków jest gdzieś pomiędzy).

> Zresztą to, że w jakiejś składni funkcja jest pod pewnym względem
> wyróżniona składniowo, nie jest argumentem za tym, żeby wyróżniać ją
> dodatkowo osobną przestrzenią nazw.

Nie jest argumentem.

Nie jest dodatkowym wyróżnieniem. Przestrzeń liniowo-topologiczna i 
przestrzeń topologiczna, to dwie różne rzeczy. Ciężko Ci będzie 
przepchnąć argument, że niekonsekwencją w matematyce jest to, że 
przekształcenia przestrzeni liniowo-topologicznych definiuje się inaczej 
niż przekształcenia przestrzeni topologicznych i inaczej niż zwykłe 
funkcje na zbiorach. Albo, że to "dodatkowo wyróżnia" przestrzeń 
topologiczną. Taka a nie inna definicja jest właśnie _konsekwencją_ 
różności, a nie dodatkową rzeczą pogłębiającą różność.

Raczej gdyby definicje przekształceń były takie same, to powinniśmy się 
pytać "dlaczego są takie same, skoro to różne rzeczy ? - ooo... jakie to 
dziwne".

No więc - dlaczego w Kogucie funkcje i zwykłe wartości siedzą w tym 
samym worku, skoro są czymś innym - mają inne własności i inaczej się 
ich używa ? Nie uważasz, że to trochę nielogiczne... ?

>> Ale może skupmy się na jednym aspekcie - rysuj za każdym razem co 
>> dokładnie zarzucasz temu podejściu - niespójność/nielogiczność, czy to, 
>> że jest niewygodne.
> 
> Z reguły zarzucam, że jest niewygodne. Niespójność i nielogiczność
> podnoszę kiedy kontruję argument, że inne rozwiązanie w przeciwieństwie
> do mojego jest wyjątkowo spójne i logiczne.

Dlaczego kontrujesz rzeczywistość ? Czy ona Ci coś złego wyrządziła ? 
Bądź miły dla rzeczywistości, to rzeczywistość będzie miła dla Ciebie :-)


mp

Marcin 'Qrczak' Kowalczyk napisał(a):

>>> To jest poboczny temat. Zaczęło się od mnogości nawiasów, która irytuje
>>> mnie bardziej niż #' i funcall/apply.
>> Pierwszy raz o czymś takim piszesz, choć przeczuwałem ten stan rzeczy od 
>> dłuższego czasu. Opowiedz mi o tym.
> 
> Nie jestem przekonany, czy tego chcesz. Taki flejm z reguły kończy się
> stwierdzeniem, że różne są gusta.

Nie, nie chcę jakiegokolwiek flejma.

Mnie zagadnienie ciekawi z punktu widzenia psychologicznego. Powiadasz, 
że Cię "irytuje mnogość nawiasów" w Lispie. Ale, prawda, nie piszesz w 
Lispie w ogóle. Zastanawia mnie jak często nachodzi Cię ta irytacja i 
rozdrażnienie (co później dodajesz) ? Od jak dawna ?

Pytam zupełnie serio. Mój jeden znajomy właśnie szuka tematu pracy 
doktorskiej z psychologii. Myślę, że dokładne opisanie tak ostrego 
przypadku parenthophobi, mogłoby być świetnym tematem. Na pewno 
pozwoliłoby to nam lepiej zrozumieć tę chorobę. Może nawet znaczący 
przełom nastąpiłby w diagnozowaniu i leczeniu. Zgodziłbyś się na 
współpracę ? Pomyśl jaka sława czeka. I ilu ludzi mogłoby przestać 
dzięki temu cierpieć !


mp

Michał Przybyłek napisał(a):

>>>> To jest poboczny temat. Zaczęło się od mnogości nawiasów, która irytuje
>>>> mnie bardziej niż #' i funcall/apply.
>>> Pierwszy raz o czymś takim piszesz, choć przeczuwałem ten stan rzeczy 
>>> od dłuższego czasu. Opowiedz mi o tym.
>>
>> Nie jestem przekonany, czy tego chcesz. Taki flejm z reguły kończy się
>> stwierdzeniem, że różne są gusta.
> 
> Nie, nie chcę jakiegokolwiek flejma.

Szczerze mówiąc nie mam nawet w tej chwili zbytnio czasu na dogłębną 
dyskusję. Prawdę mówiąc nawet już tego typu dyskusje niezbyt mnie 
podniecają (kiedyś było inaczej...). Mamy teraz ważniejsze problemy niż 
mulenie po raz kolejny tego, co zostało już przemulone tysiące razy 
przez ostatnich 50 lat.

Wszystko wygląda trochę tak jak gwałcenie, raz jeszcze, 
dziesięcioletniej kozy. Ani nie sprawia już przyjemności, ani nie 
przynosi pożytku (cóż, kiedyś nie tylko my, ale i też koza była młodsza...).

To co w tej chwili jest istotne, to zrozumienie istoty współbieżności i 
obliczeń kwantowych. I jedno i drugie mocno kuleje. Potrzebujemy dobrego 
modelu, chwytającego za logikę takich obliczeń. Jeżeli chcesz zrobić coś 
pożytecznego w kategorii języków programowania, to zabierz się za którąś 
z tych dwóch rzeczy. Chętnie podyskutuję :-)


mp

Dnia 19-05-2007, So o godzinie 23:05 +0200, Michał Przybyłek napisał(a):

> szczególnie jeżeli chodzi o 
> filozofię języka, to Lisp i Perl stoją na dwóch przeciwległych
> biegunach 
> - reszta języków jest gdzieś pomiędzy).

Etam. Po pierwsze to Scheme i Perl jeśli już, a Common Lisp jest
pomiędzy nimi. Po drugie to jest zbytnie uproszczenie: na oko Lisp
i Perl są do siebie bardziej podobne niż Haskell do któregokolwiek
z nich.

> No więc - dlaczego w Kogucie funkcje i zwykłe wartości siedzą w tym 
> samym worku, skoro są czymś innym - mają inne własności i inaczej się 
> ich używa ?

Funkcje są zwykłymi wartościami. Nie można używać czegoś inaczej niż
tego samego.

Każdą wartość można przekazać jako argument każdej innej wartości. Każdą
wartość można spróbować zaaplikować do argumentów. Czasem efektem będzie
rzucenie nieciekawego wyjątku, ale z formalnego punktu widzenia funkcje
nie mają specjalnych własności.

> Mnie zagadnienie ciekawi z punktu widzenia psychologicznego. Powiadasz,
> że Cię "irytuje mnogość nawiasów" w Lispie. Ale, prawda, nie piszesz
> w Lispie w ogóle.

Prawie nie piszę, ale nieprawda, że nie piszę w ogóle. Napisałem
kogut-mode.el do Emacsa.

Zdarzyło się ze dwa razy, że po reorganizacji kodu M-x check-parens
nie pokazało błędu, ale nawiasy były nie w tym miejscu co trzeba
i kod źle działał.

> Zastanawia mnie jak często nachodzi Cię ta irytacja i rozdrażnienie
> (co później dodajesz) ?

Kiedy oglądam kod w Lispie. Czyli średnio raz na parę tygodni.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk napisał(a):

> Prawie nie piszę, ale nieprawda, że nie piszę w ogóle. Napisałem
> kogut-mode.el do Emacsa.

To nie Lisp tylko Emacs Lisp. Okropne okropieństwo.

A możesz podać linka, albo wrzucić mi to na konto (mrp@...) ? Ciekaw 
jestem jak to napisałeś. Nie, nie chcę komentować, po prostu mnie 
ciekawi :-)

>> Zastanawia mnie jak często nachodzi Cię ta irytacja i rozdrażnienie
>> (co później dodajesz) ?
> 
> Kiedy oglądam kod w Lispie. Czyli średnio raz na parę tygodni.

Damn... też się starzejesz. Co za spokojne i opanowane odpowiedzi :-)


mp

Dnia 20-05-2007, N o godzinie 00:40 +0200, Michał Przybyłek napisał(a):

> To nie Lisp tylko Emacs Lisp. Okropne okropieństwo.

Pod względem stosowania nawiasów jest niemal równoważny Common Lispowi.
Najbardziej widoczna różnica to niesymetryczny if.

> A możesz podać linka,

http://kokogut.cvs.sourceforge.net/kokogut/kokogut/kogut-mode.el?view=markup

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/