The common practice in Java is to use all caps for static final variables:
static final int MY_CONSTANT = 24
I believe the common practice in Scala for val is to use:
val MyConstant = 24
Is there an accepted place to use all caps, like in Java, in Scala?
According to the official guidelines: no. In practice ALL_CAPS generally means "all caps, separated by underscores," and Scala really doesn't want you using underscores in names.
Generally speaking, Scala uses “camelCase” naming conventions. That is, each word (except possibly the first) is delimited by capitalizing its first letter. Underscores (_) are heavily discouraged as they have special meaning within the Scala syntax.
Related
The Unicode is allowed in identifiers in backticks
val `💾id` = "1"
But slash is not allowed
val `application/json` = "application/json"
In Scala we can have such names.
This is a JVM limitation. From the specification section 4.2.2:
Names of methods, fields, local variables, and formal parameters are stored as unqualified names. An unqualified name must contain at least one Unicode code point and must not contain any of the ASCII characters . ; [ / (that is, period or semicolon or left square bracket or forward slash).
In Scala names are mangled to avoid this limitation, in Kotlin they are not.
Kotlin's identifiers are used as-is, without any mangling, in the names of JVM classes and methods generated from the Kotlin code. The slash has a special meaning in JVM names (it separates packages and class names). Therefore, Kotlin doesn't allow using it in an identifier.
Our application relies on lots of equations, which, to correspond with the standard scientific names, use variable names like mu_k, (if the standard is $\mu_k$). (We could debate whether scientists should switch to CS style descriptive variable names, but often the terms don't really describe anything, they are just part of equations, and, more over, we need our code to match the known literature.)
In C this is easy to name vars this way: int mu_k. We are considering porting our code to Scala, but I know that val mu_k is discouraged in Scala, because underscores have special meanings.
If we use underscores only in the middle of the var name (e.g. mu_k) and not beginning or end (e.g. _x or x_), will this present a problem in Scala?
What is the recommended naming convention for Scala in this case?
You are right that underscores are discouraged in variable names in Scala, which implies that they are not forbidden. In my opinion, a convention should be followed wherever sensible.
In the case of mathematical formulae, I disagree that the Greek letters don't convey a meaning; the meaning is not necessarily intuitively descriptive for non-mathematicians, but as you say, the reference to the usage in a paper may be meaningful and important. Therefore, sticking with the underscore won't hurt, although I would probably prefer a more Scala-style way as muX when possible and meaningful. If you want a perfect answer, you might need to perform a usability test with your developers. In the specific example, I personally find mu_x more readable than muX, but that might differ among individuals.
I don't think the Scala compiler has a problem with underscores in the examples you described. Presumably, even leading and trailing underscores are fine, but should indeed be avoided strictly because they have a special meaning: http://docs.scala-lang.org/style/naming-conventions.html#methods.
Underscores are not special in any way in identifiers. There are a lot of special meanings for the underscore in Scala, but not in identifiers. (There is a special rule in identifiers that if you want to mix alphanumeric characters and operator characters in the same identifier, they have to be separated by an underscore, e.g. foo? is not a legal identifier, but foo_? is.)
So, there is no problem using an identifier with an underscore in it.
It is generally preferred to use camelCase and PascalCase for alphanumeric identifiers, and not mix alphanumeric and operator characters in the same identifier (i.e. use maxBy instead of max_by and use isFoo instead of foo_?) but that's just a coding convention whose purpose is to reduce the number of "unspecial" underscores, so that you can quickly scan for the "special" ones.
But in your case, you are using special naming conventions anyway, so you don't need to adhere to the community naming conventions as strictly.
However, I personally would actually prefer the name µ_k over mu_k.
That's as far as it goes with Scala, unfortunately. The Fortress programming language by Sun/Oracle did allow boldface, overstrike, superscripts and subscripts in identifier names, so something like µk would have been possible as a legal identifier, but sadly, Fortress was abandoned a couple of years ago.
I'm not stating this is the correct way, and myself would be rather discouraged to do this, but you can use full string literals as identifiers:
From: http://www.scala-lang.org/files/archive/spec/2.11/01-lexical-syntax.html
id ::= plainid
| ‘’ stringLiteral ‘’
Finally, an identifier may also be formed by an arbitrary string
between back-quotes (host systems may impose some restrictions on
which strings are legal for identifiers). The identifier then is
composed of all characters excluding the backquotes themselves.
So this is valid:
val ’mu k‘
(sorry, for formatting)
I wish to code fully with Esperanto lexemes. That is, not ending up with a English/Esperanto mix up. Perligata is a good example of the kind of result I would like, but it use Latin where I want to use Esperanto.
So Perl seems to be a valid answer to my question. On the other end a language like Python have no mechanism that would let you use se (if in esperanto) rather than if. On what you may call middle ground, you have languages like C that allow to replace keywords through its processor (#define se if), but won't allow you to get ride of the define keywords itself. Also you have languages like racket and the LISP-family that would probably let you use wrap most internal symbols, but probably not allow you to easily change parentheses for anything else. For example mapping ( with ene and ) with ele.
Also an other point is ability to use unicode in identifiers, as Esperanto do use non-ASCII characters in its alphabet, like ĉ. That's not really a blocking element, as one is available to use cx instead of ĉ, but its nevertheless an interesting parameter.
So I guess an ideal answer to this question would be a matrix of languages specifying their lexeme and grammar customability.
each formal language has its syntax. in my opinion, lowest 'syntax overhead' is offered by lisp-like languages. but then you don't want to have parenthesis. you also don't want to have #define therefore you reject any syntax at all and all possible replacements.
i don't think there is any language that will let you do it. you should look for language generators, write your own language (at least the syntax part) or the simplest possible way, add your own find-replace layer on top of any existing language
In scala and some other languages (Haskell, SML), we can use pattern matching, like:
val user: Option[User] = findUser(123)
user match {
case Some(u) => ...
case _ => ...
}
I have some questions about the relationship of pattern matching and type system:
Is "static type system" a must to support pattern matching?
Is there any "dynamic type system" language supports pattern matching?
Update:
Thanks to #Eran's answer.
I know there are many languages don't support pattern matching, like c/c++/java/python/ruby/javascript/lisp (can I add "bash" to this list?)
If we want to add "pattern matching" to them, what languages can add it in theory? And what languages can't do it in any case?
I assume you mean pattern matching for values in general. The special case of string pattern matching (regular expressions) is supported via library functions in pretty much any language.
Pattern matching and type checking policy are independent language "features".
Pattern matching is the process in which values are matched against patterns and successful matches are then bound to variables.
A type system is static or dynamic if type checking is enforced at compile time or run time, respectively.
A language can have either of the four combinations of these two features, for example:
C/C++/Java are statically typed languages that do not support pattern matching.
Haskell/Scala are statically typed languages that do support pattern matching.
Icon is a dynamically typed language that does support pattern matching.
JavaScript is a dynamically typed language that does not support pattern matching.
Tangentially, I find it very interesting that pattern matching can actually be used as a foundation for computation. You can search for work on pattern calculus, by Barry Jay if this piques your curiosity.
Just saw an example that looks like the following:
val b_* = grater[Book].asObject(dbo)
What is the significance of the asterisk in b_* here? What's the name for it in Scala and what affect does it have on the outcome of b_?
Asterisk is valid in scala variable and value names, as are many other characters that are not allowed in in identifier names in Java or other C-like languages. See Valid identifier characters in Scala for more info.
However, just because it can be done doesn't mean it should be done. To my eye, it's not obvious at all what this value represents.