New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add `undefined` to Prelude #44

Closed
cdepillabout opened this Issue Nov 11, 2015 · 12 comments

Comments

Projects
None yet
5 participants
@cdepillabout

cdepillabout commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@zudov

zudov Nov 11, 2015

+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.

zudov commented Nov 11, 2015

+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

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Nov 11, 2015

Member

👎 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.

Member

garyb commented Nov 11, 2015

👎 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

This comment has been minimized.

Show comment
Hide comment
@cdepillabout

cdepillabout Nov 11, 2015

👎 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.

cdepillabout commented Nov 11, 2015

👎 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

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Nov 11, 2015

Member

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.

Member

garyb commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Nov 11, 2015

Member

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.

Member

garyb commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@cdepillabout

cdepillabout Nov 11, 2015

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.

cdepillabout commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Nov 11, 2015

Member

👎 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.

Member

paf31 commented Nov 11, 2015

👎 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

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Nov 11, 2015

Member

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.

Member

garyb commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Nov 11, 2015

Member

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

Member

paf31 commented Nov 11, 2015

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

@garyb

This comment has been minimized.

Show comment
Hide comment
@garyb

garyb Nov 11, 2015

Member

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 😆

Member

garyb commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hdgarrood

hdgarrood Jan 7, 2016

Contributor

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

Contributor

hdgarrood commented Jan 7, 2016

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

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Jan 7, 2016

Member

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.

Member

paf31 commented Jan 7, 2016

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.

@paf31 paf31 closed this Jan 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment