I think Scala has definitely improved on C++ in this regard :)
C++ had a very clear (and restricted) idea of what operators were available,
and could be overloaded - using method names like operator_+
You also had to decide if you wanted your operator to be a friend, or to be
a member, it very quickly got convoluted and the answer wan't always clear.
Scala takes the approach "Do not try to bend the operator — that's
impossible. Instead, only try to realize the truth: there is no operator."
In other words, Scala doesn't have operators as you might normally
understand them.
Instead, "operators" are just an infix notation for calling methods,
allowing ANY method to be used as an operator
The works because symbols are also allowed as method names
So the following are equivalent.
mylist map { _ + 2 }
mylist.map( _ + 2 )
x + 2
x.+(2)
This infix notation can be used to great effect in DSLs such as ScalaTest (
http://www.scalatest.org/getting_started_with_bdd)
allowing for expressions that read very much like plain english
When such "operators" are daisy chained, precedence is determined by the
first letter of the operator name.
This allows 1 + 2 * 3 + 4 to be equivalent to 1 + (2 * 3) + 4 and not ((1 +
2) * 3) + 4
any operator ending with a `:` is also right associative. So
x :: someList
is equivalent to someList.::(x)
and not x.::(someList)
This is a nice convention, allowing for a symmetry in operators, consider
the prepend (+:) and append (:+) operators against sequences
(sequences include lists, vectors, buffers, etc.)
1 +: someList :+ 2
becomes someList.+:(1).:+(2)
By allowing any combination of unicode characters to be an operator, you
also avoid the problem in C++ where you needed an operator, but were forced
to choose from a limited subset - none of which was appropriate. Stream IO
being the classic example of this!
Scalaz, for example, draws quite heavily from the algebraic symbols used in
set theory and category theory:
http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Identity.scala.html
If you want ≤ or ∘ or ⊛ or ∑ or ∃ or ∀ or ∈ or ∋ you can have them :)
On 9 August 2010 09:02, Fabrizio Giudici <[email protected]>wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/8/10 17:35 , Josh Berry wrote:
> > It seems that the thing that is "off" in all of this discussion is
> > that we are trying to determine which is more complex between the
> > languages, when what we really care about are the programs written
> > in those languages.
> >
> > To that end, I really just want to simply point to something like
> > scalatest or squeryl to get an idea of the simplicity of some of
> > the client code that can be written against Scala.
> >
> > Take your example, though, "5 + 2." This works for simple
> > numbers, but what about the fun of matrix math? Or complex numbers
> > math? Both of which would undoubtedly look nicer --- one might say
> > simpler --- using the familiar symbols for addition, but this can
> > not be done in Java. Now, I would agree that this is a complexity
> > of the language, but it is a simplification in the program.
> I've been fooled by this idea fifteen years ago with C++ and I
> dramatically changed my mind :-) At the time I was expanding my
> knowledge of C++ by writing my first public app (not open source at
> the time) that was a flight simulator for MS-DOS (it was called FGFLY
> (*)). Of course there was a relatively simple physics engine inside
> (but it was by far much more sophisticated than most of the stuff
> available at the time) and of course there was vector / matrix maths
> inside. Also, I didn't use any library, so even 3D rendering was done
> by me. I thought that being able to write stuff such as f = m * a or x
> = [M] * y was great, and pushed the use of templates and operator
> overloading to a big extent. In the end, it turned out to be a
> nightmare. Sometimes I completely lost control of implicit
> conversions, thus generating unoptimized code; when I tried to compile
> the thing under two compilers (I started with Borland C++, then moved
> to Watcom C++ for MSDOS - it supported 32bits and included a memory
> extended that allowed to bypass the infamous 640MB limit, and
> eventually started to port it under Linux with the GNU compiler) I ran
> in a number of gray areas in the C++ specifications, so one compiler
> usualy got it right and the other got it wrong. At the end, I gave up.
>
> Of course, it's perhaps an implementation problem rather than a
> specification problem, and maybe today they can get it right in Scala
> (and maybe bytecode even improves the quality of the final native
> code). But we're always in the same side: operator overloading is
> powerful, but complex. It's a way to shoot into your feet.
>
>
> (*) There are no more traces of FGFLY in Internet (you might find some
> screenshots having fgfly in the name, but they're likely to be
> FlightGear). Unfortunately I've lost the sources of it (that's when I
> learned how to to backups :-) but I think an executable is still
> downloadable from there:
> http://www.nic.funet.fi/pub/msdos/games/demos/fgfly01c.zip. I don't
> think it runs on any modern computer, since it depended heavily on
> VESA extensions for the graphics and needed a SoundBlaster for the sound.
>
> - --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> java.net/blog/fabriziogiudici - www.tidalwave.it/people
> [email protected]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxftfwACgkQeDweFqgUGxcWjwCeIn0HM7AuFulYDb399rVWOQTJ
> 6lcAn12KnNf8vbC7EaH+xDcxV3M6gC8x
> =2WBs
> -----END PGP SIGNATURE-----
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
mail/google talk: [email protected]
wave: [email protected]
skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
