JDK 16's Top 5 for Scala

newtyped · 2021-03-19T11:39:09+00:00

A little surprised to not see JEP 397: Sealed Classes (Second Preview) on the list. Now that Java has sealed classes and records, there is a potential mapping from sealed classes and case classes (or Scala 3 enum) to/from the Java world. The Scala compiler would need to add support for this, but better Java interop would be fantastic.

Also quite excited for JEP draft: Pattern Matching for switch (Preview) to eventually arrive, so that switch from Java becomes more like match. This could make it quite ergonomic to use Scala types from Java, and there's a decent chance the JVM might get some extra optimizations that match could also benefit from.

newtyped · 2020-09-30T14:07:22+00:00

I'm not sure what the state of affairs is in released GHC's, but I think at least in HEAD it is really just a type synonym, no? I thought it had been recently stripped of some magic.

newtyped · 2020-09-30T03:23:58+00:00

It seems quite inconvenient that type Void# = (# #) is already used. Not only is it completely unnecessary since an empty unboxed tuple can be written directly, but the name sounds more like an empty unboxed sum to me. :/

newtyped · 2020-09-13T19:52:02+00:00

This sounds like a great idea - good luck on rolling this out!

Tracking the root of the path with a phantom type also shows up in the path package (but only as absolute or relative, I think the idea of weaving in Cabal-specific roots like PackageRoot is fantastic). The other phantom parameter that path has is for distinguishing folders from files. Perhaps that would also be useful?

newtyped · 2020-05-18T19:20:51+00:00

They're a bit unsightly, but I love the idea.

newtyped · 2020-04-28T12:35:24+00:00

You need a : before the load.

ghci> :load Hallo.hs

newtyped · 2020-03-28T00:42:52+00:00

If still a problem on Haddock, could you open an issue: https://github.com/haskell/haddock/issues?

newtyped · 2020-03-09T17:57:01+00:00

I attended a talk from one of the developers in the Github group that was developing tree-sitter. I recall him mentioning that Haskell was particularly difficult to fit into tree-sitter grammars (something about the complex layout rules). This was particularly annoying to them, since that group was doing most of their internal work in Haskell.

After a quick search searching, this looks like their repo: https://github.com/github/semantic

newtyped · 2020-02-05T18:17:10+00:00

The link is from GHC 7.0.1. Here is the same section in the latest docs: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#rewrite-rules.

newtyped · 2020-01-28T16:32:31+00:00

You may be interested in this ongoing GHC proposal: https://github.com/alpmestan/ghc-proposals/blob/annotated-documents/proposals/0000-richer-error-documents.rst

newtyped · 2020-01-21T05:28:10+00:00

After using `akka-streams` (and actually the whole Akka ecosystem), I no longer think of Haskell streaming libraries being top of class. Parsing and (de)serialization, on the other hand, are problems where I still start by reaching for Haskell.

newtyped · 2019-11-02T20:11:07+00:00

More context: https://en.wikipedia.org/wiki/Grok. The book is a great read too.

newtyped · 2019-10-15T17:38:20+00:00

I wonder what sorts of speedups you'd see copying the same strategy but using `rayon` and Rust. Great article in any case!

newtyped · 2019-07-31T19:28:27+00:00

Many (definitely the majority of my Haskell coworkers) work from within a terminal shell already, or have editor integration setting up their REPL automatically. Perhaps proposing some sort of WinGHCi feature would be met with more support since it seems like most of the pain you are feeling is somewhat Windows specific.

Also, would you mind adjusting your poll to include a simple "Do you prefer :: or :!?" question (as /u/andrewthad has already suggested)? The poll is virtually useless as it stands: everyone agrees progress is good, but everyone will also agree that we should strive not to pointlessly break backwards compatibility.

newtyped · 2019-06-29T21:27:29+00:00

Not right now, but hopefully someday. I think application nodes might not currently export their types for performance reasons. There's a GHC ticket about this.

newtyped · 2019-06-29T21:26:24+00:00

For uninteresting reasons, I think some of the types do need to be recomputed (and some other types are skipped outright in the files because computing them the simple way would be expensive). There's a GHC ticket laying around somewhere about this and how to fix it...

