Re: [elm-discuss] Dot notation for default value fails on compilation

2016-07-30 Thread Austin B
Oh nice, okay. thank you.

On Saturday, July 30, 2016 at 2:43:36 PM UTC-7, Janis Voigtländer wrote:
>
> Known issue: https://github.com/elm-lang/elm-compiler/issues/635.
>
> Am Samstag, 30. Juli 2016 schrieb Austin Baltes :
>
>> Hi, I'm working on building a scatterPlot module for one of my Elm 
>> projects.
>>
>> This works (assigning Sp.defaultProps into defaultProps)
>> import ScatterPlot as Sp
>> defaultProps = Sp.defaultProps
>> init : (Model, Cmd Msg)
>> init =
>>   ( Model
>>   { defaultProps
>>   | series =
>>   [ { x = 0, y = 1000 }
>>   , { x = 1, y = 800 }
>>   , { x = 2, y = 700 }
>>   , { x = 3, y = 630 }
>>   , { x = 4, y = 590 }
>>   , { x = 5, y = 530 }
>>   , { x = 6, y = 500 }
>>   , { x = 7, y = 480 }
>>   ]
>>   , xRange = { lower = 0, upper = 10 }
>>   , yRange = { lower = 0, upper = 1000 }
>>   , chartWidth = 400
>>   , chartHeight = 200
>>   }
>>   , Cmd.none
>>   )
>>
>>
>> But this throws a compiler error
>> import ScatterPlot as Sp
>> init : (Model, Cmd Msg)
>> init =
>>   ( Model
>>   { Sp.defaultProps
>>   | series =
>>   [ { x = 0, y = 1000 }
>>   , { x = 1, y = 800 }
>>   , { x = 2, y = 700 }
>>   , { x = 3, y = 630 }
>>   , { x = 4, y = 590 }
>>   , { x = 5, y = 530 }
>>   , { x = 6, y = 500 }
>>   , { x = 7, y = 480 }
>>   ]
>>   , xRange = { lower = 0, upper = 10 }
>>   , yRange = { lower = 0, upper = 1000 }
>>   , chartWidth = 400
>>   , chartHeight = 200
>>   }
>>   , Cmd.none
>>   )
>>
>> I ran into something unexpected when parsing your code! 23| { 
>> Sp.defaultProps ^ I am looking for one of the following things: a 
>> closing bracket '}' a lower case name whitespace
>>
>> It'd be nice to use Sp.defaultProps to be more succinct and keep the new 
>> name space clean, but I haven't figured out how to do this yet.
>>
>> this is my implementation in ScatterPlot.elm
>> module ScatterPlot exposing (Point, Series, Range, Props, defaultProps, 
>> scatterPlot)
>> defaultProps : Props
>> defaultProps =
>>   { series = []
>>   , xRange = { lower = 0, upper = 100 }
>>   , yRange = { lower = 0, upper = 100 }
>>   , chartHeight = 100
>>   , chartWidth = 100
>>   }
>>
>> Thanks for any help; just starting in elm and working to get comfortable 
>> with modularizing code.
>>
>> -- 
>> 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 elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] How are deeply nested records updated or what alternatives are typically used?

2016-08-01 Thread Austin B
Hi,

I come from an OOP background and trying to make the leap to keeping all 
state in a single immutable data store, which has shown to be amazing as 
long as the system is small, but I am having trouble scaling up to anything 
beyond a toy app.

One big challenge is trying to update nested fields. For example if I want 
to change a forecast parameter in the following code:

-- Model
type alias Forecast =
  { parameters: Pf.ArpsParameters
  , production: List Float
  }
type alias Model =
  { primaryForecast: Forecast
  , secondaryForecast: Forecast
  }

-- Init

init : (Model, Cmd Msg)
init =
  (
{ primaryForecast =
  { parameters =
{ q = Nothing
, de = Nothing
, c = Nothing
, months = [0..48]
}
  , production = []
  }
}
, Cmd.none
  )


I end up with code like this:

update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  let
primaryForecast = model.primaryForecast
parameters = model.primaryForecast.parameters
  in
case msg of
  Q string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | q = toMaybe (String.toFloat string) } } }, 
message UpdateProduction)
  De string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | de = toMaybe (String.toFloat string) } } }, 
message UpdateProduction)
  C string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | c = toMaybe (String.toFloat string) } }}, 
message UpdateProduction)
  UpdateProduction -> ...


