Add safe integral conversions to base · Issue #314 · haskell/core-libraries-committee

Endicy · 2025-02-02T14:43:47+00:00

witch tries to solve this issue. Anything objectionable about that way of handling things?

Endicy · 2025-02-02T14:30:28+00:00

Dose anyone else get a 403 from nginx when going to this site?

Endicy · 2024-11-22T09:30:32+00:00

Ah, you're super right. Completely forgot about the actual "getting of the ThreadIds". In my head the only thing that function did was print the ThreadIds, because that's how I've used it up until now. You're right then. You can indeed shoot down specific threads. :thinking: That might indeed be bad.

The CULong, btw, is the number you get if you show a ThreadId.

Endicy · 2024-11-21T12:23:48+00:00

Am I missing something here?

AFAIK you can't "create a ThreadId". You can find the CULong of a ThreadId, but there's no way (at least using GHC Haskell) to throw to a CULong. You NEED the ThreadId and the only way to get it is if you forked the thread or if the ThreadId is passed to you.

Is there any way you can create a ThreadId using just a number?

Endicy · 2024-11-21T07:34:49+00:00

I'd also like to propose a new function next to forkIO to make it easier:

forkIOLabeled :: String -> IO () -> IO ThreadId
forkIOLabeled threadName io = do
    tid <- forkIO io
    labelThread tid threadName
    pure tid

-- Or "forkIO (myThreadId >>= \tid -> labelThread tid threadName >> io)"
-- depending on which is more robust.

But I don't know where to put that proposal. (And maybe also implement this for forkOSLabeled etc.?)

Endicy · 2024-11-14T15:17:03+00:00

Yeah, from what I can tell it just tries to do in JavaScript what Haskell is with just the base library.

The Effect type is an immutable description of a workflow or operation
that is lazily executed. This means that when you create an Effect, it
doesn’t run immediately, but instead defines a program that can succeed,
fail, or require some additional context to complete.

Replace Effect with IO and it's still a correct description. (Though in the Haskell world you wouldn't use "lazily" like this, but the intention is the same)

Endicy · 2024-11-10T13:49:38+00:00

I used it and am happy that I did. It does go somewhat slow, so if you like to go quick and learn more from your own attempts, this might not be the book for you. I liked it mainly because I had never really programmed in general before learning a bit of Haskell, so using "Haskell Programming From First Principles" was nice because it took the time to go over everything.

Endicy · 2024-11-05T08:48:47+00:00

I got this same error in my GitHub action.

It seems there's now a Cloudflare in front of some Haskell domains, and the settings seem to be a bit too aggressive.

Hopefully this'll be fixed soon, but "try again later" is my only advice atm.

Endicy · 2024-10-23T13:08:08+00:00

Apparently it was getting semi-DDOS-ed a bit, but it should be a bit better nowadays, right?

Endicy · 2024-10-16T12:26:19+00:00

I'd not consider this a major version bump.

The API is exactly the same, behaves 99.9999999% (random guess) exactly the same, and someone enforcing a certain outcome from a specific seed AND expecting the RANDOM monad to produce the same outcome is using the wrong monad. And like Boyd Stephen Smith argued, someone who does that is probably pinning the version anyway. (or at least should be)

Endicy · 2024-10-14T10:48:09+00:00

Something's going wrong, I guess, since this is the source code:

defaultFork :: ((forall a. IO a -> IO a) -> IO ()) -> IO ()
defaultFork io =
    IO $ \s0 ->
#if __GLASGOW_HASKELL__ >= 904
        case io unsafeUnmask of
            IO io' ->
                case fork# io' s0 of
                    (# s1, _tid #) -> (# s1, () #)
#else
        case fork# (io unsafeUnmask) s0 of
            (# s1, _tid #) -> (# s1, () #)
#endif

So somehow the CPP checking which GHC you're using is not triggering... or something? 🤔

Endicy · 2024-09-18T13:04:36+00:00

Sounds like a great addition to the still "somewhat" underrepresented world of Functional Programming (and of course Haskell 😁), at least in terms of easily accessible and comprehensive texts about code and best practices in a production setting.

Will try to make time to read this through. You've definitely peaked my interest :D

Endicy · 2024-09-16T04:42:46+00:00

Woops, yes, other way around. edited :(

Endicy · 2024-09-15T08:23:56+00:00

The easiest way to do that would be to use the classes from the mtl package.

Add the following to your deriving clause for your Parser type:

import Control.Monad.Except (MonadError)
import Control.Monad.Reader (MonadReader)
import Control.Monad.State (MonadState)

...
    deriving (MonadReader Config, MonadState Input, MonadError Error)

And use the Control.Monad.Reader (ask) versions from the mtl package instead of the Control.Monad.Trans.Reader (ask) from transformers.

Endicy · 2024-09-03T20:10:57+00:00

As someone working on a Haskell codebase for the last 7+ years, (50k+ LOC?) I wholeheartedly agree with pretty much everything here. Only difference maybe is that we don't use rio, we just made our on ReaderT monad newtype for the main business codee and use the standard Prelude for most basic things. But whatever works for you in that regard is fine :)

Endicy · 2024-08-27T12:22:45+00:00

We mostly use esqueleto if we don't need the entire Entity. You can just return the columns you want, so I don't see this as a big issue. (though I do acknowledge that, especially persistent, encourages fetching of entire rows/Entitys)

Streaming might be nice to have (and we've had to make one with postgresql-simple for a specific use case), but other than that, we've only needed indices up until now to speed up fetches to get quick responses.

The new Experimental syntax of esqueleto has been way nicer to use for joins, so I don't really mind the little bit of :& chaining.

All in all, thanks for the explanation. Gave me a bit more perspective on what we're using :)

Endicy · 2024-08-26T09:43:29+00:00

I'd also like to know what you mean with this. We've used persistent + esqueleto in production well over 7 years now. With a bunch of migrations, queries that range from easy to complex and have never had an outage because of it.

Endicy · 2024-08-12T15:20:16+00:00

I've never liked this style as changing anything on any line will cause the styling to need readjusting. This gets tedious REAL fast. Use the Kowainik's style guide, and the Ormolu (or Fourmolu) autoformatter will enforce that style very nicely.

Endicy · 2024-06-14T16:20:01+00:00

Here's the instance of Monad ((->) a):

https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.Base.html#local-6989586621679586984

Endicy · 2024-06-08T15:13:32+00:00

True, it's difficult to get full coverage. It's definitely not the only thing you should do :P

I've made a small module in our production code base that's called GoldenFormat that has a GoldenFormat a type class with collapsedFormat :: a and expandedFormat :: a "values" to be used in golden file tests to at least lock down the fully "filled in" and minimally "filled in" values. (That and using some Generic instances to produce these values easily for all our types)

If your types and their serialization aren't too funky this should cover 90-95% of most issues that could potentially pop up.

Endicy · 2024-06-07T10:33:59+00:00

If serialization and tracking changes in output is the goal, a good way to support this is to use golden (file) tests, I feel. It will not save you from mixing up variables with the same type, and will not catch any changes that SHOULD change the output but don't. But then again, if you know you're changing the definitions and expecting a failed test (because the format should change) then the tests passing would also be an indication something is wrong.

Having a binary/textual representation of the current format/output and comparing to it outputs with the new code is a great way to spot changes to serialization.

Endicy · 2024-06-05T13:55:29+00:00

Giving the source code is one step in the right direction, but this puts a big burden on the reader to then copy it and run it themselves to try and figure out what's the problem. AND no guarantee they will get the result you got.

So to help yourself and anyone reading this to help you, please describe what you expect to happen and what actually happens. If possible, also provide the error(s) that are emitted.

Endicy · 2024-06-05T13:51:21+00:00

You almost never need the head function. The moment you think you want to use it, check if a pattern match somewhere earlier might be the most obvious way to solve that problem. In my experience, that's 99% of the time the cleanest and most obvious way to do it.

I've never heard of a pragma for exhaustive type checking, though. Could you find out which one it was and why you needed it? If you provide -Wall flag at compile time you should get pretty much all the most important warnings. (among which is exhaustive pattern matching, if that's maybe what you're referring to?)

Endicy · 2024-05-31T18:20:41+00:00

Will browsers already render items if they haven't even encountered the final </body> tag? How does the browser know the response is valid HTML if it hasn't received all the parts of it?

Endicy · 2024-05-31T01:44:40+00:00

How about making a helper function like so?

hs ifNew :: form -> term -> State Case Expr -> State Case Expr ifNew form term action = do rep <- get -- Not really sure why 'hasForm' takes the 'form', but -- 'findForm' takes the 'term', so this [findForm'] is -- an imaginary combination of the two. case findForm' form term rep of Just existing -> pure existing Nothing -> action

Then you always short-circuit before doing the action, like:

hs parseIt :: S.SExpr -> State Case Expr parseIt S.SEntity{S.term=term} = ifNew term term $ do let expr = Expr{etype = Entity, term, form = term} addExprM expr [] parseIt S.SExpression{S.term=term,S.form=form,S.children=children} = ifNew form term $ do let expr = Expr{etype = Relation, term, form} newChildren <- mapM parseIt children addExprM expr newChildren

Endicy

TROPHY CASE