You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content.
Not everything is tracing and debugging, sometimes you really need to output intermediate results for "normal", "production" purposes. One could still abuse Debug::Trace, but that would really be ugly.
I also object to that "everywhere". It is far easier to just dump an extra 'print' line somewhere inside a for-loop than into a `foldl (*) 1 $ map (+ 3) [17, 11, 19, 23]`. And that is an easy one...
With eventlog you have lightweight profiling and logging tool for "normal", "production" purposes. You can correlate different metrics of your program with your messages. This is not an abuse of Debug.Trace (notice the dot), it is normal state of affairs, regularly used and RTS is optimized for that use case.
I develop with Haskell professionally. That foldl example of yours is pretty rare and usually dealt with the QuickCheck [1], mother of all other quickchecks. Usually, the trace will be outside of the foldl application, but you can have it there in the foldl argument, of course.
Eventlog traces are RTS calls wrapped into unsafePerformIO, you are right. The trace part of eventlog is optimized for, well, tracing and is very, very lightweight. It is also safe from races, whereas simple unsafePerformIO (putStrLn $ "did you meant that? " ++ show (a,b,c)) is not.
In my opinion, eventlog traces make much better logging than almost anything I've seen.
Right now, developing with C++, I miss the power of Haskell's RTS.
> I develop with Haskell professionally. That foldl example of yours is pretty rare and usually dealt with the QuickCheck [1], mother of all other quickchecks. Usually, the trace will be outside of the foldl application, but you can have it there in the foldl argument, of course.
So actually not everywhere. And QuickCheck does something else entirely.
You missed the word "usually". You really, really do not need a print within the body of a loop of any tightness. But you can have it.
The foldl example of yours should be split into a property checking and controlling for expected properties of the input. The first part is done via quickcheck and second part usually is done with assertions and/or traces.
But nothing preclude you from having your trace there, inside foldl argument. This is clearly wrong place to have it, but still you can have it there.
So I repeat, you can have your traceEvents everywhere.
You're thinking of Haskell. F# was modelled after OCaml, which doesn't attract monad transformer stacks, and doesn't have a zoo of compiler extensions.
Well, they aren't actually compiler extensions but pre processor extensions (PPX).
And I would really like if OCaml would have had the possibility to add the needed PPXs names to the source file (like Haskell's compiler extensions). So as to not have to read the Dune (or whatever build system is used) file to get to know where `foo%bar` or `[@@foo]` is coming from and what is doing. But at least the usage of `ppxlib` nowadays should make PPXs "compose" aka. not stamping on each other's feet.
I haven’t used it for some time but OCaml certainly used to have a zoo of incompatible compiler extensions. Circa 2008 or so I once hit on the brilliant idea of using protobufs to get two mutually incompatible halves of an ocaml program to talk to one another only to find that required yet another compiler extension to work.
I'm pretty sure F# was modeled on both. There are some definite "Haskell-isms" in F#; if nothing else, monads are typically done in something more or less equivalent to the `do` notation (an `async` or `seq` block), for example.
The syntax superficially looks a lot like OCaml, but it doesn't do the cool stuff with OCaml functors and modules; you write it a lot more like Haskell most of the time.
Don Syme began with a port of Haskell to .Net, but SPJ convinced him that this is a bad idea, so he did choose OCaml. ("The Decision to Create F#", Page 9)
What do you mean by this?