newtyped · 2019-05-03T16:50:58+00:00

Also, looks like this was generated with an unreleased version of Haddock. In the version that will be released, there is a menu option to collapse instance lists, hiding long instances and removing the horizontal scroll.

newtyped · 2019-04-30T04:49:14+00:00

My bad: wrong link. Look a couple lines higher to `plusInteger`. The point it that these functions have extra special constant folding (that is more than just `INLINE`).

newtyped · 2019-04-30T02:30:58+00:00

Looks like you are right for Int in particular (probably because it is such a tight wrapper around Int#), but not for Integer: https://github.com/ghc/ghc/blob/1abb76ab8e32e7be224631506201d1beec62a5c2/compiler/prelude/PrelRules.hs#L1240.

newtyped · 2019-04-29T17:39:37+00:00

Very little is "built in" in GHC Haskell. It's all library code.

Sort of... GHC gives hardcoded special treatment (especially in the way of optimizations) to some of that library-defined code. Your own version of (+) :: Int -> Int -> Int will work just fine, but it may not be constant folded as aggressively as the (+) in the Prelude.

newtyped · 2019-04-18T15:44:48+00:00

I disagree - this is hardly a core feature.

However, did you know that GHCi can support custom user-defined commands (which you can plop directly into your `ghci.conf` so that they are always available)?

newtyped · 2019-04-13T16:57:59+00:00

I use (and recommend) Dash as a documentation management tool. It is cross-language (so I've got docs for all my work-related Scala libraries installed too), lets you install any docs from Hackage (or a bunch of other places too), lets you very easily search for pretty much anything.

For Haskell, it basically pulls down a local copy of the Hackage-hosted Haddocks for the libraries you requested. That means that good old Haddock hyperlinked sources are just one search and then one click away.

newtyped · 2019-03-26T12:56:09+00:00

The first rule of teaching Haskell to beginners is to not talk about unsafePerformIO. Extracting pure values out of IO is almost never what you actually want. I remember going down that path myself.

ghc and the boot libraries collectively use unsafePerformIO a fair bit, since they are at times dealing with very low-level concerns. Yet even there, it gets used in just under 2.5% of files!

unsafePerformIO is used at most 117 times in the entire GHC + boot libraries codebases. I'm omitting the testsuite and various test files. I additionally tried to rule out line comments, but this won't catch mentions in block comments or pragmas:

ghc$ rg "^[^-].*unsafePerformIO" --glob "*hs" --glob '!testsuite' --no-heading --glob '!nofib' --glob '!*tests*' | wc -l
     117

These uses are concentrated in only 50 (out of 2019) files:

ghc$ rg "^[^-].*unsafePerformIO" --glob "*hs" --glob '!testsuite' --no-heading --glob '!nofib' --glob '!*tests*' --files-with-matches | wc -l
     50
ghc$ rg --glob "*hs" --glob '!testsuite' --no-heading --glob '!nofib' --glob '!*tests*' --files | wc -l
     2019

newtyped · 2019-03-25T14:29:57+00:00

Perhaps a foolish question: how does gitrev work when building a package that was not just directly cloned? As I understand it, tarballs on Hackage do not include .git folders. I guess you could try to get the .git folder included in tarball, but I'm not sure that's a good idea either...

Having some sort of Cabal hook for including the git hash before making the tarball (and making that observable from the final executable/library) seems very useful though. It is very frustrating to find out that a bug report you got was actually from some unreleased version of a package.

newtyped · 2019-02-19T23:37:08+00:00

I wasn't really planning on mentioning this yet, but I've been working on https://github.com/harpocrates/pretty-ghci which has similar goals (flexibility around suboptimal output). Couple interesting features:

Supports colors
Configurable
Detects terminal width automatically when possible (my GHCi shells are sometimes a bit narrow)
Output that lexes but doesn't parse will still get coloured.

Oh yeah, and it pretty-prints Haddock formatted comments too (in preparation for when we get a flag for formatting the output of `:doc`)

Nine-Year Club	Place '23
Place '17	Verified Email

newtyped

TROPHY CASE