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

Feature Request: Add Semantic clue to functions that return Maybe #553

Closed
rebelwarrior opened this Issue Apr 7, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@rebelwarrior
Contributor

rebelwarrior commented Apr 7, 2016

There no way of knowing if a function like List.tail returns a Maybe a just from looking at the function name. I think there is an opportunity to add clues to the return value on the function name, adding meaning (semantics) to the function names.

In Ruby there is a "!" at the end of a method that alters the original element and a "?" to ones that return a boolean. Now I don't think neither the "!" or the "?" would work for the normal function name, but since I found myself using the Maybe.withDefault construct a lot, it could be built in.

For example:
List.tail list -> Maybe a
and
List.tail! default list -> List
by doing a

tail! default list = 
  case List.tail list of
    Nothing -> default
    Just x -> x 

They you'd know any method that has a "!" (bang) alias will return a Maybe without the bang.

@altaic

This comment has been minimized.

Show comment
Hide comment
@altaic

altaic Apr 7, 2016

In functional languages, one typically has the type signature at hand, but, beyond that, Maybe can be easily inferred by the purpose of a function: if there is a possibility that it will not be able to return an element, as is the case e.g. with List.head and List.tail, the result must be wrapped in a type that can represent both a value and no value. Maybe is the obvious choice here, though it's trivial (and oftentimes necessary) to make your own algebraic data type.

I don't think it's a good idea to introduce special syntax or even a naming convention for this. Type signatures are your friends!

altaic commented Apr 7, 2016

In functional languages, one typically has the type signature at hand, but, beyond that, Maybe can be easily inferred by the purpose of a function: if there is a possibility that it will not be able to return an element, as is the case e.g. with List.head and List.tail, the result must be wrapped in a type that can represent both a value and no value. Maybe is the obvious choice here, though it's trivial (and oftentimes necessary) to make your own algebraic data type.

I don't think it's a good idea to introduce special syntax or even a naming convention for this. Type signatures are your friends!

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Apr 18, 2016

Contributor

I think this has been considered on the mailing list in the past and been rejected. Even if not (yet), the mailing list would be the best place to have this discussion, since the issue tracker here is mainly for bugs and their fixes. So I'm closing the issue here. Of course, you can still take it to the mailing list (possibly after going through the mailing list's archive to see whether/what the potential previous discussion was like).

Contributor

jvoigtlaender commented Apr 18, 2016

I think this has been considered on the mailing list in the past and been rejected. Even if not (yet), the mailing list would be the best place to have this discussion, since the issue tracker here is mainly for bugs and their fixes. So I'm closing the issue here. Of course, you can still take it to the mailing list (possibly after going through the mailing list's archive to see whether/what the potential previous discussion was like).

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