PDXScala Meeting! Wednesday, 6PM @ Janrain
16 views
Skip to first unread message
Thomas Lockney
May 7, 2013, 7:39:56 PM5/7/13
to pdxscala
Hey folks, it's that time again. We'll have some great beginner friend material courtesy of Rob Norris along with time for general questions and answers for any one who's just getting started with Scala and wants to know how more experienced Scala developers might do things. In addition, Kevin Scaldeferri will be giving a bit of a preview of the material for the talk he'll be giving at Lambdajam (http://lambdajam.com/sessions#scaldeferri) later this summer, covering
"using the cake pattern to bridge the divide between unit testing and functional testing." We'll have pizza and we welcome attendees whether you're deep in the Scala world or just passing by and wanting to see what all this functional programming in the OO world is about.
We look forward to seeing you!
Dave Rostron
May 9, 2013, 1:34:45 PM5/9/13
to pdxs...@googlegroups.com
Per Thomas's mention at the meeting.
Until you have some time to read Concepts, Techniques, and Models of Computer Programming the following is a good primer.
Programming Paradigms for Dummies: What Every Programmer Should Know, Peter Van Roy
--
You received this message because you are subscribed to the Google Groups "pdxscala" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdxscala+u...@googlegroups.com.
To post to this group, send email to pdxs...@googlegroups.com.
Visit this group at http://groups.google.com/group/pdxscala?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Phil Tomson
May 9, 2013, 1:42:21 PM5/9/13
to pdxs...@googlegroups.com
Enjoyed the meeting last night. Thanks for the newbie presentation.
Also, other resources that were mentioned:
"Scala for the Impatient" was mentioned as a good book for newbies: http://www.amazon.com/Scala-Impatient-Cay-S-Horstmann/dp/0321774094/ref=sr_1_1?ie=UTF8&qid=1368121161&sr=8-1&keywords=scala+for+the+impatient
Talk from NEScala on the cake pattern: http://nescala.org/#keynote
And another blog entry on the Cake pattern: http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di/
Phil
Thomas Lockney
May 9, 2013, 3:07:00 PM5/9/13
to pdxscala
Just for historical interest I thought I'd mention that the post from Jonas Boner's blog is actually the original post that's usually cited about the cake pattern. While the post makes it sound like the pattern had already been around and discussed for a while, I've never found an earlier example or reference to it (though I haven't tried hard).
Also, thanks again to everyone who came out and thanks especially to Rob and Kevin for their talks. We'll have more beginner friendly stuff going forward since there was such a positive response to it.
Last, but not least, this is mostly for Phil or anyone else who's also interested in Ocaml, I found this rather interesting comparison of Scala and Ocaml functionality: http://langref.org/ocaml+scala/all (the website this is on looks interesting in general).
Leif Warner
May 9, 2013, 4:12:20 PM5/9/13
to pdxs...@googlegroups.com
Yeah, those were some great talks last night.
I wanted to offer a sort of mea culpa: When, during Rob's talk while we were discussion typeclasses, and I said in def blah[A: Foo](a:A) = ..., the A: Foo relationship can be thought of as being analogous to the 5: Int relationship, I was being excesively hand-wavey, as I often am.
The proper thing at that space in the relationship would be kinds.
Kinds are to types as types are to values. The kind of Int is Type (or maybe in Scala parlance, Class?), and the kind of Option is Type => Type (Class[_]?)
So, in some made-up notation:
5 : Int
Int : Class
Option : Class[_]
Either : Class[_, _]
By the underscores, I just mean that Option isn't a "concrete" type the way Int is - it has to be applied to another type for that. One place where this is useful is in defining typeclasses. E.g. Monads are only defined on M[_], e.g. types of kind Class[_]; not Class, not Class[_, _], etc...
Maybe what I was thinking if is: ff you have the line: Value -> Type -> Kind, imagine forking off at an angle from Type perhaps upward a bit (in a tangential direction), and call that destination Typeclasses? "A is a Foo" isn't the proper way to describe A: Foo; probably not "Foo has A", either. More like "there exists an implementaion of Foo for A". So it's actually a lot like traits / interfaces. Only, instead of making a subclass of A with Foo mixed-in, you put an instance of Foo parameterized for A in implicit scope.
If you wanted to write a constraint like that in trait-speak, maybe you'd say something like "A with Foo"?
-Leif
I wanted to offer a sort of mea culpa: When, during Rob's talk while we were discussion typeclasses, and I said in def blah[A: Foo](a:A) = ..., the A: Foo relationship can be thought of as being analogous to the 5: Int relationship, I was being excesively hand-wavey, as I often am.
The proper thing at that space in the relationship would be kinds.
Kinds are to types as types are to values. The kind of Int is Type (or maybe in Scala parlance, Class?), and the kind of Option is Type => Type (Class[_]?)
So, in some made-up notation:
5 : Int
Int : Class
Option : Class[_]
Either : Class[_, _]
By the underscores, I just mean that Option isn't a "concrete" type the way Int is - it has to be applied to another type for that. One place where this is useful is in defining typeclasses. E.g. Monads are only defined on M[_], e.g. types of kind Class[_]; not Class, not Class[_, _], etc...
Maybe what I was thinking if is: ff you have the line: Value -> Type -> Kind, imagine forking off at an angle from Type perhaps upward a bit (in a tangential direction), and call that destination Typeclasses? "A is a Foo" isn't the proper way to describe A: Foo; probably not "Foo has A", either. More like "there exists an implementaion of Foo for A". So it's actually a lot like traits / interfaces. Only, instead of making a subclass of A with Foo mixed-in, you put an instance of Foo parameterized for A in implicit scope.
If you wanted to write a constraint like that in trait-speak, maybe you'd say something like "A with Foo"?
-Leif
Jesse Hallett
May 9, 2013, 7:47:29 PM5/9/13
to pdxs...@googlegroups.com
Digressing from typeclasses a bit, using underscores in type
expressions actually does work to manipulate types of different kinds.
It is a lot like creating partially applied functions:
def sum(a: Int, b: Int): Int = a + b
val succ = sum(_:Int, 1)
succ(1) == 2
You can also create partially applied types. Here is an example of
just creating an alias of a type with two parameters:
type OneOrTheOther[A, B] = Either[_, _]
Or you can fill in one of those positions to create a type with a
smaller kind, like with succ and sum:
type StringOrOther[A] = Either[String, _]
val a: StringOrOther[Int] = Left("string")
I just learned about this feature while reading a series of posts on
adopting Haskell's style of IO in Scala with Scalaz:
https://apocalisp.wordpress.com/2011/03/20/towards-an-effect-system-in-scala-part-1/
https://apocalisp.wordpress.com/2011/12/19/towards-an-effect-system-in-scala-part-2-io-monad/
expressions actually does work to manipulate types of different kinds.
It is a lot like creating partially applied functions:
def sum(a: Int, b: Int): Int = a + b
val succ = sum(_:Int, 1)
succ(1) == 2
You can also create partially applied types. Here is an example of
just creating an alias of a type with two parameters:
type OneOrTheOther[A, B] = Either[_, _]
Or you can fill in one of those positions to create a type with a
smaller kind, like with succ and sum:
type StringOrOther[A] = Either[String, _]
val a: StringOrOther[Int] = Left("string")
I just learned about this feature while reading a series of posts on
adopting Haskell's style of IO in Scala with Scalaz:
https://apocalisp.wordpress.com/2011/03/20/towards-an-effect-system-in-scala-part-1/
https://apocalisp.wordpress.com/2011/12/19/towards-an-effect-system-in-scala-part-2-io-monad/
Reply all
Reply to author
Forward
0 new messages