Lisplog

I cannot render a basic input, complains about type mismatch

via Elm - Latest posts by @samjk Sam on Thu, 10 Feb 2022 17:22:50 GMT

The short answer: The onBlur function needs just a Msg (ie a Msg constructor that takes no arguments) rather than String -> Msg like your PostIssue constructor which needs a string in order to become a real Msg.

The long answer: onBlur does not have access to the value in the input field, so it’s not the way to access what the user has typed in. To get the current value in the input field you’ll want to use onInput (defined in Html.Events and store the value in your Model (in something like a currentIssue record field). You need to store the value after each input event (ie keystroke) since the view function needs to know what to render - if the input after each keystroke is not stored in your model, any new input in the field won’t be rendered. The example in the Elm Guide shows you how to set up a basic text input.

If you want to treat the blur event as a sort of submit action, you should create a separate Msg constructor that takes no input for use with onBlur. Then in your update function, when that message is received it can look up the stored value in your model for the current input and add it to the list of issues (or otherwise handle it as desired).

Adding formatting options to Date/Time lib (elm-cldr)

via Elm - Latest posts by @Enkidatron Ben Thomas on Wed, 09 Feb 2022 23:25:32 GMT

I have written up a proposed API and added basic documentation to it.

This API changes the format functions as discussed above, and adds Cldr.Format.Options and Cldr.Format.OptionsBuilder. The options themselves are record types with default records available, so people can use the record update syntax if they want. There is also the OptionsBuilder module for those who prefer to stick with the helper functions. Both options are fully type-safe; people can use whichever they find most convenient.

What do you think of this API?

Click to view the poll.

What to do if you have a Non Exhaustive pattern match

via Elm - Latest posts by @eike Eike Schulte on Wed, 09 Feb 2022 18:14:48 GMT

“No runtime errors” is a very high priority for Elm. This means that you are not allowed to create functions that can fail. (Unless you’re implementing a core function like modBy 0.) The unsatisfying the solution of choosing a default value is probably your best choice. What I would do is:

1. Use Debug.todo in your code while developing to mark the impossible branches.
2. Write exhaustive tests and make sure you never run into those errors.
3. Replace Debug.todo by a default value.

(You might consider writing a custom wrapper around Debug.todo that already takes a value of the correct type so that you only need to change the definition of your custom wrapper before finalizing the module instead of replacing every occurrence of Debug.todo.)

Unfortunately, there are still two problems:

1. Having to use different code for development and production builds is annoying.
2. If you are tasked with producing a value of an unknown type (say you have a function MyTree a -> a and you know that the tree will always contain a value to return but you can’t prove it to the compiler), you’re out of luck and your “infinite recursion” solution is basically your only choice.

What to do if you have a Non Exhaustive pattern match

via Elm - Latest posts by @dta David Andrews on Wed, 09 Feb 2022 13:06:49 GMT

I would be interested in seeing the code that calls single_L as well. Since it’s already doing the pattern matching, can it pass in el, rlst, and rrst instead of rst?

How do i defualt a date model variable to todays date

via Elm - Latest posts by @passiomatic Andrea Peltrin on Wed, 09 Feb 2022 10:28:05 GMT

In addition to hrnxm comments, typically in Elm you can have a reasonable precise date/time value by having a “subscription” (see Commands and Subscriptions · An Introduction to Elm) that runs periodically and ask the system for current date/time.

That way, you store the value in your Model.currentDate and use wherever you want in your app. Also, to avoid having to deal with Maybe's you can have a init value passed from JS (see reply above).

What to do if you have a Non Exhaustive pattern match

via Elm - Latest posts by @nerfingen on Wed, 09 Feb 2022 08:34:23 GMT

First some code (there are 4 rotations (two double rotations and two single rotations) here a single
rotation (the double rotations have to look one deeper and have one patternmatch more):

single_L : a -> Tree a -> Tree a -> Tree a
single_L el lst rst =
  case rst of
    E -> undefined
    T el2 _ rlst rrst -> t1 el2 (t1 el lst rlst) rrst

some context E and T are constructors for the Tree a datatype. E : Tree a is for leaves and T : a -> Int -> Tree a -> Tree a -> Tree a for nodes. The Int is stores is the sized of the tree (that is used for balancing)

t1 : a -> Tree a -> Tree a is a ‘smart’ constructor computing the right size, so there will be never accedentily the wrong one. The module will only export safe operations that can’t produce trees with wrong size information (so it won’t export T for example (and also not t1 as it can produce non-search trees but this is not the point here)).

single_L already takes the outermost Tree node in a patternmatched form (as the parent has to do this match anyway and we have one less pattern match we need to do then).

Why do I know that the patternmatching can’t fail. I read the size information (of the parent) before and know that the tree must be balanced (to some degree) and this already tells me that there has to be a non-leave there. If there is, this module already contains a bug! It should only give the user functions that produce correct trees!

What I realy dislike about the identity (it would work of course (in theory everything that is of the correct type wouldd work)), is that it can hide bugs. I as a developer want to know when this code branch gets exercised (as something is clearly wrong then). If I put the identity there it would not only return some value that type checks, but also produce a correct search tree. So from the outside and in
functional tests it will look like everything works, even if there is a bug and the tree is not rebalancing correctly, and I want to catch that error and fix it. In other words writing the Identity there makes it harder to catch a potential bug! That sounds not good.

What to do if you have a Non Exhaustive pattern match

via Elm - Latest posts by @rupert Rupert Smith on Tue, 08 Feb 2022 22:54:18 GMT

Probably just do nothing. If you get two nodes, rotate them and return the rotated nodes. If you get anything else just return it as is - the identity function.

Maybe need to see some code to give a better recomendation.

Adding formatting options to Date/Time lib (elm-cldr)

via Elm - Latest posts by @wolfadex Wolfgang Schuster on Tue, 08 Feb 2022 19:36:50 GMT

The helper functions might also benefit from using phantom builder pattern to prevent someone from doing

dateTime
    |> setYear Numeric
    |> setDay Numeric
    |> setYear Short

This is really exciting to see though! Thank you for all of your hard work on it.

What to do if you have a Non Exhaustive pattern match

via Elm - Latest posts by @nerfingen on Tue, 08 Feb 2022 16:56:26 GMT

Hi, I tried to implement some sort of balancing search tree. For this I need some sort of rotation operation, these need to look a bit deeper (two nodes) into the tree, but I only call them if I already now that these exists (aka are none leafs). But to look into the tree I need to pattern match on their constructor. As Elm requires me to do this exhaustively I don’t know what to do in the Leave case of that pattern match (that can never occur).

I see the following options:

1. I return something of the required type (that would be bad, and sends me (in case of a bug that exercise this codebranch) into debug hell.
2. I wrap everything in Maybe (that is also terrible as this would propagate to the library api, and it is kind of stupid to have functions there that are Maybe, but never return Nothing) (aka the library will get unnecissary unusable)
3. I write a pice of nonterminating code that will inhabit every type and send the programm into an infinite recursion. (I hope I don’t need to justify, why I don’t like this option)

So what is the right thing todo?

Adding formatting options to Date/Time lib (elm-cldr)

via Elm - Latest posts by @Enkidatron Ben Thomas on Tue, 08 Feb 2022 16:46:34 GMT

I would like to expand my locale-aware date/time formatting library (elm-cldr) to support the more granular formatting options that would be required for it to support more use cases, e.g. Fluent.

My current plan is to add a new module Cldr.Format.Options:

module Cldr.Format.Options exposing (..)

type alias DateTimeOptions =
    { era : Maybe TextOption
    , year : Maybe NumberOption
    , month : Maybe NumberOrTextOption
    , day : Maybe NumberOption
    , weekday : Maybe TextOption
    , period : Maybe TextOption
    , hour : Maybe NumberOption
    , minute : Maybe NumberOption
    , second : Maybe NumberOption
    , fractionalSecondDigits : Maybe FractionalDigits
    , zone : Maybe NameOption
    , hour12 : Maybe HourType
    }

defaultDateTimeOptions : DateTimeOptions

type alias DateOptions = 
    { era : Maybe TextOption
    , year : Maybe NumberOption
    , month : Maybe NumberOrTextOption
    , day : Maybe NumberOption
    , weekday : Maybe TextOption
    }

defaultDateOptions : DateOptions 

type TextOption
    = Short
    | Long
    | Narrow

type NumberOption
    = Numeric
    | TwoDigit

type NumberOrTextOption
    = Text TextOption
    | Number NumberOption

type FractionalDigits
    = One
    | Two
    | Three

type NameOption
    = ShortName
    | LongName

type HourType
    = Hour12
    | Hour24

The FormatType in Cldr.Format.DateTime module would then be updated:

module Cldr.Format.DateTime exposing (..)

type FormatType 
    = DateOnly Length 
    | TimeOnly Length 
    | DateAndTime { date : Length, time : Length }
    | WithOptions DateTimeOptions

The Cldr.Format.Date module would also gain a FormatType and the format function would change signature to use it:

module Cldr.Format.Date exposing (..)

type FormatType 
    = WithLength Length 
    | WithOptions DateOptions

format : FormatType -> Locale -> Date -> String 

I am interested in feedback generally, but specifically in thoughts about these questions:

• Should the Cldr.Format.Options module have setX helper functions, e.g. setMonthNumber : NumberOption -> DatePlusOptions a -> DatePlusOptions a?
• Is the Cldr.Format.Date.format refactor ok? It would turn format Short myLocale date into format (WithLength Short) myLocale date. The alternative would be to add a second format function, like formatWithOptions : DateOptions -> Locale -> Date -> String, which is less consistent with Cldr.Format.DateTime.

Many thanks to everyone who has already provided feedback and interest in this project!