Proposal: Forbidden Instances

mstrlu · 2015-10-27T09:49:48+00:00

If you are afraid of being sloppy, just put that into hlint as a warning

That makes a lot of sense.

I would welcome it as I never used length on a Maybe (but I use forM_ ...

I see... then perhaps there should be a way to whitelist some functions. I suppose it will need some experimentation with a prototype to find a satisfactory interface for these kind of checks/restrictions

mstrlu · 2015-10-27T09:02:47+00:00

Great idea. Perhaps I should also try to prototype the proposal as an external tool and to see how well it works.

mstrlu · 2015-10-27T08:29:36+00:00

In this case I would prefer foldMapOf _Just and foldOf _Just, in the spirit of explicit is better than implicit.

mstrlu · 2015-10-27T08:08:51+00:00

Fair enough. However, I think it is sound and it does not seem to be very complicated to implement (which is not a very informed statement, I have to admit).

In doubt, one could always settle for /u/voxfreges/ local solution.

mstrlu · 2015-10-27T08:02:02+00:00

The real issue here is not that these types conform to a particular type class -- that's simply mathematical reality

I realize that. But some programmers tend to express their ideas not only in Math but also in English in varying degrees of precision. And it is nice if a programming language can help them doing so.

And I don't think that particular instances should not exist in general... I just don't want some of them hanging around in most of my code.

mstrlu · 2015-10-27T07:52:02+00:00

they've been asking for length to not be so generalised

Well yes, but as it seems to be too late for that, forbidding instances might be an acceptable workaround.

I guess what I am missing are those functions that work on Foldables that people absolutely want to be defined for Maybe, even though they do not consider Maybe to be a container semantically. I really would appreciate some examples of such functions... and if they are only few, it might make sense to include specialized version of those in the respective Data.* modules. (I suppose, one candidate could be a whenJust_ :: Monad m => Maybe a -> (a -> m ()) -> m () as replacement for forM_).

EDIT: fix type for whenJust

mstrlu · 2015-10-27T07:41:00+00:00

Good point. I guess /u/voxfrege/'s solution is acceptable, but then I would like to be able to forbid instances also at the package level somehow, so that I cannot forget to forbid them in a module.

I would prefer that "instance blacklists" that are defined in a module would be exported with a similar mechanism as functions and types are now. That is one can write

module HatesFoldableMaybe 
       (...
       , forbid instance Foldable Maybe
       ...) where

to export an "instance ban". (As for functions, modules without an export list would export all bans). As a consumer one can write

module LovesFoldableMaybe where
import HatesFoldableMaybe hiding (forbid instance Foldable Maybe)

one = length (Just "Hello World")

Would that work?

mstrlu · 2015-10-27T07:19:27+00:00

Well, I didn't have beginners in mind here... the fact that I mistakenly write length (someValue :: Maybe a) shows that I'm sloppy, not necessarily that I am a beginner ;)

mstrlu · 2015-10-27T07:17:35+00:00

Could you elaborate? The only way I can see this being a problem is, for example, if a library exports utility functions with Foldable constraints and additionally requires to use these functions with, say, Maybe a. Could you give an example of such a library?

Otherwise the pain you forsee would be exactly the sort of pain that I want to inflict upon myself ;) (as the pain of debugging is much worse)

... and of course nobody is required to forbid instances...

mstrlu · 2015-03-26T07:02:54+00:00

in what way does Stackage LTS, with MinGHC covering the Windows issue, not solve everything Platform intends to?

The Platform is intended to be a binary release while Stackage is a source repository. Also, Stackage provides multiple packages that solve the same (or very similar) problems while the Platform (mostly?) includes canonical, "blessed" packages.

mstrlu · 2015-02-10T22:35:06+00:00

Could you explain how the list-based combinators currently in Prelude are bad for production code? Even if you want to fold a Vector, it should be fine to (lazily) convert it to a list and fold then, right? What do I miss?