This seems unnecessarily verbose, and I'm unsure whether I am turning wrong 
with how I am structuring data or if I am trying to modify data incorrectly.

Thanks for any help!

Austin

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How are deeply nested records updated or what alternatives are typically used?

2016-08-02 Thread Austin B
Hi all, I really appreciate the ample feedback.

As I am new to the functional style, Sergey, your input is extremely 
helpful. For some reason, I felt like I was supposed to have all my 
modifiers and data structure definitions in one place, which became 
unmanageable. I am currently refactoring to fit that structure an, so far 
it feels a lot cleaner and "right".

One thing I liked is that the lack of syntax for this was it forced me to 
find the more accepted functional pattern. However, I'd vote Ambrose's 
pattern points for clarity if one were to me incorporated.

On Tuesday, August 2, 2016 at 11:44:25 AM UTC-7, Ambrose Laing wrote:
>
> When you say 
>
> { model.primaryForecast.parameters | q = ... }
>
> it seems to me that the type of the argument to the left of the '|'  is of 
> the same type as model.primaryForecast.parameters, so to me,
> this means something whose type and value is the same as 
> model.primaryForecast.parameters, except that q has been changed.
>
> My suggestion:
>
> { model | model.primaryForecast.parameters.q = ... }
>
> makes it clearer, I think, that what you want is of type the same as 
> model, but for which the sub sub sub field called q is changed.
> At least that is what I meant, if I didn't mention that.
>
> Then if I want something whose type is the same as a primaryForecast, but 
> whose q value has changed, one could write:
>
> { model.primaryForecast | parameters.q = ... }
>
> And if I want something of same type as model.primaryForecast.parameters, 
> but with q changed, one could write:
>
> { model.primaryForecast.parameters | q = ... }
>
> Anyway, this remains wishful, ... I am yet to grok the appeal of lenses.
>
> On Tuesday, August 2, 2016 at 12:34:24 PM UTC-4, Robin Heggelund Hansen 
> wrote:
>>
>> As far as I know, there is nothing against such a syntax, though I think 
>> the preferred syntax would be `{ model.primaryForecast.parameters | q = 
>> ...}`
>> It just haven't been implemented yet.
>>
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [elm-discuss] Re: How are deeply nested records updated or what alternatives are typically used?

2016-08-02 Thread Austin B
I think that would be the case. Although, I'd imagine I'd be using 
dictionaries in this situation once I get to the point of having "Maybe" 
data in this particular example.

I am beginning to understand the value of flattening data structures in 
this context.


On Tuesday, August 2, 2016 at 12:01:01 PM UTC-7, Duane Johnson wrote:
>
> I like the syntax. It's intent is clear. However, correct me if I'm wrong, 
> but it would only work for records of records, correct? No way to deal with 
> a "Maybe Forecast", right?
>
> On Tue, Aug 2, 2016 at 12:53 PM, Ambrose Laing  > wrote:
>
>> Correction: what I should have written is:
>>
>> { model | primaryForecast.parameters.q = ... }
>>
>> instead of 
>>
>> { model | model.primaryForecast.parameters.q = ... }
>>
>> because the former is more consistent with the notion that the field 
>> between the | and the = must exist inside the record to the left of the |, 
>> which one of the requirements of the the current syntax.
>>
>> Again.  Wishful.
>>
>>
>> On Tuesday, August 2, 2016 at 2:44:25 PM UTC-4, Ambrose Laing wrote:
>>>
>>> When you say 
>>>
>>> { model.primaryForecast.parameters | q = ... }
>>>
>>> it seems to me that the type of the argument to the left of the '|'  is 
>>> of the same type as model.primaryForecast.parameters, so to me,
>>> this means something whose type and value is the same as 
>>> model.primaryForecast.parameters, except that q has been changed.
>>>
>>> My suggestion:
>>>
>>> { model | model.primaryForecast.parameters.q = ... }
>>>
>>> makes it clearer, I think, that what you want is of type the same as 
>>> model, but for which the sub sub sub field called q is changed.
>>> At least that is what I meant, if I didn't mention that.
>>>
>>> Then if I want something whose type is the same as a primaryForecast, 
>>> but whose q value has changed, one could write:
>>>
>>> { model.primaryForecast | parameters.q = ... }
>>>
>>> And if I want something of same type as 
>>> model.primaryForecast.parameters, but with q changed, one could write:
>>>
>>> { model.primaryForecast.parameters | q = ... }
>>>
>>> Anyway, this remains wishful, ... I am yet to grok the appeal of lenses.
>>>
>>> On Tuesday, August 2, 2016 at 12:34:24 PM UTC-4, Robin Heggelund Hansen 
>>> wrote:

 As far as I know, there is nothing against such a syntax, though I 
 think the preferred syntax would be `{ model.primaryForecast.parameters | 
 q 
 = ...}`
 It just haven't been implemented yet.

