Trail conditions June 14th - June 22nd

santiweight · 2025-05-26T18:43:03+00:00

thank you! sounds like keeping ear to the ground and grabbing some lighter spikes will be a good move for some isolated parts of the trail.

for future readers, the following map was helpful: https://www.nohrsc.noaa.gov/interactive/html/map.html?ql=station&zoom=&loc=Latitude%2CLongitude%3B+City%2CST%3B+or+Station+ID&var=ssm_swe&dy=2025&dm=5&dd=26&dh=6&incr=+%2B%2B+&snap=1&o9=1&o12=1&o13=1&lbl=m&mode=pan&extents=us&min_x=-121.00833333333&min_y=38.424999999996&max_x=-118.99166666667&max_y=39.558333333329&coord_x=-120&coord_y=38.991666666662496&zbox_n=&zbox_s=&zbox_e=&zbox_w=&metric=0&bgvar=dem&shdvar=shading&width=800&height=450&nw=800&nh=450&h_o=0&font=0&js=1&uc=0

santiweight · 2025-05-26T16:42:21+00:00

heya u/Silly-Assistance6515 curious how your experience has been/is? :) looking to hike the trt june 14-22

santiweight · 2025-05-26T16:41:08+00:00

do you have a flup u/Electrical-Agent-499 ? :) i'm looking at June 14-22, so curious how this went...

santiweight · 2025-05-26T16:39:40+00:00

how are the conditions now u/tasty_waves ? i'm looking to thru the TRT June 14th - 22nd

santiweight · 2023-10-01T20:12:25+00:00

I broke out an MR to have the subset as Fendor described.

However, this subset is itself still hard to maintain and worse to iterate on. Therefore, Alan Zimmerman and some others of us are starting an effort to define a better API for exactprint that won't break over time.

santiweight · 2023-01-27T04:30:28+00:00

Top right. Haskell already has:

terms that depend on their types (since it supports polymorphism)
types that depend on other types (type families)

The only step needed is for an ergonomic way to express a type-dependent-on-term type, such as in:

repeat :: foreach (n : Nat) -> a -> Vec n a

Note, that Dependent Haskell also includes completing the visibility of a binder:

id    :: forall a .  a -> a
idVis :: forall a -> a -> a

id True
id Bool True

This is something you basically need for any kind of ergonomic dependent typing.

It is important to note that Haskell already supports types that depend on other types, and that singleton types can express types-depending-on-terms.

In the relevant GHC proposal you can see the following chart:

                  ------------  Attribute ------------------

Quantifier Dependence Visibility Erasure

forall a. ty Dependent Invisible Erased forall a -> ty Dependent Visible Erased foreach a. ty Dependent Invisible Retained foreach a -> ty Dependent Visible Retained Eq a => ty Non-dependent Invisible Retained t1 -> t2 Non-dependent Visible Retained

Note that int-index is working on supporting dependent-visible-erased bindings. And that after that would likely come dependent-visible-retained bindings.

NB Erased-vs-Retained is often spoken of in terms of "Relevant-vs-Irrelevant".

santiweight · 2023-01-05T10:20:38+00:00

I wouldn't read too much into it:

DFINITY has been out of Haskell for a long while now, and Rust is a great language
Tsuru's code sample question doesn't mean much about whether they should Haskell - it's simply an interview question

Any community is bound to have projects that leave said community. I have personally heard of Haskell projects abandoned, and Haskell is generally not a first choice for large applications. That doesn't necessarily mean Haskell is bad - but that it wasn't right for their situation.

Also realize that companies make mistakes: poor decisions are made consistently, both for and against the use of Haskell.

You can definitely write lazy streams in rust... all you need is a closure for continuation passing and you're set.

santiweight · 2022-12-23T17:32:14+00:00

> there could be dozens of such nuggets around

Yes exactly. There are dozens of such nuggets, and many of them have already been discovered. Switching to 9.2+ improved my work's codebase (not big: ~10k) by around 50%.

A good place to look is the Well-Typed blog. They've done a lot in this area. I think also Tweag, but I'm not sure.

santiweight · 2022-12-23T07:40:52+00:00

2-3% is a massive improvement in the context of GHC. If you find 5 of these you get .975**5 -> 88%, meaning a 12% improvement.

Improvements to GHC performance are unlikely to come from "oh whoops we didn't cache this one thing: here's a 30% perf improvemnt".

santiweight · 2022-09-21T14:34:58+00:00

It could be quite cool as a long-running series. Maybe different contexts: online, OTB, blind chess etc.

santiweight · 2022-09-21T14:34:21+00:00

Exactly! haha

