Re: assorted beginner questions

On 1/28/07, martin odersky odersky-at-......... |scala|
<...> wrote:
> > for the following code:
> >     def all(xs: Iterator[Boolean]) = xs forall (x => x) // forall (xs) (x
> => x)
> >     all(for (val b <- List(true,false)) yield !b)
> > i get:
> > Main.scala:29: error: no type parameters for method map:
> > ((scala.Boolean) => b)scala.List[b] exist so that it can be applied to
> > arguments ((scala.Boolean) => scala.Boolean)
> > --- because ---
> > result type scala.List[b] is incompatible with expected type
> > scala.Iterator [scala.Boolean]
> >     all(for (val b <- List(true,false)) yield !b)
>
> Lists are not iterators. You either need to  turn the result of `for' into
> an iterator using `elements', or define `all' on Iterables.

why doesn't the for-comprehension iterate over everything by default?
or why not enforce map() always return an iterator? or have
for-comprehensions use elements()?

> > is there any special syntax for hashtable/map/set gets/updates?
>
>  General syntactic sugaring applies. You can write:
>
>     m(key) = value       or
>     m += (key -> value)
>
> The two are equivalent. The first is translated to m.update(key, value). The
> second reduces to the same expression.

what's the () operator? (m("d") in the examples.) i.e., what am i
looking for in the api docs? or is this a language-level translation?

i'm pretty amazed at how fast development on this language is moving.
i just downloaded 2.3.0 what seemed like a few days ago, and in 2.3.2
all these and other changes were introduced. and now there's 2.3.3.

> > why is, e.g., foldLeft defined so oddly? 'explicitly curried', it seems:
> > def foldLeft[b](z: b)(op: (b, a) => b): b = ...
> > this is also seen on
> > http://www.scala-lang.org/intro/targettyping.html. is
> this seems to
> > encourage the user to use this strange syntactic style:
> > (xs foldLeft z) { (x,y) => x+y }
>
> That's indeed the encouraged style. One reason for this is that then you
> need not give types for the parameters x and y (they are inferred from the
> previous argument).

indeed,

scala> def f[T,U](s:Set[U],a:T,b:(T,U)=>T):T=(s foldLeft a)(b)
f: [T,U](scala.collection.immutable.Set[U],T,(T, U) => T)T

scala> f(Set(1,2,3),0,((x,y)=>x+y))
<console>:5: error: missing parameter type
 val line10 = f(Set(1,2,3),0,((x,y)=>x+y))
                               ^
<console>:5: error: missing parameter type
 val line10 = f(Set(1,2,3),0,((x,y)=>x+y))

for some reason, the inference breaks if you try to lump the args
together. it's unclear to me whether this is a limitation of the
implementation or scala's type system.

> > while on that page, what's the difference between {} and () in this
> > context? it seems whileLoop treats both as parameterless closures
> > ('blocks' as the manual calls them).
>
> They are exactly the same at the moment. Both mean the unit value.  We are
> thinking of deprecating () because it looks too much like an empty parameter
> list (which is not the same as the unit value).

i also was actually referring to the use of (...) and {...} (not
empty; they have stuff between them).

to use the above example:

(Set(1,2,3) foldLeft 0) ((x,y) => x+y)
(Set(1,2,3) foldLeft 0) {(x,y) => x+y}
{Set(1,2,3) foldLeft 0} ((x,y) => x+y)
{Set(1,2,3) foldLeft 0} {(x,y) => x+y}

> > is there any way to automatically inherit certain behaviors, a la
> > 'derives' in haskell? any tools/approaches using metaprogramming,
> > reflection, or something else? in particular, i'd like to
> > (de)serialize my objects, a la python's pickle or haskell's read/show,
> > without writing any serialization code (or at most once).
>
> There are some frameworks for this in development. Philip Haller has a
> library of pickling combinators in style of what Andrew Kennedy did for
> Haskell.

does anybody have more info about this? do the combinators use scala.reflect?

> > what are the some of the principal reasons for scala's (generally)
> > lesser performance compared with java, at least according to the
> > language shootout? not trolling; i'd just like to understand the
> > strengths and weaknesses of languages that i use.
>
> Last I saw, Scala was equal to Java in the shootout. I think the shootout
> produces a lot of noise anyway.

although the shootouts are flawed in many ways, the ratio of
Java:Scala speed seems to be consistently non-negligible across the
shootouts: 1.7:2.6.

yang