add undefined to Prelude

[cdepillabout]

When I'm programming in Haskell, I often use undefined to get code compiling when I am just fleshing out an api/type signatues.

For instance, when doing something like authentication, I might write the following code:

type Email = String
type Password = String
data AuthInfo = AuthInfo Email Password

auth :: AuthInfo -> Boolean
auth = undefined

checkEmail :: Email -> Boolean
checkEmail email = length Email >= 7 

checkEmailAndPassword :: Email -> Password -> Boolean
checkEmailAndPassword = undefined

At first, I don't want to worry about how to write the auth and checkEmailAndPassword functions, so I leave them as undefined. After making sure the types line up and code compiles, I take out the undefined, and fill in the appropriate code.

I end up wanting undefined so often that I think it should go into the Prelude.

However, there are some downsides to putting it into the prelude:

• It makes the Prelude slightly bigger. It seems like most people want to keep the Prelude very small.
• It isn't type safe. I don't think the current Prelude has any functions that will blow up at runtime? Except maybe unsafeCompare and division by 0.

[zudov]

+1, I've been noticing myself doing different hacks like short-circuiting a function to get things compile, because of the lack of undefined and being lazy to import Unsafe.Coerce.

[garyb]

👎 for it being in the prelude, it's about the most unsafe function you can have so it definitely shouldn't be commonly imported - we try to avoid providing partial functions anywhere aside from Unsafe modules.

The only way I would be in favour of having this is if we included some kind of compiler hack so that there was an error thrown at the end of compilation if it was used, or for the generated runtime code to throw an error immediately (during initialisation) if the value is used.

[cdepillabout]

👎 for it being in the prelude, it's about the most unsafe function you can have so it definitely shouldn't be commonly imported.

I mostly feel the same way. But undefined is just so convenient for "type-driven" programming, I feel like it should be somewhere easily accessable.

Maybe the best solution would just be to make my own Prelude.

[garyb]

Yeah, it's definitely super useful. I've written Unsafe.Coerce.unsafeCoerce unit so many times it's not even funny. I considered adding it to purescript-debug too, as at least that's not intended to appear in production code at all as a whole too.

Supporting it natively in the compiler is my preference really, not sure what @paf31 thinks about that though? Alas we probably can't use _ like in Haskell due to ambiguity with record wildcards.

[garyb]

Actually I guess _ is a little different as it throws an error immediately (I think?) when a hole is reached. Ideally it would compile everything and then error about using a hole at the end, that way you know the rest of the program compiles first.

[cdepillabout]

Actually I guess _ is a little different as it throws an error immediately (I think?) when a hole is reached. Ideally it would compile everything and then error about using a hole at the end, that way you know the rest of the program compiles first.

Something that did this would be really nice.

Something along the same lines is that ghc flag that defers type errors to runtime.

[paf31]

👎 I'd much rather this were supported in a custom prelude, or in the compiler as a variation on typed holes. In either case, strictness is going to be an issue.

[garyb]

In either case, strictness is going to be an issue.

How so? I think compilation should fail when a hole is present, just after all the other work is done so you know it would compile if the hole had an implementation.

[paf31]

Ah, I was thinking it would be a warning like type wildcards (and ideally implemented using type wildcards).

[garyb]

Yeah, that's what I had in mind too - it desugars into something like (($hole :: forall a. a) :: _) but we take note if any of those desugarings happened, and if so we throw an error (or some kind of bail-out message) after typechecking has completed.

Even without the error it would be better than what we have now, but people don't necessarily always pay too much attention to warnings... especially when we have tons to fix in the core libraries. I get something like 400 warnings when building new-halogen slamdata 😆

[hdgarrood]

So can we close this, if we've decided we'd rather do it inside the compiler? That is, purescript/purescript#1283

[paf31]

Either way, I don't think it belongs in Prelude. A single-definition purescript-typed-holes library would be better IMO, or as you say, compiler support.