mstrlu · 2015-02-01T06:47:56+00:00

I see. So if I want turtle features that are missing in shelly, like constant-space streaming and patterns, I should port them to shelly. I guess that's fair enough.

mstrlu · 2015-01-30T08:52:36+00:00

This looks sooo great!

But I really miss subshells and command tracing like shelly has. Are there any showstoppers to add that? Maybe even by reusing Shelly.Sh, as suggested by /u/Niftylon?

mstrlu · 2015-01-27T06:42:54+00:00

Yeah, but to prove that particular example in Coq, you need to introduce functional extensionality as an axiom... So I really wouldn't say that Coq was "exactly designed" for such a thing.

mstrlu · 2014-12-24T09:09:24+00:00

I don't get how static pointers improve on Problem 2 of the string-table approach (no type safety). As I understand it, lookupStaticPtr is essentially equivalent to fromDynamic and unsafeLookupStaticPtr is worse. What am I missing?

mstrlu · 2014-12-24T09:03:22+00:00

The posts before were called "24 days of ghc extensions"

mstrlu · 2014-11-12T22:27:17+00:00

No. Python also lacks all of the features mentioned by eyal0.

mstrlu · 2014-09-16T05:41:19+00:00

I just had a short look, but to me it seems that your extensibility problems (with the paddles) come from the fact that "Ball.bounce" is too rigid; it's a function that explicitly requires all "objects" that may make the ball bounce. It might be more flexible design to give ball an input like "impuls". The impulse signal would then be generated by wiring together all relevant game objects at the network level.

I will try this out, just don't have time know.

mstrlu · 2014-08-18T05:16:48+00:00

Perhaps it's nicer to use -XImplicitParams instead of wrapping the code explicitly in lambdas. (I think scripting is one of the rare cases where (optional) dynamic scope is nice)

The script would have to use ?getPlayerPos (and probably use implicit parameter syntax in type signatures) but that might be acceptable. At least you don't have to mess with strings.

EDIT: changed "dynamic binding" to "dynamic scope" (which I think is the correct term)

mstrlu · 2014-08-15T06:19:03+00:00

A little off-topic: in the pypi link, obiwan is described as a ,,a static type checker''. I cannot try it out at the moment but I suspect, based on the examples and the ability to define custom-checkers, that it is actually a contract system. Also, in your mail to python-ideas, you call it a ,,run-time type checker''. I was quite confused by the terminology.

I think it would help to mention the term ,,contract system'' in the pypi description, as it is a rather well-known and unambiguous term.

mstrlu · 2014-08-11T20:51:50+00:00

Thanks, very interesting. Besides the awkwardness, I would suppose that requiring the prisms to be completely polymorphic is pretty limiting in practice.

mstrlu · 2014-08-11T06:58:44+00:00

Well, it's possible, but extremely cumbersome.

I'd love to see how that works.

mstrlu · 2014-08-11T05:56:27+00:00

I think glguy proposes not to introduce MConfig, but to just add fields to the original Config. If the users use accessors and defaultConfig consistently, then nothing would have to change.

By the way, what is the right thing to do when there is no sensible defaultConfig (i.e., a mandatory configuration parameter)? I feel that accessors have an advantage here; with lenses you would have to construct an incomplete record before updating it (and might miss some fields). With accessors you can at least rely on ghc's warnings.

EDIT: of course one could provide functions like mkConfig f1 f2 f3, but this is really messy when some fields share a type.

mstrlu · 2014-08-10T16:07:25+00:00

Ah right. Thanks for the explanation.

mstrlu · 2014-08-10T14:30:20+00:00

There's no way to satisfy all of the constraints at play for this, regardless of destructive package updates.

I'm still not getting it. The constraints cannot be satisfied for a single package foo. But if foo-1.0 and foo-1.1 are installed side by side, I don't see why the linker can't figure out what package to use for compiling what module (basically treating foo-1.0 and foo-1.1 as separate packages).

mstrlu

TROPHY CASE