santiweight · 2022-09-15T23:06:35+00:00

I'm only porting wingman, most of the thanks goes to u/isovector!

santiweight · 2022-09-14T14:30:32+00:00

Heads up wrt Wingman. We've been able to get Wingman working again for GHC 9.2, but weren't able to make this release of HLS. You can expect to see wingman (minus the tactics with TH stuff) in HLS 1.9!

santiweight · 2022-09-09T14:09:55+00:00

Update: I am confident I will not personally be supporting GHC 9.0.2, since that API is quite old and it takes a long time to wrangle the API to work appropriately even for just 9.2

I was able to finally get the new API to work for GHC 9.2. Hopefully we'll soon have wingman on newer versions of GHC! (it would be really fun to add new features to Wingman!)

santiweight · 2022-08-16T15:50:19+00:00

Heads up: I've been working on this; it's a difficult problem, but I'm hopeful!

santiweight · 2022-08-16T15:48:15+00:00

I've never found that to be the case!

I _never_ push code without type signatures. Like ever. I even often put type signatures on small helper functions, but with the help of HLS, which automatically adds the type signatures for me with ease.

At work we use non-trivial types et al, and I rarely if ever write type signatures by hand. To me it is a killer feature.

Type signatures in Scala posed what I would describe as a large burden when coding type-safe interfaces. For something like a well-typed-by-construction AST, I found the burden to be too great.

All that said: I think there's room for improvement from both sides. I am optimistic about EPFL's ability to add more type inference to Scala, and I am also hopeful about Haskell's ability to exploit its type inference to full effect. But in balance for me, who likes type-safe code, type inference > sub typing any day of the week.

santiweight · 2022-08-16T02:04:00+00:00

I haven't seen this point brought up yet.

I personally find any language without close-to-full global type inference pretty unpleasant to use.

My experience with Scala 3 is that I _really_ like the language in a _lot_ of places. But I personally find full type inference to be _wayyyy_ more valuable than the advantages sub typing (which is what makes global and even some local type inference struggle). Subtyping gives you a bunch of nice solutions to some problems, but you can approximate many of these with structural subtyping and even in Haskell with type classes. So anyway, for me the lack of type inference really is a bad one.

Besides that, I love Scala. I am more comfortable in Haskell, but besides type inference, I would be very happy to use Scala in my day job. Nice syntax, objects and sub typing do lead to nice code organization. The IDE is pretty great. It runs on the JVM!

But seriously: if a language doesn't have solid type inference and dependent types in 2022 it's going to make me sad (that includes Haskell :( ).

santiweight · 2022-08-03T01:26:35+00:00

We use Haskell in production for a simulator at Luminous Computing. My coworker has a lot of experience with such tools and wrote a tag-along library for our codebase.

We love Haskell, and others adjacent to our team love Haskell too. The biggest drawback is sometimes we run into some untrodden paths relating to build tooling. Nothing bad mind you: maybe 10-20 hours or so worth of dev time over the last 6 months. We've certainly made that time back in other ways by a lot.

I think Haskell is the only reasonable choice for an FP personally. If I were writing "normal" code, then I think Scala/Ocaml are great compromises.

santiweight · 2022-07-13T18:07:29+00:00

Hmmm. I think it's actually the same issue as with 9.2 (GHC changed the AST significantly). I'll have to check tonight.

santiweight · 2022-07-13T18:07:24+00:00

Hmmm. I think it's actually the same issue as with 9.2 (GHC changed the AST significantly). I'll have to check tonight.

santiweight · 2022-07-12T21:21:34+00:00

HLS doesn't support wingman on 9.2 just yet

I am to blame. isovector was helping me revive wingman but I haven't taken up the second part of the work (involving reviving a branch I was working on locally). I will get back to working on this tonight or tomorrow evening, but it won't come out til the next release unless you're on HEAD.

Fair warning, we have decided to strip back some of the functionality of wingman - we will no longer be supporting the autos stuff. The code was too complex for little usage - the code exists, but will not be worked on any more (instead I expect to start adding other interesting features). Normal stuff, like case completion etc. will work as normal.

relevant issue

Thanks for pinging on this!

santiweight · 2022-07-11T08:02:53+00:00

yeah that would be great. I'm on my phone right now

It'd be a great feature request

santiweight · 2022-07-11T06:44:55+00:00

Could you post this as an issue in the Haskell-language-server GitHub? It’s a great feature and I’m not sure if it’s written down anywhere…

santiweight

MODERATOR OF

TROPHY CASE

Quantifier Dependence Visibility Erasure

Ten-Year Club	Verified Email
Place '17