The Artima Developer Community
Sponsored Link

Programming in Scala Forum
Symbol literals?

5 replies on 1 page. Most recent reply: Sep 26, 2010 1:18 PM by Nikolaos Apostolakos

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Vladimir Kelman

Posts: 46
Nickname: vkelman
Registered: Feb, 2008

Symbol literals? Posted: Sep 8, 2008 6:40 PM
Reply to this message Reply
Book says,
Symbol literals are typically used in situations where you would use just an identifier in a dynamically typed language. For instance, you might want to define a method that updates a record in a database:
scala> def updateRecordByName(r: Symbol, value: Any) {
// code goes here
The method takes as parameters a symbol indicating the name of a record field and a value with which the field should be updated in the record.
you can pass a symbol literal:
scala> updateRecordByName('favoriteAlbum, "OK Computer")

I don't understand why would we use a symbol literal as a first function parameter, why not to use a string literal? Perhaps, I'm not familiar with dynamic languages, in C# I would definitely use a parameter of type string. Could the usage of symbol literals be explained in more details?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Symbol literals? Posted: Sep 9, 2008 9:41 AM
Reply to this message Reply
HI Vladimir,

Sorry, I think our examples are a bit too contrived here. Basically the most significant difference between a symbol literal and a string literal is that you can't have spaces in a symbol literal. You also can't have spaces in Scala identifiers, like method names, variables names, class names, etc. That's really the main thing they are intended to be used for, as far as I know.

A use case for symbols is if you are trying to do something dynamic in a Scala program. For example, perhaps you define a method that is supposed to take as one argument the name of another method. It is better to pass a symbol in for the method name rather than a string for two reasons. One reason is the syntax looks a bit less cumbersome on the invocation, because you have one tick mark in front of the method name string being passed, rather than needing to surround it with double quotes on both ends. Another is that if you change a method name using a refactoring IDE or other refactoring tool, that tool could either change all the symbols with that name, or show them to you, etc. It is the kind of heuristic refactoring you get with a dynamic language, but by having those names symbols instead of strings, that should reduce the likelihood of false hits when doing heuristic refactoring.

A concrete example is I'm planning to add a method for invoking private methods to ScalaTest, so that it is easier to test private methods. I can't invoke them statically, because it won't compile (because they are private). I have to use reflection, but that code is very verbose, so I'm making an invokePrivate method to make it less verbose. invokePrivate will take the name of the private method to invoke as a symbol, not a string, for the above reasons.

j herber

Posts: 6
Nickname: 53144
Registered: Jan, 2008

Re: Symbol literals? Posted: Sep 9, 2008 10:09 AM
Reply to this message Reply
first, they are visually discernable over strings.

"key" -> "value"

'key -> "value"

second, in dynamic languages, symbols are used identify things that have a stronger meaning than a mere string content. they name a thing or an action. often something we use more than once in the code.

in ruby, they look a bit better, imo.

:key is a symbol

here's a snapshot of symbols (blue) in a ruby editor where they stand out.

thus the authors of scala have given you a finer granularity of control over visual and semantic identification for things you may have used strings for in the past, but that are not merely "values".

Vladimir Kelman

Posts: 46
Nickname: vkelman
Registered: Feb, 2008

Re: Symbol literals? Posted: Sep 9, 2008 10:50 AM
Reply to this message Reply
Thank you very much, Bill! I think I'm starting to understand. I suspected that it is something to denote identifiers... I'm looking forward to see your example with invocation of private methods using reflection. I wonder if at the moment of actually invoking a private method you would need to convert a symbol to a string (which could be done implicitly, I guess).
It's a quite complicated topic for a newbie Scala developer with a zero knowledge of dynamic languages like Ruby.
As far as I know, C# does not provide a facility similar to Scala symbols.

I asked the same question in Scala - User Nabble forum. A discussion there is quite interesting too, although it partially transformed to string semantic :).

Vladimir Kelman

Posts: 46
Nickname: vkelman
Registered: Feb, 2008

Re: Symbol literals? Posted: Sep 9, 2008 11:06 AM
Reply to this message Reply
Thank you, j herber.
Your post is a good addition to Bill's one. As I said, I'm starting to understand a reasoning behind adding Scala symbols.
I newer programmed in Ruby, but in your example I see :post label (it is called a label in Ruby, right?) used after 'when' keyword, where, I guess, a Boolean is expected. Is it somehow implicitly converted to an identifier of a Boolean variable?
Isn't a construct like session[:user] where as C# programmer I could use a constant (like const user = "app_user")?

Nikolaos Apostolakos

Posts: 1
Nickname: nikoapos
Registered: Apr, 2010

Re: Symbol literals? Posted: Sep 26, 2010 1:18 PM
Reply to this message Reply
Hi Bill,

I am currently trying to learn Scala and after reading the part of the book related with symbol literals I was still a little bit confused about their reason of existence (like Vladimir was). This post gave me some idea, but it also created the following questions.

First of all I would like to comment that it is not true that symbol literals cannot contain spaces. This is true only on the case when the syntax of the single quote is used (according my understanding). If the factory of the Symbol object is used, then a symbol literal with spaces can be created (at least with Scala 2.8 which I use now). For example:

scala> val symbolLiteralWithSpaces = Symbol("I have spaces")
symbolLiteralWithSpaces: Symbol = 'I have spaces

Is this behavior intended or the visibility of this factory should actually be restricted only for internal use of the Scala libraries? Except of the fact that the factory can create symbol literals with spaces (which could be a security issue for methods like the example in the book), the use of the factory also does the support from the IDEs unreliable (I am not an IDE developer, but my guess is that the detection of the symbol literals will most probably be done by parsing the code and detect the tokens starting with single literal, and not by checking the calls to a specific method of an object, the argument of which should actually be highlighted as a String that it is).

My second question is about performance. The benefit when two symbol literals are compared, having in mind that they are interned, is obvious to me. What is not so clear is what is the cost of the creation of the symbol literals. Is the scala compiler actually replacing the single quote symbols with calls to the factory method I mentioned earlier and then the symbols are created in runtime, when the specific part of code is executed? Wouldn't that mean that anywhere a symbol literal object is used (which most probably will never be reused again if it is used like the way j herber demonstrates) there is the need for a time consuming hash calculation (maybe even more expensive than a character to character string comparison)? Or is the scala compiler doing this overhead during compiling and the generated bytecode does something smarter?

Thank you for your answers and sorry for posting in a so old post.

Flat View: This topic has 5 replies on 1 page
Topic: java program help Previous Topic   Next Topic Topic: I want exercises

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use