decodeValue docu not up to date

[jvoigtlaender]

One issue is that the code example in its documentation (http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Json-Decode#decodeValue) is still given in terms of Signals.

Another thing is that the documentation mentions Json.Value instead of Json.Encode.Value or Json.Decode.Value. That is confusing, because Json.Value does not exist as a type in core. One solution to this (other than renaming the three occurrences of Json.Value) could be to add the line

import Json.Decode as Json

to the code example.

[halfzebra]

Would it make sense to stop using module namespace in it's own documentation and use namespaces only for the external modules, used in the code snippets?

I find the import statement above slightly confusing.

What I would offer is to assume, that we're using the current module with:

import Json.Decode exposing (..)   -- for dcoumented
import Dict                        -- for external

How does that sound?

[halfzebra]

Would it make sense to stop using module namespace in it's own documentation and use namespaces only for the external modules, used in the code snippets?

I find the import statement above slightly confusing.

What I would offer is to assume, that we're using the current module with:

import Json.Decode exposing (..)   -- for dcoumented
import Dict                        -- for external

How does that sound?

[jvoigtlaender]

That would be a general policy issue for @evancz to decide. I agree that it would be good for the whole documentation of the core package to be consistent in some such way. I rely heavily on it in teaching, so am always willing to invest into improving it. If a decision were made about "this is how it's to be done throughout the documentation of this package", someone (you, me, someone) could go through all modules and enact that policy everywhere.

About your concrete proposal, I think it should be at least like "import Dict exposing (Dict)", i.e., so that types that are the "main type" of a module, having the same name, need not be given in qualified form.

[jvoigtlaender]

That would be a general policy issue for @evancz to decide. I agree that it would be good for the whole documentation of the core package to be consistent in some such way. I rely heavily on it in teaching, so am always willing to invest into improving it. If a decision were made about "this is how it's to be done throughout the documentation of this package", someone (you, me, someone) could go through all modules and enact that policy everywhere.

About your concrete proposal, I think it should be at least like "import Dict exposing (Dict)", i.e., so that types that are the "main type" of a module, having the same name, need not be given in qualified form.