-
-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
first pass at cheatsheet for scala #348
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Terribly sorry for the delay, my inbox overwhelmed me
/** | ||
* a very special trait. | ||
*/ | ||
trait Foo {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you remove the foobar references please.
size2 = 1 | ||
``` | ||
|
||
Scala uses `val` for immutable bindings and `var` for mutable bindings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove explanations and examples of var
and the scoping rule below, as we don't need to teach Scala and there's no equivalent in Gleam.
In Gleam, `let` and `=` can be used for pattern matching, but you'll get | ||
compile errors if there's a type mismatch, and a runtime error if there's | ||
a value mismatch. For assertions, the equivalent `let assert` keyword is | ||
preferred. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let assert
is required, not preferred. let
does not result in a runtime error as it does not permit value mismatches
For methods with no arguments, you may omit the parenthesis | ||
|
||
```scala | ||
|
||
def noArgs = "Surprise." | ||
|
||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For methods with no arguments, you may omit the parenthesis | |
```scala | |
def noArgs = "Surprise." | |
``` |
We don't need to teach Scala
```scala | ||
def main() = { | ||
val x = { | ||
someFunction(1) | ||
2 | ||
} | ||
// Parenthesis are used to change precedence of arithmetic operators | ||
// Although curly braces would work here too. | ||
val y = x * (x + 10) | ||
y | ||
} | ||
``` | ||
|
||
or using indentation in Scala 3 | ||
|
||
```scala | ||
def main() = | ||
val x = | ||
someFunction(1) | ||
2 | ||
val y = x * (x + 10) | ||
y | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
```scala | |
def main() = { | |
val x = { | |
someFunction(1) | |
2 | |
} | |
// Parenthesis are used to change precedence of arithmetic operators | |
// Although curly braces would work here too. | |
val y = x * (x + 10) | |
y | |
} | |
``` | |
or using indentation in Scala 3 | |
```scala | |
def main() = | |
val x = | |
someFunction(1) | |
2 | |
val y = x * (x + 10) | |
y | |
``` | |
```scala | |
def main() = { | |
val x = { | |
someFunction(1) | |
2 | |
} | |
val y = x * (x + 10) | |
y | |
} |
Can drop some of the info on Scala
} | ||
``` | ||
|
||
As all expressions the case expression will return the matched value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean?
_ if is_confirmed_by_mail == True -> "allow access" | ||
_ -> "deny access" | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this please
Exhaustiveness checking at compile time, which is in the works, will make | ||
certain that you must check for all possible values. A lazy and common way is | ||
to check of expected values and have a catchall clause with a single underscore | ||
`_`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gleam has exhaustiveness checking
try { | ||
println("this line will be executed and thus printed") | ||
aFunctionThatFails() | ||
println("this line will not be executed and thus not printed") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be 2 space
However, this is not considered idiomatic Scala in most cases. Many libraries | ||
provide more functional approaches to error-handling. The standard library | ||
also includes such a structure which can wrap code that throws exceptions | ||
and return the success or exception as a value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove this bit as we don't need to teach Scala
Thanks for the thorough review! I'll try to get these edits done soon |
Hello,
For your consideration, I've written a cheatsheet for Scala programmers. I think by most measures Scala is the most mainstream fp language in industry and has a lot of similarity with Gleam. Both are highly influenced by ML family of languages but use a more C-style syntax.
I'm not sure how you decide which languages deserve a dedicated cheatsheet, and I realize this is more (basically untestable) code that needs to be maintained. So I will be understanding if you're not accepting these types of contributions.
There's also probably some mistakes, I based this off of the PHP cheatsheet but read several others to get ideas for what else to cover. I tried to keep in mind the audience should be Scala programmers looking into Gleam and not as much the other direction, so there's tons of omissions about Scala's huge type system.
Additionally, I think it would make sense to draw a comparison between the
use
expressions and Scala'sfor
comprehensions, but I didn't see an obvious spot for that. Another minor thing to add is thetodo
vs Scala's???
(which seems to have inspiredtodo
) but that seems less important for real-world code.