Status Report - 11 July 2017

[Evan Czaplicki]

I recently got all of the major features of 0.19 working, so I am now working on cleaning everything up for an alpha that we can test out. I'm uncertain how long that will take, but the end is in sight.

Packages

Before I can do an alpha, I need to have the packages working with 0.19, so I have been working on the following things:

• Getting elm diff, elm bump, elm publish, and elm install working again. I looked through all the issues about all of these commands and tried to make as many fixes as possible. One result is that the publish process is quite a bit nicer. (Checks if README exists, verifies build, checks for local changes, etc.)
• Migrating all packages to some new formats. This means transforming elm-package.json to elm.json, normalizing all past licenses to SPDX, updating docs to have a consistent format, filtering out things that could not be migrated, getting info on release dates, etc. I have a pretty solid script for doing this, so I just need to run it again when it's closer to release to get all the latest packages.

With that work done, I can publish things to my test package website. So the next phase is to get all my libraries updated for 0.19 and put them there. I am trying to review issues as I go through the libraries to see if there are changes I should make. So far I have mostly focused on core.

Core

I have some tentative changes. It's unclear if everything here is the right move, so I am sharing so folks can make a note if anything seems like a big problem.

• Introducing a Json.Decode.Error type. This means you have structured errors and folks can display JSON errors in better ways than the default text. Excited to see what people do with this!
• Making a bunch of internal improvements to decoders as recommended in various issues.
• Making Json.Encode.list have an API that better matches common usage.
• Moving Basics.toString to Debug.toString, providing String.fromInt and String.fromFloat for use in production code. I know that having (a -> String) meant that people would accidentally be stringifying records when they absolutely needed a number, so this will be caught by the types now.
• Merging in the new Array implementation (Thank you Robin!)
• Merging in the new Random implementation (Thank you Max!)
• Moving the List.foldr implementation into Elm and making it faster (Thank you Robin!)

I am also thinking about moving certain things out of core. For example, I think regex should be its own package so that it is clearer that you should choose between a real parsing library and regex stuff. As I learn more about dates, I am thinking that it may make sense to have an elm-lang/date library that attempts to get things as right as possible. Not sure though.

Note: These things are all subject to change! Maybe they will be undone. I'm just sharing how things are at the moment!

Error Messages

I get pretty excited about error messages it seems, and one of the remaining tasks is to clean up all the error code. Part of the new command line tool is that the error format has been normalized so that every command produces errors in the same way. One improvement is when there is a problem in elm.json it is formatted in a much nicer way, more aware of JSON structure.

As I was going through package issues, I found this one. I am pretty excited about the resulting addition to the error message. I think thosee import hints will be really helpful for newcomers!

Next

I am not certain when the alpha will be ready to share. I am just chugging along, getting things working, cleaning things up, etc. I do not have a clear timeline for that, but the end is in sight.

The plan is to have a pretty long alpha/testing phase. Probably about a month. The ecosystem is larger now, so I want the folks who work on elm-format, elm-test, pluggins, etc. to have time to get things ready for 0.19 so we can have a really smooth transition on the public release day. I would like the alpha phase to be as long as needed to make that happen.

Excited to share all the improvements!

Evan

[Richard Feldman]

This is great! :D

 

One result is that the publish process is quite a bit nicer. (Checks if README exists, verifies build, checks for local changes, etc.)

"Check if README exists" is sweet, and reminded me to create this related issue: https://github.com/elm-lang/elm-package/issues/277

[Francesco Orsenigo]

Super excited about 0.19!

I am very happy about Debug.toString and Json.Decode.Error, I love to see that Elm is getting cleaner and cleaner.

[Frank Bonetti]

Evan,

You mentioned in the roadmap that "[t]he major focus of 0.19 will be creating “single-page apps” in Elm". You listed some potential features, like server-side rendering, tree shaking, code splitting, and lazy loading. You also said you would introduce a "much nicer alternative to [the] “routing” layer" (the alternative routing layer was also mentioned in this post by Richard Feldman).

Is that still a priority? I'm just curious if your goals for 0.19 have changed since you wrote the roadmap.

Thanks,

Frank

[Ilias Van Peer]

Really excited about the changes to decoders. I had already done some exploration along the same lines, introducing stronger error types: http://package.elm-lang.org/packages/zwilias/json-decode-exploration/3.0.0/Json-Decode-Exploration

And I always end up having a `(a -> Value) -> List a -> List Value` function, so that's pretty great to have as the default, too!

Op dinsdag 11 juli 2017 18:49:45 UTC+2 schreef Evan Czaplicki:

[Josh Adams]

As I learn more about dates, I am thinking that it may make sense to have an elm-lang/date library that attempts to get things as right as possible. Not sure though.

About this: Elixir introduced core Calendar types in 1.3 (see section titled "Calendar types and sigils") but didn't go much further. I like the way it has worked out as there are now packages out there that can explore different directions but since they have a common central data structure they are easy to use / swap out. From the docs:

The aim of the current implementation of the Calendar modules and its types is to provide a base for interoperatibility in the ecosystem instead of full-featured datetime API. This release includes basic functionality for building new types and converting them from and back strings.

Anyway, if you hadn't seen it I thought it might be useful source material when thinking further on the issue. Thanks!

[W. Brian Gourlie]

Evan,

I would suggest reaching out to John Skeet (https://twitter.com/jonskeet) and seeing if he'd be willing to review any datetime API questions.  His feedback, if he'd be willing to give it, would be invaluable.

Brian

[Janis Voigtländer]

The status report says that there will be a new function String.fromInt. That is the function for your valid use case. 

Am 15.07.2017 um 07:34 schrieb Christian Charukiewicz <c.charu...@gmail.com>:

Here's an example of how we're using toString in our production code:

...after some computation to determine how somethign should be positioned...

style
    [ ( "margin-top", toString topVal ++ "px" )
    , ( "left", toString leftVal ++ "px" )
    ]

Both topVal and leftVal in the examples above are Int values.

On Saturday, July 15, 2017 at 12:20:01 AM UTC-5, Christian Charukiewicz wrote:

Moving Basics.toString to Debug.toString

I assume that the implication here is that you never should have been using Basics.toString in production code.   Can someone explain what should be used instead?

Say I have an Int value in my model, and want to pass it into Html.text to display it to the user.  What should one be doing here if not using toString?  My assumption was that it was reasonable to use this function in the view.

On Tuesday, July 11, 2017 at 11:49:45 AM UTC-5, Evan Czaplicki wrote:

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/93c14e37-c559-4ca6-8880-a15e95b1b82a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Deedostar]

Great work, I love the choice for the Encode.list signature. Also the Encode.dict and Encode.keyValuePairs functions. Those changes will make encoding a lot easier to use. I have previously been thinking of writing a package that allows this style of writing, but having that as the default in 0.19.0 is awesome.