🚀 go-pugleaf

On 12 Maj, 01:44, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Użytkownik "ethouris" <ethou...@gmail.com> napisał w wiadomości
>
> > > PS: Jezykiem beztypowym to jest np Tcl.
> > >       Tam wszystko jest stringiem.
> > Bzdura.
>
> > Język Tcl jak najbardziej posiada typy (z tym tylko, że w zakresie
> > języka nie można tworzyć własnych). Zasada EIAS tak naprawdę polega
> > tylko na tym, że każdy obiekt Tcl-owy (a więc należący do jednego z
> > Tcl-owych typów) jest automatycznie serializowalny, tzn. zawsze może
> > być przekonwertowany na string i odwrotnie.
> > No i oczywiście nie można
> > tych typów jawnie weryfikować w programach.
>
> Taaa, nie moge tworzyc nie moge werifikowac, w ogole ich
> nie widze
> No to gdzie te typy ?

Typy nie powodują, że możesz je widzieć, tylko że określone operacje
różnią się w zależności od tego typu. Nikt nie powiedział, że masz
mieć możliwość nazwania tych typów, czy też pobrania z danego obiektu
informacji o tym, jakiego ten obiekt jest typu. Proponuję zrobić sobie
małą powtórkę z podstawowych wiadomości o programowaniu.

To tak po pierwsze dla ustalenia uwagi.

> Sektor przestan prosze pierdzielic od rzeczy.
> Typow w Tclu nie ma i nie bylo nigdy.

Trochę nie do końca.

> W Tclu _wszytsko_ jest stringiem

Obiekty klas zdefiniowanych za pomocą biblioteki Itcl również?

> i gadanie o jakis
> wewnetrznych optymalizacjach majacych na celu
> poprawe szybkosci swoistego _autointerpretera_
>  jakim jest Tcl to jawne wprowadzanie ludzi w blad.
> Nawet te optymalizacyjne zabiegi sa dopiero od Tcl8.0
> a w Tcl7.6 ich jeszcze nie bylo.

Zgadza się, ale to nie zmienia faktu, że są od 8.0.

> Natomiast Tcl7.6 i 8 sa zgodne w sensie jezyka.

Bzdura. 8.0 jest wstecznie zgodny z 7.6, nic ponad to.

Przykładowo, w Tcl 7.6 wyrażenie expr { "s" == "s" } powodowało
wyjątek. W 8.0 normalnie zwraca true. To ma być twoim zdaniem zgodność
w sensie języka?

A w jaki cudowny sposób operator == wie, którą wersję porównania ma
wybrać dla argumentów, skoro - jak twierdzisz - w Tcl-u nie ma typów?

Inna sprawa - w jaki sposób komenda incr sprawdza, czy czasem wartość
zmiennej do inkrementacji nie jest zmiennoprzecinkowa?

> > Aczkolwiek jest to zupełnie niepotrzebne, bo w Tcl-u si
> > ę po prostutego nie robi.
>
> Nie robi sie bo sie po prostu nie da.

No fakt, że się nie da, bo nie zrobiono mechanizmów, które by na to
pozwalały, tylko pytanie - po co one miałyby istnieć.

> Ni ma na czym badac tego typu.

Jest na czym. Na obiektach. Tylko nie ma po co.

Typy są badane przez operacje wykonywane wewnętrznie. I to wystarczy.
Zawsze można z nich skorzystać.

Faktem jest, że jeśli np. w zmiennej powstanie nagle wartość, która
może być wartością określonego typu, to dostaje taki właśnie typ. W
związku z tym, wartość 0x10 będzie zawsze typu integer, nawet jeśli
powstała przez "set x {0x}; append x 10".

Typ nie oznacza jakiegoś magicznego identyfikatora przypisanego
określonemu obiektowi, tylko charakterystykę sposobu przeprowadzania
na nim operacji lub niemożności ich przeprowadzenia.

> > Jeśli np. potrzebujemy wykonać operację dodawania na
> > dwóch wartościach, a jedna z nich jest stringiem nie konwertowalnym na
> > liczbę, to leci wyjątek (note: odmiennie, niż np. w Perlu, w którym
> > "jeden" == "dwa" zwraca true).
>
> Ta , leci wyjatek bo parserek czyli komenda [expr ]
> nie umie zewaluowac argumentu.