>>> -- 
>> 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 elm-discuss...@googlegroups.com .
>> For more options, visit 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] How to check if all Maybes are specified and use values directly (without using "withDefault")

2016-08-03 Thread Austin B
I am trying to ensure that three arguments to a function are all not 
Nothing.

Right now I have this (below), which works, but uses "withDefault." I want 
to avoid this because the default values are meaningless and I want to 
clearly and fundamentally avoid any possible situation where a Nothing gets 
through to the "else" part

forecastProtected : Maybe Float -> Maybe Float -> Maybe Float -> (List Int) 
-> List Float
forecastProtected q d b months =
  if List.any (\m -> m == Nothing) [q, e, b] then []
  else
forecast
  (withDefault 0 q)
  (withDefault 0 d)
  (withDefault 0 b)
  months


 I am hoping to do something like this:
forecastProtected : Maybe Float -> Maybe Float -> Maybe Float -> (List Int) 
-> List Float
forecastProtected q d b months =
  let
params = {q = q, d = d, b = b}
  in
case params of
  { Just qF, Just dF, Just bF } -> forecast qF dF bF months
  { Maybe, Maybe, Maybe } -> []

which more clearly shows what I am trying to achieve. Could someone point 
me to the appropriate syntax for this? Also the 'F' in qF, dF, and bF are 
"Float" to avoid masking of variables (not sure how this happens in elm); 
it would be best if I could avoid this complication too.

Thanks everyone for all your help as I'm getting started!
Austin


-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [elm-discuss] How to check if all Maybes are specified and use values directly (without using "withDefault")

2016-08-03 Thread Austin B
Hey thank you!

On Wednesday, August 3, 2016 at 4:51:55 PM UTC-7, Joey Eremondi wrote:
>
> The key here is to use the wildcard _ in your pattern matching, which will 
> match any value. 
>
> You can also bundle your arguments in a tuple, without needing to use 
> records.
>
> forecastProtected : Maybe Float -> Maybe Float -> Maybe Float -> (List 
> Int) -> List Float
> forecastProtected q d b months =
>   case (q, d, b) of
>   ( Just qF, Just dF, Just bF ) -> forecast qF dF bF months
>   _ -> []
>
> Note also that your syntax was wrong in your case: Maybe is a type, not a 
> value, so you can never use it in a pattern match. You need to match either 
> against the constructors (Just, Nothing) or wildcards, or variables.
>
> On Wed, Aug 3, 2016 at 4:44 PM, Austin B > 
> wrote:
>
>> I am trying to ensure that three arguments to a function are all not 
>> Nothing.
>>
>> Right now I have this (below), which works, but uses "withDefault." I 
>> want to avoid this because the default values are meaningless and I want to 
>> clearly and fundamentally avoid any possible situation where a Nothing gets 
>> through to the "else" part
>>
>> forecastProtected : Maybe Float -> Maybe Float -> Maybe Float -> (List 
>> Int) -> List Float
>> forecastProtected q d b months =
>>   if List.any (\m -> m == Nothing) [q, e, b] then []
>>   else
>> forecast
>>   (withDefault 0 q)
>>   (withDefault 0 d)
>>   (withDefault 0 b)
>>   months
>>
>>
>>  I am hoping to do something like this:
>> forecastProtected : Maybe Float -> Maybe Float -> Maybe Float -> (List 
>> Int) -> List Float
>> forecastProtected q d b months =
>>   let
>> params = {q = q, d = d, b = b}
>>   in
>> case params of
>>   { Just qF, Just dF, Just bF } -> forecast qF dF bF months
>>   { Maybe, Maybe, Maybe } -> []
>>
>> which more clearly shows what I am trying to achieve. Could someone point 
>> me to the appropriate syntax for this? Also the 'F' in qF, dF, and bF are 
>> "Float" to avoid masking of variables (not sure how this happens in elm); 
>> it would be best if I could avoid this complication too.
>>
>> Thanks everyone for all your help as I'm getting started!
>> Austin
>>
>>
>> -- 
>> 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 elm-discuss...@googlegroups.com .
>> For more options, visit 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.