- Home
- Software
- Threads FAQ
- A glossary of terms used in threaded programming
- About the multithreaded programming FAQ
- After I create a certain number of threads, my program crashes [Unix]
- Asynchronous thread cancellation [Unix]
- How can I perform a join on any non-specific thread? [Unix]
- Mixing threads and signals [Unix]
- The history of threads
- What are the main families of threads?
- What is a thread?
- Why are reentrant library and system call interfaces good?
that looks significantly more straight-forward to me type- and behaviour- wise : )
It’s the right functionality, and at the list level it’s the right interface. Go for it.
How the differential calculus ends up in the prelude is destined to be a longer story.
Don’t you mean:
find :: Text -> Text -> [(Text,Text,Text)]
Since the middle element is always going to be the same, and identical to whatever the user passed in, is there any reason to include it in the output? Apart from the symmetry reasons I suppose. But returning a list of 3-tuples means we can’t use the standard `fst` and `snd` functions for extracting results.
> Since the middle element is always going to be the same, and identical to whatever the user passed in, is there any reason to include it in the output?
Once you start to do pattern matching instead of just substring search, the actually matched part may be different.
Yes, i ‘find’ the new version of ‘find’ a lot more intuitive!
I’ve used a version of this function when computing symbolic derivatives. D(fgh) = D(f) g h + f D(g) h + f g D(h) etc. It’s curious (but not completely surprising) that computing derivatives of functions makes use of one of the standard functions attached to derivatives of types.
Yes, we discussed revising find yet again on the #ghc channel a month or so ago. Despite having pushed you towards the one with type Text -> Text -> (Text, [(Text, Text)]), I realised I still was not happy with it either.
The one we discussed more recently is similar to what you are proposing now. I think the difference was that in what I suggested, the middle component of the tuple went to the end of the text, i.e. it was a prefix of the last component.
I think the rationale for that was that you already know what you searched for and we can save time and space by providing the full tail rather than making new texts by recomposing the search term with the trailing string.
This post seems to have vanished utterly.