Jeśli mówimy o takim wyrażeniu jak { $p+2 }, to ów "parserek"
zadziałał już dawno, w momencie gdy ostatni raz nadawano wartość
zmennej p. W takim przypadku sprawa jest prosta - próbuje się wykonać
operację + na $p i 2, gdzie $p nie jest typu integer ani float.

> Ten argument jest jednak zwyklym stringiem.

Ten argument jest obiektem Tcl-owym, który co najwyżej posiada
zapamiętaną ostatnią reprezentację jako string (bo ma ją każdy
obiekt). Reprezentacja ta jest jednak produkowana na nowo, jeśli
zmieniono wartość w sposób zgodny z typem tego obiektu, a nie żądano
dotychczas odczytu stringa z tego obiektu (bo i nie zawsze się żąda:
wyrażenie expr nie żąda, wyrażenie [list] również nie żąda).

> Nie ma tak zadnego tworzenia obiektow typu int long
> string itp.

String jest dla Tcl-a czymś w rodzaju "typu ortogonalnego": można nim
reprezentować wartość każdego obiektu Tcl-owego. I poza tym jest jeden
tylko typ całkowity (bo nie rozumiem, po co miałoby być więcej w
języku skryptowym).

> Po prostu jest zwykle parsowanie _stringu_
> Bo w Tcl _wszytsko_ jest stringiem.

Nie jest to już prawda od Tcl-a 8.0

> > ale i w takim języku nie widzę koniecznej potrzeby posiadania
> > możliwości sprawdzania typu.
>
> Sektor prestan truc juz bez sensu.
> W jezykach bez statyvznej kontrolo typow trzeba
> _szczegolnie_ o ta kontrole zadbac.

W języku bez statycznej kontroli typów żadna kontrola typów nie ma
sensu. Język taki należy traktować tak samo, jak beztypowy. Jeśli
chcemy wykonać operację, to wykonujemy ją; jeśli ona miałaby się nie
udać, to rzuci wyjątek.

A jeśli takie reguły języka powodują, że nie da się w nim pisać dużych
aplikacji - cóż, niektórzy odkryli to już wiele lat wcześniej.

> Tu masz przyklad z brzegu:
>
> @docstring(a="frobination count")
> @typechecker(a=Number, b=Number, _return=Number)
> @constrain_values(a=range(3,9), b=[4,8,12])
> def  foo(a, b):
>      # the code

I to @typechecker(a=Number, b=Number, _return=Number) ma być lepsze od
hipotetycznego takiego podejścia?:

def Number foo( Number a, Number b ):
   # the code

Adamie nie rozśmieszaj mnie.

Różnica nie polega na tym, że ludzie chętnie używają tylko tego, czego
używać muszą i używa się łatwo i naturalnie. Czymś takim właśnie jest
statyczna kontrola typów w C++ i niestety to jest jeden z powodów, dla
których C++ zbiera cięgi od zwolenników odśmiecania, czy też
rezygnacji właścicielstwa do obiektów: T* pisze się łatwiej, niż
shared_ptr<T>.

Więc jeśli chcesz mi powiedzieć, że tego typu rzeczy staną się
kiedykolwiek dominującą w świecie Pythona metodą na weryfikację typów,
to jesteś po prostu niepoprawnym optymistą.

> > W języku skryptowym przykładowo mogę mieć
> > "coś" pobrane z jakiegoś źródła i nie interesuje mnie czy w postaci
> > liczby całkowitej, czy stringa, ale interesuje mnie jednak, czy to, co
> > dostałem, to liczba.
> [...]
> > Sprawdzam tylko czy [string is integer $liczba] i to mi
> > wystarczy.
>
> Taaa.
> Czyli sobie zapuszacm znow parserek i sobie patrze czy
> sie wywalil.

Parserek był tam zapuszczony już dawno temu. To, co sprawdza [string
is integer], to typ obiektu.

> Jesli sie nei wypierdzielil na [exp $x + 0] to znaczy ze liczba
> No ooo w sumie mozna :)

Tak też, owszem, można - chociaż stosowałbym to rozwiązanie tylko w
razie braku wyboru, czyli gdybym nie miał [string is integer].