Thanks. I’ve filed an issue with a small reproducible example. https://github.com/elm-lang/elm-compiler/issues/1555 <https://github.com/elm-lang/elm-compiler/issues/1555>
> On Jan 12, 2017, at 10:57 PM, Max Goldstein <[email protected]> wrote: > > Very tentatively, this might be a bug. I would think that because model_page > is not capitalized, it should be interpreted as a value, not a module. That > should resolve to a record that you can access a field on. I think your code > can be unambiguously parsed. > > (Where you might get into trouble is if module Foo defines a record type > alias Bar, and there's also a module Foo.Bar. Though I still think that works > because these are functions, not records, and you can't call a module name.) > > On Thursday, January 12, 2017 at 4:12:29 PM UTC-8, Brian Marick wrote: > Short: I am getting this error when `model_page` is a record inside module > `Animals.Model` > >> Cannot find variable `Model.model_page.set`. >> >> 13| model |> Model.model_page.set (Page.fromLocation location) |> noCmd >> ^^^^^^^^^^^^^^ >> No module called `Model.model_page` has been imported. > > > The relevant import statement is: > >> import Animals.Model as Model exposing (..) > > > How do I tell the compiler that `Model` contains a record with a `set` field, > rather than that `Model.model_page` is a module with a top-level definition > named `set`? > --------------- > --------------- > > I’m using Monocle > http://package.elm-lang.org/packages/arturopala/elm-monocle/latest > <http://package.elm-lang.org/packages/arturopala/elm-monocle/latest> for > lenses with good success. It allows a reasonable approximation to the sort of > deep accessors and “setters” that are easier in dynamically typed languages. > For example, in Clojure, you can traverse a record with `(get-in record > [:profile :name]) > > What a lens library allows is a record with `get` and `set` functions that > work on a possibly-nested “part” of a larger whole. > > Because I’m obsessive about naming, I’ve being experimenting with how to make > lenses available to client code. I previously slopped them all into a giant > `Lenses.elm` namespace that was imported like this: > >> import Animals.Animal.Lenses exposing (..) > > > But I’d rather include the lens definitions alongside the `type alias` > declarations that they apply to. That is: > >> type alias Model = >> { page : Page.PageChoice > > … >> -- Boilerplate Lenses >> >> model_page : UpdatingLens Model Page.PageChoice >> model_page = lens .page (\ p w -> { w | page = p }) > > > My goal is to stop using “import Animals.Animal.Lenses exposing (..)”. > Instead, I’d have more specific imports and use qualified names like > `Model.pageLens`. That is, instead of an implicit reference to the kind of > the data the lens manipulates (“model_”), it’d be encoded in the module name > as a convention I’d follow (“Model.*lens”). > > But the compiler error above is getting in my way. > > For reference: > - the lens definitions > https://github.com/marick/eecrit/blob/621466af5e4c5f46595c903b28bd3cca91995586/web/elm/Animals/Animal/Lenses.elm > > <https://github.com/marick/eecrit/blob/621466af5e4c5f46595c903b28bd3cca91995586/web/elm/Animals/Animal/Lenses.elm> > - the use: > https://github.com/marick/eecrit/blob/621466af5e4c5f46595c903b28bd3cca91995586/web/elm/Animals/Pages/Update.elm#L13 > > <https://github.com/marick/eecrit/blob/621466af5e4c5f46595c903b28bd3cca91995586/web/elm/Animals/Pages/Update.elm#L13> > > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
