Fix some typos

Author: adam-wyluda

pl/tutorials/tour/abstract-types.md

@@ -76,4 +76,4 @@ object AbstractTypeTest2 extends App {
 }
 ```
 
-Należy też pamiętać o tym, żeby zastosować [adnotacji wariancji](variance.html). Inaczej nie byłoby możliwe ukrycie konkretnego typu sekwencji obiektu zwracanego przez metodę `newIntSeqBuf`.
+Należy też pamiętać o zastosowaniu [adnotacji wariancji](variance.html). Inaczej nie byłoby możliwe ukrycie konkretnego typu sekwencji obiektu zwracanego przez metodę `newIntSeqBuf`.

pl/tutorials/tour/annotations.md

@@ -36,8 +36,8 @@ Znaczenie adnotacji jest zależne od implementacji. Na platformie Java, poniższ
 
 W poniższym przykładzie dodajemy adnotację `throws` do definicji metody `read` w celu obsługi rzuconego wyjątku w programie w Javie.
 
-> Kompilator Javy sprawdza czy program zawiera obsługę dla [wyjątków kontrolowanych](http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html) poprzez sprawdzenie które wyjątki mogą być wynikiem wykonania metody lub konstruktora. Dla każdego kontrolowanego wyjątki który może być wynikiem wykonania, adnotacja **throws** musi określić klasę tego wyjątku lub jedną z jej klas bazowych.
-> Ponieważ Scala nie pozwala na definiowanie wyjątków kontrolowanych, jeżeli chcemy móc obsłużyć wyjątek z kodu w Scali w Javie, należy dodać jedną lub więcej adnotacji `throws` określające klasy wyjątek przez nią rzucanych.
+> Kompilator Javy sprawdza czy program zawiera obsługę dla [wyjątków kontrolowanych](http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html) poprzez sprawdzenie, które wyjątki mogą być wynikiem wykonania metody lub konstruktora. Dla każdego kontrolowanego wyjątku który może być wynikiem wykonania, adnotacja **throws** musi określić klasę tego wyjątku lub jedną z jej klas bazowych.
+> Ponieważ Scala nie pozwala na definiowanie wyjątków kontrolowanych, jeżeli chcemy obsłużyć wyjątek z kodu w Scali w Javie, należy dodać jedną lub więcej adnotacji `throws` określającej klasy wyjątków przez nią rzucanych.
 
 ```
 package examples
@@ -106,7 +106,7 @@ Zastosowanie adnotacji w Scali wygląda podobnie jak wywołanie konstruktora, gd
 class MyScalaClass ...
 ```
 
-Składnia ta może się wydawać nieco nadmiarowa, jeżeli adnotacja składa się tylko z jednego elmentu (bez wartości domyślnej), zatem jeżeli nazwa pola jest określona jako `value`, może być ona stosowana w Javie stosując składnię podobną do konstruktora:
+Składnia ta może się wydawać nieco nadmiarowa, jeżeli adnotacja składa się tylko z jednego elementu (bez wartości domyślnej), zatem jeżeli nazwa pola jest określona jako `value`, może być ona stosowana w Javie stosując składnię podobną do konstruktora:
 
 ```
 @interface SourceURL {

pl/tutorials/tour/automatic-closures.md

@@ -54,7 +54,7 @@ object TargetTest2 extends App {
 }
 ```
 
-Funkcja `loop` przyjmuje ciało pętli oraz zwraca instancję klasy `LoopUnlessCond` (która enkapsuluje to ciało). Warto zwrócić uwagę, że ciało tej funkcji nie zostało jeszcze ewaluowane. Klasa `LoopUnlessCond` posiada metodę `unless` którą możemy wykorzystać jako *operator infiksowy*. W ten sposób, uzyskaliśmy całkiem naturalną składnię dla naszej nowej pętli: `loop { < stats > } unless ( < cond > )`.
+Funkcja `loop` przyjmuje ciało pętli oraz zwraca instancję klasy `LoopUnlessCond` (która enkapsuluje to ciało). Warto zwrócić uwagę, że ciało tej funkcji nie zostało jeszcze ewaluowane. Klasa `LoopUnlessCond` posiada metodę `unless`, którą możemy wykorzystać jako *operator infiksowy*. W ten sposób, uzyskaliśmy całkiem naturalną składnię dla naszej nowej pętli: `loop { < stats > } unless ( < cond > )`.
 
 Oto wynik działania programu `TargetTest2`:
 

pl/tutorials/tour/compound-types.md

@@ -13,7 +13,7 @@ tutorial-previous: abstract-types
 
 Czasami konieczne jest wyrażenie, że dany typ jest podtypem kilku innych typów. W Scali wyraża się to za pomocą *typów złożonych*, które są częścią wspólną typów obiektów.
 
-Załóżmy że mamy dwie cechy `Cloneable` i `Resetable`:
+Załóżmy, że mamy dwie cechy `Cloneable` i `Resetable`:
 
 ```tut
 trait Cloneable extends java.lang.Cloneable {

pl/tutorials/tour/default-parameter-values.md

@@ -11,7 +11,7 @@ tutorial-next: named-parameters
 tutorial-previous: annotations
 ---
 
-Scala zezwala na określenie domyślnych wartości dla parametrów co pozwala wyrażeniu wywołującemu ją na pominięcie tych parametrów.
+Scala zezwala na określenie domyślnych wartości dla parametrów, co pozwala wyrażeniu wywołującemu ją na pominięcie tych parametrów.
 
 W Javie powszechną praktyką jest definiowanie implementacji metod, które służa wyłącznie określeniu domyślnych wartości dla pewnych parametrów dużych metod. Najczęściej stosuje się to w konstruktorach:
 
@@ -30,7 +30,7 @@ public class HashMap<K,V> {
 
 Mamy tutaj do czynienia tylko z dwoma konstruktorami. Pierwszy przyjmuje inną mapę, a drugi wymaga podania pojemności i load factor. Trzeci oraz czwarty konstruktor pozwala użytkownikom `HashMap` na tworzenie instancji z domyślnymi wartościami tych parametrów, które są prawdopodobnie dobre w większości przypadków.
 
-Bardziej problematyczne jest to, że domyślne wartości są zarówno w Javadoc oraz w kodzie. Łatwo można zapomnieć o odpowiedniej aktualizacji tych wartości. Powszechnym wzorcem jest utworzenie publicznych stałych których wartości pojawią się w Javadoc:
+Bardziej problematyczne jest to, że domyślne wartości zapisane są zarówno w Javadoc oraz w kodzie. Można łatwo zapomnieć o odpowiedniej aktualizacji tych wartości. Dlatego powszechnym wzorcem jest utworzenie publicznych stałych, których wartości pojawią się w Javadoc:
 
 ```java
 public class HashMap<K,V> {
@@ -53,7 +53,7 @@ Mimo że powstrzymuje to nas od powtarzania się, to podejście nie jest zbyt wy
 Scala wprowadza bezpośrednie wsparcie dla domyślnych parametrów:
 
 ```tut
-class HashMap[K,V](initialCapacity:Int = 16, loadFactor:Float = 0.75f) {
+class HashMap[K,V](initialCapacity: Int = 16, loadFactor: Float = 0.75f) {
 }
 
 // Używa domyślnych wartości

pl/tutorials/tour/explicitly-typed-self-references.md

@@ -28,7 +28,7 @@ abstract class Graph {
 }
 ```
 
-Grafy składają się z listy węzłów oraz krawędzi, gdzie zarówno typ węzłą jak i krawędzi są abstrakcyjne. Użycie [typów abstrakcyjnych](abstract-types.html) pozwala implementacjom cechy `Graph` na to by określały swoje konkretne klasy dla węzłów i krawędzi. Ponadto istnieje tutaj metoda `addNode`, której celem jest dodanie nowych węzłów do grafu. Węzły są połączone z użyciem metody `connectWith`.
+Grafy składają się z listy węzłów oraz krawędzi, gdzie zarówno typ węzła jak i krawędzi jest abstrakcyjny. Użycie [typów abstrakcyjnych](abstract-types.html) pozwala implementacjom cechy `Graph` na to, by określały swoje konkretne klasy dla węzłów i krawędzi. Ponadto graf zawiera metodę `addNode`, której celem jest dodanie nowych węzłów do grafu. Węzły są połączone z użyciem metody `connectWith`.
 
 Przykład implementacji klasy `Graph`:
 
@@ -62,7 +62,7 @@ Klasa `DirectedGraph` częściowo implementuje i jednocześnie specjalizuje klas
 
 Ponieważ konieczne jest udostępnienie możliwości tworzenia wierzchołków i krawędzi w naszej częściowej implementacji grafu, dodane zostały metody fabrykujące `newNode` oraz `newEdge`. Metody `addNode` wraz z `connectWith` są zdefiniowane na podstawie tych metod fabrykujących.
 
-Jeżeli przyjrzymy się bliżej implementacji metody `connectWith`, możemy dostrzec że tworząc krawędź, musimy przekazać samoreferencję `this` do metody fabrykującej `newEdge`. Lecz `this` jest już powązany z typem `NodeImpl`, który nie jest kompatybilny z typem `Node` ponieważ jest on tylko ograniczony z góry typem `NodeImpl`. Wynika z tego, iż powyższy program nie jest prawidłowy i kompilator Scali wyemituje błąd kompilacji.
+Jeżeli przyjrzymy się bliżej implementacji metody `connectWith`, możemy dostrzec, że tworząc krawędź, musimy przekazać samoreferencję `this` do metody fabrykującej `newEdge`. Lecz `this` jest już powązany z typem `NodeImpl`, który nie jest kompatybilny z typem `Node`, ponieważ jest on tylko ograniczony z góry typem `NodeImpl`. Wynika z tego, iż powyższy program nie jest prawidłowy i kompilator Scali wyemituje błąd kompilacji.
 
 Scala rozwiązuje ten problem pozwalając na powiązanie klasy z innym typem poprzez jawne typowanie samoreferencji. Możemy użyć tego mechanizmu, aby naprawić powyższy kod:
 
@@ -93,9 +93,9 @@ Scala rozwiązuje ten problem pozwalając na powiązanie klasy z innym typem pop
     }
 ```
 
-W nowej definicji klasy `NodeImpl` referencja `this` jest typu `Node`. Ponieważ typ `Node` jest abstrakcyjny i stąd nie wiemy jeszczy, czy `NodeImpl` w rzeczywistości odpowiada `Node`, system typów w Scali nie pozwoli nam na utworzenie tego typu. Mimo wszystko za pomocą jawnej adnotacji typu stwierdzamy, że w pewnym momencie klasa pochodna od `NodeImpl` musi odpowiadać typowi `Node` aby dało się ją utworzyć.
+W nowej definicji klasy `NodeImpl` referencja `this` jest typu `Node`. Ponieważ typ `Node` jest abstrakcyjny i stąd nie wiemy jeszcze, czy `NodeImpl` w rzeczywistości odpowiada `Node`, system typów w Scali nie pozwoli nam na utworzenie tego typu. Mimo wszystko za pomocą jawnej adnotacji typu stwierdzamy, że w pewnym momencie klasa pochodna od `NodeImpl` musi odpowiadać typowi `Node`, aby dało się ją utworzyć.
 
-Oto konkretna specjalizacja `DirectedGraph`, gdzie abstrakcyjne elementy klasy mają ustalone konkretne znaczenie:
+Oto konkretna specjalizacja `DirectedGraph`, gdzie abstrakcyjne elementy klasy mają ustalone ścisłe znaczenie:
 
 ```tut
 class ConcreteDirectedGraph extends DirectedGraph {
@@ -107,7 +107,7 @@ class ConcreteDirectedGraph extends DirectedGraph {
 }
 ```
 
-Należy dodać, że w tej klasie możemy utworzyć `NodeImpl` ponieważ wiemy już teraz, że `NodeImpl` określa klasę pochodną od `Node` (która jest zwyczajnie aliasem dla `NodeImpl`).
+Należy dodać, że w tej klasie możemy utworzyć `NodeImpl`, ponieważ wiemy już teraz, że `NodeImpl` określa klasę pochodną od `Node` (która jest po prostu aliasem dla `NodeImpl`).
 
 Poniżej przykład zastosowania klasy `ConcreteDirectedGraph`:
 

pl/tutorials/tour/higher-order-functions.md

@@ -11,7 +11,7 @@ tutorial-next: nested-functions
 tutorial-previous: anonymous-function-syntax
 ---
 
-Scala pozwala na definicję funkcji wyższego rzędu. Są to funkcje, które przyjmują funkcje jako parametry lub których wynik jest też funkcją. Poniżej znajduje się przykład funkcji `apply` który pobiera inną funkcję `f` i wartość `v`, po to by zwrócić wynik zastosowania `f` do `v`:
+Scala pozwala na definiowanie funkcji wyższego rzędu. Są to funkcje, które przyjmują funkcje jako parametry lub których wynik jest też funkcją. Poniżej znajduje się przykład funkcji `apply` który pobiera inną funkcję `f` i wartość `v`, po to by zwrócić wynik zastosowania `f` do `v`:
 
 ```tut
 def apply(f: Int => String, v: Int) = f(v)
@@ -39,4 +39,4 @@ Wykonanie zwraca poniższy wynik:
 [7]
 ```
 
-W tym przykładzie, metoda `decorator.layout` jest automatycznie konwertowana do funkcji typu `Int => String` czego wymaga funkcja `apply`. Warto dodać, że metoda `decorator.layout` jest polimorficzna, co oznacza, że jej sygnatura jest odpowiednio dopasowana przez kompilator, dzięki czemu gdy jest przekazana do funkcji `apply`, jest ona traktowana jako `Int => String`.
+W tym przykładzie, metoda `decorator.layout` jest automatycznie konwertowana do funkcji typu `Int => String`, czego wymaga funkcja `apply`. Warto dodać, że metoda `decorator.layout` jest polimorficzna, co oznacza, że jej sygnatura jest odpowiednio dopasowana przez kompilator, dzięki czemu gdy jest przekazana do funkcji `apply`, jest ona traktowana jako `Int => String`.

pl/tutorials/tour/implicit-conversions.md

@@ -19,7 +19,7 @@ Konwersje implicit są stosowane w dwóch sytuacjach:
 * W przypadku wyboru `e.m` z `e` typu `T`, jeżeli `m` nie jest elementem `T`.
 
 W pierwszym przypadku wyszukiwana jest konwersja `c`, którą można zastosować do `e` aby uzyskać wynik typu `T`.
-W drugim przypadku wyszukiwana jest konwersja `c`, którą można zastosować do `e` i której wyniki zawiera element nazwany `m`.
+W drugim przypadku wyszukiwana jest konwersja `c`, którą można zastosować do `e` i której wynik zawiera element nazwany `m`.
 
 Poniższa operacja na dwóch listach `xs` oraz `ys` typu `List[Int]` jest dopuszczalna:
 

pl/tutorials/tour/implicit-parameters.md

@@ -11,7 +11,7 @@ tutorial-next: implicit-conversions
 tutorial-previous: explicitly-typed-self-references
 ---
 
-Metodę z _parametrami implicit_ można stosować tak samo jak zwyczajną metod. W takim przypadku etykieta `implicit` nie ma żadnego znaczenia. Jednak jeżeli odpowiednie argumenty dla parametrów implicit nie zostaną jawnie określone, to kompilator dostarczy je automatycznie.
+Metodę z _parametrami implicit_ można stosować tak samo jak zwyczajną metodę. W takim przypadku etykieta `implicit` nie ma żadnego znaczenia. Jednak jeżeli odpowiednie argumenty dla parametrów implicit nie zostaną jawnie określone, to kompilator dostarczy je automatycznie.
 
 Argumenty które mogą być przekazywane jako parametry implicit można podzielić na dwie kategorie:
 
@@ -39,7 +39,7 @@ object ImplicitTest extends App {
     def add(x: Int, y: Int): Int = x + y
     def unit: Int = 0
   }
-  /** Metoda sum pobiera List[A] i zwraca A, który jest wynikiem zastosowania zastosowania monoidu do wszystkich kolejnych elementów listy. Oznaczając parametr m jako implicit sprawiamy, że potrzebne jest tylko podanie parametru xs podczas wywołania, ponieważ mamy już List[A], zatem wiemy jakiego typue jest w rzeczywistości A, zatem wiemy też jakiego typu Monoid[A] jest potrzebny. Możemy więc wyszukać wartość val lub obiekt w aktualnym zasięgu, który ma odpowiadający typu i użyć go bez jawnego określania referencji do niego. */
+  /** Metoda sum pobiera List[A] i zwraca A, który jest wynikiem zastosowania zastosowania monoidu do wszystkich kolejnych elementów listy. Oznaczając parametr m jako implicit sprawiamy, że potrzebne jest tylko podanie parametru xs podczas wywołania, ponieważ mamy już List[A], zatem wiemy jakiego typu jest w rzeczywistości A, zatem wiemy też jakiego typu Monoid[A] jest potrzebny. Możemy więc wyszukać wartość val lub obiekt w aktualnym zasięgu, który ma odpowiadający typu i użyć go bez jawnego określania referencji do niego. */
   def sum[A](xs: List[A])(implicit m: Monoid[A]): A =
     if (xs.isEmpty) m.unit
     else m.add(xs.head, sum(xs.tail))

pl/tutorials/tour/inner-classes.md

@@ -45,7 +45,7 @@ object GraphTest extends App {
 }
 ```
 
-Teraz wzbogacimy nasz przykład o jawne typowanie aby można było zobaczyć powiązanie typów wierzchołków z grafem:
+Teraz wzbogacimy nasz przykład o jawne typowanie, aby można było zobaczyć powiązanie typów wierzchołków z grafem:
 
 ```tut
 object GraphTest extends App {
@@ -74,7 +74,7 @@ object IllegalGraphTest extends App {
 }
 ```
 
-Warto zwrócić uwagę na to, że ostatnia linia poprzedniego przykłady byłaby poprawnym programem w Javie. Dla wierzchołków obu grafów Java przypisałaby ten sam typ `Graph.Node`. W Scali także istnieje możliwość wyrażenia takiego typu, zapisując go w formie: `Graph#Node`. Jeżeli byśmy chcieli połączyć wierzchołki różnych grafów, musielibyśmy wtedy zmienić definicję implementacji naszego grafu w następujący sposób:
+Warto zwrócić uwagę na to, że ostatnia linia poprzedniego przykładu byłaby poprawnym programem w Javie. Dla wierzchołków obu grafów Java przypisałaby ten sam typ `Graph.Node`. W Scali także istnieje możliwość wyrażenia takiego typu, zapisując go w formie: `Graph#Node`. Jeżeli byśmy chcieli połączyć wierzchołki różnych grafów, musielibyśmy wtedy zmienić definicję implementacji naszego grafu w następujący sposób:
 
 ```tut
 class Graph {

pl/tutorials/tour/local-type-inference.md

@@ -31,7 +31,7 @@ object InferenceTest2 {
 }
 ```
 
-Nie jest też konieczne określenie parametrów typu, kiedy są wywoływanie [metody polimorficzne](polymorphic-methods.html) lub kiedy tworzymy [klasy generyczne](generic-classes.html). Kompilator Scali sam określi typ brakujących parametrów typów na podstawie kontekstu oraz typów właściwych parametrów metody/konstruktora.
+Nie jest też konieczne określenie parametrów typu, kiedy są wywoływane [metody polimorficzne](polymorphic-methods.html) lub kiedy tworzymy [klasy generyczne](generic-classes.html). Kompilator Scali sam określi typ brakujących parametrów typów na podstawie kontekstu oraz typów właściwych parametrów metody/konstruktora.
 
 Oto przykład który to ilustruje:
 

pl/tutorials/tour/singleton-objects.md

@@ -49,7 +49,7 @@ Bardzo powszechne jest użycie wzorca typeclass w połączeniu z [wartościami i
 
 ## Uwagi dla programistów Javy ##
 
-`static` nie jest słowem kluczowym w Scali. Zamiast tego, wszyskie elementy, które powinny być statyczne (wliczając w to klasy) powinny zostać zamieszczone w obiekcie singleton.
+`static` nie jest słowem kluczowym w Scali. Zamiast tego, wszystkie elementy, które powinny być statyczne (wliczając w to klasy) powinny zostać zamieszczone w obiekcie singleton.
 
 Często spotykanym wzorcem jest definiowanie statycznych elementów, np. jako prywatne, pomocniczo dla ich instancji. W Scali przenosi się je do obiektu companion:
 

pl/tutorials/tour/variances.md

@@ -13,7 +13,7 @@ tutorial-previous: generic-classes
 
 Scala wspiera adnotacje wariancji parametrów typów [klas generycznych](generic-classes.html). W porównaniu do Javy, adnotacje wariancji mogą zostać dodane podczas definiowania abstrakcji klasy, gdy w Javie adnotacje wariancji są podane przez użytkowników tych klas.
 
-Na stronie o [klasach generycznych](generic-classes.html) omówiliśmy przykład zmiennego stosu. Wyjaśniliśmy, że typ definiowany przez klasę `Stack[T]` jest poddany niezmiennemu podtypowaniu w stosunku do parametru typu. Może to ograniczyć możliwość ponownego wykorzystania abstrakcji tej klasy. Spróbujemy teraz opracować funkcyjną (tzn. immutable) implementację dla stosów, które nie posiadają tego ograniczenia. Warto zwrócić uwagę na to, że jest to zaawansowany przykład łączący w sobie zastosowanie [funkcji polimorficznych](polymorphic-methods.html), [dolnych ograniczeń typu](lower-type-boudns.html) oraz kowariantnych adnotacji parametru typu. Dodatkowo stosujemy też [klasy wewnętrzne](inner-classes.html) aby połączyć ze sobą elementy stosu bez jawnych powiązań.
+Na stronie o [klasach generycznych](generic-classes.html) omówiliśmy przykład zmiennego stosu. Wyjaśniliśmy, że typ definiowany przez klasę `Stack[T]` jest poddany niezmiennemu podtypowaniu w stosunku do parametru typu. Może to ograniczyć możliwość ponownego wykorzystania abstrakcji tej klasy. Spróbujemy teraz opracować funkcyjną (tzn. immutable) implementację dla stosów, które nie posiadają tego ograniczenia. Warto zwrócić uwagę na to, że jest to zaawansowany przykład łączący w sobie zastosowanie [funkcji polimorficznych](polymorphic-methods.html), [dolnych ograniczeń typu](lower-type-bounds.html) oraz kowariantnych adnotacji parametru typu. Dodatkowo stosujemy też [klasy wewnętrzne](inner-classes.html), aby połączyć ze sobą elementy stosu bez jawnych powiązań.
 
 ```tut
 class Stack[+A] {