[elm-discuss] Re: Would Enums make a good addition to Elm?

[Ambrose Laing]

I just realized that the sortBy function already allows you to sort a list 
by any sort criterion of your choice.  Which removes some of my concerns in 
the previous post.

On Friday, August 4, 2017 at 12:06:53 PM UTC-4, Ambrose Laing wrote:
>
> It seems like a minor detail that may come as a matter of course, but I'd 
> like to request that Bool's should also be comparable.  If Bools are not 
> comparable but you embed a Bool inside a tuple or a List or a Record, that 
> makes the larger type also not comparable.  Unless you decide to ignore the 
> Bool's but I think that is a less useful design choice IMO.
>
> Another general issue is what happens if the programmer does not like the 
> ordering provided by default for a particular type?  Ie. if we are in a 
> world where False < True, but I would prefer to use True < False, what do I 
> do.  Can there be a special function name ("compare" would be the most 
> obvious choice) such that if I define my own version of that function for 
> any given type, then it is used rather than the native default?  I think 
> that would be especially useful if you don't want to compare records 
> alphabetically by field name.
>
> Eg.  I want to sort records by name first and age second -- records of the 
> type { name: String, age: Int }.  I don't want to have to force myself to 
> rename them creatively to get the sort I want eg: { appelation: String, 
> maturity: Int } or worse {aName: String, zAge: Int}.
>
> In this instance the ability to override the sort order by defining a 
> compare function would be helpful.
>
> Alternatively for records, one could use the fact that the listing order 
> otherwise carries no information, and have the sort order for 
> records be implied by the listing order.  Just like unions in Haskell.  So:
>
> {name: String, age: Int} 
>
> would sort automatically by name first and age second.  But it would 
> remain legal to write {age = 22, name="Bob"}.  This is controversial 
> because it retains the fact that by definition the ordering of fields in 
> the record is irrelevant, and yet partially gives them meaning under 
> special circumstances.  There might also be issues if
> you define the record one way, and persist the data somehow, and then read 
> the data back in after compiling with a source code which changes the 
> listing order of
> the fields.  Nothing should change.  Yet, this solution will cause changes 
> in sorting behavior.
>
> All things considered, it might be better to allow the programmer to 
> define a compare function and have that used automatically for Sets and 
> Dicts.  Kind of typeclass-ish, but it may not necessarily require 
> typeclasses to be exposed in the language.  And let the listing order of 
> the field names in the source code have no significance.
>
> On Friday, August 4, 2017 at 11:04:07 AM UTC-4, Richard Feldman wrote:
>>
>> Having a deriving-esque way to generate encoders and decoders 
>>> automagically would be great, and would go a long way in solving the 
>>> hassle. (2) would also make my life easier.
>>> The problem I see with both deriving-esque auto coders (DEAC, patent 
>>> pending) and comparable union types, is the difficulty of implementation. 
>>> DEAC's seem like an advanced language feature that will take a while to get 
>>> into the language.
>>>
>>
>> Oh yeah - worth noting that this implementation already exists for 
>> records. Ports do it. If you send a record out a port, or bring it in 
>> through a port, under the hood what's happening is an encoder (or decoder, 
>> respectively) gets generated automatically from the type.
>>
>> Doing it for union types as well would largely be a matter of designing a 
>> nice serialization and deserialization format; the type information is just 
>> as easy to access as it is for records. 
>>
>

-- 
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: Would Enums make a good addition to Elm?

[Ambrose Laing]

It seems like a minor detail that may come as a matter of course, but I'd 
like to request that Bool's should also be comparable.  If Bools are not 
comparable but you embed a Bool inside a tuple or a List or a Record, that 
makes the larger type also not comparable.  Unless you decide to ignore the 
Bool's but I think that is a less useful design choice IMO.

Another general issue is what happens if the programmer does not like the 
ordering provided by default for a particular type?  Ie. if we are in a 
world where False < True, but I would prefer to use True < False, what do I 
do.  Can there be a special function name ("compare" would be the most 
obvious choice) such that if I define my own version of that function for 
any given type, then it is used rather than the native default?  I think 
that would be especially useful if you don't want to compare records 
alphabetically by field name.

Eg.  I want to sort records by name first and age second -- records of the 
type { name: String, age: Int }.  I don't want to have to force myself to 
rename them creatively to get the sort I want eg: { appelation: String, 
maturity: Int } or worse {aName: String, zAge: Int}.

In this instance the ability to override the sort order by defining a 
compare function would be helpful.

Alternatively for records, one could use the fact that the listing order 
otherwise carries no information, and have the sort order for 
records be implied by the listing order.  Just like unions in Haskell.  So:

{name: String, age: Int} 

would sort automatically by name first and age second.  But it would remain 
legal to write {age = 22, name="Bob"}.  This is controversial because it 
retains the fact that by definition the ordering of fields in the record is 
irrelevant, and yet partially gives them meaning under special 
circumstances.  There might also be issues if
you define the record one way, and persist the data somehow, and then read 
the data back in after compiling with a source code which changes the 
listing order of
the fields.  Nothing should change.  Yet, this solution will cause changes 
in sorting behavior.

All things considered, it might be better to allow the programmer to define 
a compare function and have that used automatically for Sets and Dicts. 
 Kind of typeclass-ish, but it may not necessarily require typeclasses to 
be exposed in the language.  And let the listing order of the field names 
in the source code have no significance.

On Friday, August 4, 2017 at 11:04:07 AM UTC-4, Richard Feldman wrote:
>
> Having a deriving-esque way to generate encoders and decoders 
>> automagically would be great, and would go a long way in solving the 
>> hassle. (2) would also make my life easier.
>> The problem I see with both deriving-esque auto coders (DEAC, patent 
>> pending) and comparable union types, is the difficulty of implementation. 
>> DEAC's seem like an advanced language feature that will take a while to get 
>> into the language.
>>
>
> Oh yeah - worth noting that this implementation already exists for 
> records. Ports do it. If you send a record out a port, or bring it in 
> through a port, under the hood what's happening is an encoder (or decoder, 
> respectively) gets generated automatically from the type.
>
> Doing it for union types as well would largely be a matter of designing a 
> nice serialization and deserialization format; the type information is just 
> as easy to access as it is for records. 
>

-- 
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: Drawing Directed Graphs (?) in Elm

[Ambrose Laing]

There is also this one:

https://github.com/mstefaniuk/graph-viz-d3-js

On Friday, August 4, 2017 at 8:20:23 AM UTC-4, Ambrose Laing wrote:
>
> This may be helpful.
>
> https://github.com/mdaines/viz.js/
>
> It should give you exactly the solution you cited.  But I believe you need 
> to figure out hooking it up to elm using ports.
> I have no experience with this particular project myself, but I do use 
> graphviz and had heard of this one.
>
>
> On Friday, August 4, 2017 at 5:51:23 AM UTC-4, Michael Jones wrote:
>>
>> Hi,
>>
>> I am interested in exploring the automatic layout of 
>> flow-chart-like-structures in Elm. I'm not sure of the exact terminology. I 
>> think directed graphs covers it.
>>
>> Perhaps a solution like the one presented in this paper: 
>> http://www.graphviz.org/Documentation/TSE93.pdf
>>
>> I would be happy to try to tackle it myself but I'm also curious if 
>> anyone is already looking into it? I have done some searching and have 
>> found various graph libraries but not tackle the idea of doing an automatic 
>> layout.
>>
>> I am not so interested in force-layouts as they product more organic 
>> results which do not match my use case.
>>
>> Related results:
>> - Fixed diagrams: https://github.com/vilterp/elm-diagrams
>> - Drawing tree structures: https://github.com/brenden/elm-tree-diagram
>> - Drawing arc diagrams: 
>> https://github.com/justinmimbs/elm-arc-diagram/tree/1.0.0
>> - Graph editor with dot export: 
>> https://github.com/jhrcek/elm-graph-editor
>> - Visualisation library which includes Force Layouts: 
>> https://github.com/gampleman/elm-visualization
>>
>> Cheers,
>> Michael
>>
>

-- 
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] List of all members of a union type

[Ambrose Laing]

If you really want a solution and want it now, here is a solution using the 
unix-based m4 text/macro processor -- don't know if this has been mentioned 
in the other threads on this topic.   It should be possible to write a file 
like so (maybe named *YourFile.elm.m4*):


## The following is the only line that lists the state names!
define(`stateList', ``Alabama', `Alaska', `Arizona', `Arkansas'')dnl

type AState = m4AltSep(stateList)

allAStates = m4ListStates(stateList)

allAStateNames = m4ListStrings(stateList)

When you run it through m4 with the right macro definitions, you will get 
this:


## The following is the only line that lists the state names!

type AState = Alabama | Alaska | Arizona | Arkansas

allAStates = [ Alabama, Alaska, Arizona, Arkansas ]

allAStateNames = [ "Alabama", "Alaska", "Arizona", "Arkansas" ]


And the required definitions are (maybe this can be in *elmdefs.m4*):

define(`m4foreach',`ifelse(eval($#>2),1,
`pushdef(`last_$1',eval($#==3))dnl
`'pushdef(`$1',`$3')$2`'popdef(`$1')dnl
`'popdef(`last_$1')dnl
`'ifelse(eval($#>3),1,`$0(`$1',`$2',shift(shift(shift($@')')')dnl
define(`m4AltSep', `m4foreach(`xstate', `xstate`'ifelse(last_xstate,0,` | 
')',$@)')dnl
define(`m4ListStates', `[ m4foreach(`xstate', 
`xstate`'ifelse(last_xstate,0,`, ')',$@) ]')dnl
define(`m4ListStrings', `[ m4foreach(`xstate', 
`"xstate"`'ifelse(last_xstate,0,`, ')',$@) ]')dnl

The macros are adapted from M. Breen's page  
especially 
the section on loops.
The command that makes it work:

cat elmdefs.m4 YourFile.elm.m4 | m4 > YourFile.elm

The price you pay is having to somehow integrate this command into your 
build flow -- it is easy enough using unix *make*.  And if your build tool 
would need to understand that when the .elm.m4 file changes, the 
.corresponding elm file should be rebuilt.  And of course if you are using 
elm-format that will work at the .elm level and it will not understand the 
.elm.m4 level.  Finally because it is a source-level modification, it does 
not resolve any of the semantic issues that have been raised in this 
thread.  It just deals with the very narrow enum case.  Given this extra 
work to set this up, some may opt to just live with the risk of getting 
your lists/enumerations out of sync, ... this can only be practical when 
your codebase has a lot of Enums like this which need to be kept in sync.

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Ambrose Laing]

One could define fold as a generic operation that replaces the empty list 
with a constant (for example an identity element) and replaces the "cons" 
operator with a function that takes an element and a partial result.  This 
is consistent with other ways to define generalized folds over recursive 
data structures.  For example for trees you can replace the leaf node with 
a constant and replace the internal node with a binary function.  The key 
idea here is that fold directly reflects the natural structure of the 
underlying data structure.  ie, the way you would draw a picture of the 
underlying data structure is exactly the picture of the execution order. 
 If we are consistent with this, then fold will be defined for lists to be 
the same as foldRight for lists.  For more detailed exposition to motivate 
this definition, see the paper "Merging Monads and Folds for Functional 
Programming", by Meijer and Jeuring. 


One could also define a fold (as scala does) to be not-necessarily-linear 
-- the execution order is unspecified and left up to the implementer.  So 
in scala, a fold can split up a list into many pieces (sublists) and 
process the sublists in parallel, and then fold them up to obtain the final 
answer.  In this case, it is not necessaria foldLeft or a foldRight.  It 
could actually be a fold-from-the-middle or even 
fold-from-many-places-in-the-middle.  In order to make sure the answer is 
well-defined, the folding operator is required to be associative.

IMO it would be a good idea to avoid confusion with these alternative 
semantics by not reusing the name "fold" at all, or else adopting one of 
the conventional meanings (if we can agree what the most common meaning is).

On Thursday, October 20, 2016 at 11:32:12 AM UTC-4, Max Goldstein wrote:
>
> Normally I'm opposed to syntax or name changes. But I think this or some 
> variation is a good idea. (Maybe foldl becomes fold, since it's usually the 
> one you want.)
>
> That said, it's all subject to Evan's approval. 
>

-- 
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 to insert an object into a list from a form

[Ambrose Laing]

I would modify the model to also contain a name, description and price, at 
the top level.  These are uncommitted values.  By uncommitted I mean that 
it should be possible to change any one of these without changing the 
others, and yet your master list of all the items will not change because 
you have not clicked the Run button yet.  This is because naturally it is 
impossible to change all three items at once.  You change one, and you need 
somewhere to hold the value you have changed while you modify the next one, 
but before you commit a group of three of them as one article into your 
master list.  It is only when you click Run that these three values are 
copied into an Article and the article is appended to the List of articles 
in your model.  Hope that helps.

On Monday, October 10, 2016 at 7:54:13 AM UTC-4, Did wrote:
>
> Hi there,
>
> I'm pretty new to elm, so maybe this is a common issue.. I have a list of 
> articles, each article is composed of an id, a name, a description and a 
> price. I have also, in the UI, 3 fields in order to create a new article 
> and add it to the list by clicking to the "click" button. All articles are 
> listed in a table.
>
> But I really don't understand how to resolve this... Maybe by having an 
> article object and "bind" its properties with a onInput event on their 
> corresponding field, but even by doing that, I'm not sur how to implement 
> the update function. For now, the update function returns the model because 
> I don't know how to implement each cases...
>
> Thanks for your help!
>
> Here is the code :
>
> import Html exposing (..)
> import Html.App as App
> import Html.Events exposing (onClick, onInput)
> import Html.Attributes exposing (..)
>
> main =
>   App.beginnerProgram {model = model, update = update, view = view}
>  
> type alias Model = List Article
>
> type alias Article = 
>   { 
> id: Int
>,name: String
>,description: String
>,price: String
>   }
>
> model: Model
> model = [{
> id = 1
>,name = "Test 1"
>,description = "Description..."
>,price = "10.0"
>   }]
>  
>
> type Msg = 
>Run | UpdateName String | UpdateDescription String | UpdatePrice String
>
>
> update: Msg -> Model -> Model
> update msg model =
> case msg of
> UpdateName newName -> model
> UpdateDescription newDesc -> model
> UpdatePrice newPrice -> model
> Run -> model
>
>
> view model =
>   let th' field = th [] [text field]
>   tr' article = tr [] [ td [][text article.name] 
>,td [][text article.description]
>,td [][text article.price]
>   ]
>   in
>   div []
>   [input[type' "text", placeholder "Enter a name...", onInput UpdateName][]
>,input[type' "text", placeholder "Enter a description...", onInput 
> UpdateDescription][]
>,input[type' "text", placeholder "Enter a price...", onInput 
> UpdatePrice][]
>,div[]
>[
>  input[type' "button", value "click", onClick Run][]
>]
>,div[]
>[
> table [] [
>   thead[][tr [](List.map th' ["name", "description", "price"])]
>  ,tbody[](List.map tr' model)
> ]
>]
>   ]
>

-- 
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] No Runtime Exceptions - Still not computing

[Ambrose Laing]

Elm has datatypes called Maybe, Result and Task.  You mentioned Maybe 
already, which may be understood to mean a list of at most one item, or a 
data type with either missing data, or an unspecified error.  Result allows 
you to specify the error and propagate it, so take a look at that.  Then 
look at Task also.

http://package.elm-lang.org/packages/elm-lang/core/4.0.5/Result

On Thursday, October 6, 2016 at 11:33:43 PM UTC-4, Dave Ford wrote:
>
> Duane. Don't get me wrong. I prefer compile errors over runtime errors.  
> And if Elm can catch more errors at compile time without adding a bunch of 
> noise to my code that is a good thing obviously.
>
> But runtime errors are unavoidable.  It's not possible for the compiler to 
> catch every possible error condition. The question is,  does the language 
> have an elegant mechanism to deal with runtime exceptions? Especially in a 
> separate flow from the normal return value. 
>
> And from what I am hearing the answer is either no or no one is telling me 
> what it is.  
>
> So my question is: does Elm have something similar to throw/raise?
>
> On Oct 6, 2016 8:07 PM, "Duane Johnson"  
> wrote:
>
>>
>> On Thu, Oct 6, 2016 at 8:13 PM, Dave Ford > > wrote:
>>
>>> 2. *Runtime Exception. *Like a NullPointerException or an 
>>> IllegalArgumentException. I *love* these kind of bugs. Super easy to 
>>> find. Super easy to fix. A stack trace tells me exactly where to look. 
>>> These kind of exceptions have never been a thorn in my spine.
>>
>>
>> I'm genuinely surprised by your experience / reaction to runtime 
>> exceptions. My experience has been the exact opposite. Runtime exceptions 
>> can only be found through tedious exercise of every branch of code through 
>> all possible states, which creates a horrible burden on the developer who 
>> wishes to not have to worry about how old code might break as new code is 
>> added and the size of the project (and possible states) increases.
>>
>> When you say you love these kind of bugs, are you saying you like to go 
>> through your program and try this or that input and see if you can get it 
>> to throw an exception? What if you change the code somewhere else, but in a 
>> section of code that *might* affect other parts of your codebase--do you 
>> then go back to each of the other parts of your program and try to think of 
>> new ways that exceptions might have be able to be raised?
>>
>> I wrote part of a large (very large--possibly the largest open source 
>> Ruby app, called Canvas) and at some point, the complexity becomes 
>> mindboggling. It slows down project development when you can't check (at 
>> compile-time) whether a change here affects the code *there* (and *there*, 
>> and *there*, and, does it affect *this* code?) The motivation of Elm, as I 
>> see it, is to push as many classes of errors as possible into the 
>> compile-time error space. Not all can be pushed into that domain, but many 
>> can--and that's considered an advantage because as project size increases, 
>> you can still move with confidence.
>>
>> Possibly related--I found it instructive to listen to Richard's "Making 
>> Impossible States Impossible" presentation at ElmConf.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/00CgYDiMvBI/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] Re: Long form: how to handle model, Msg and update?

[Ambrose Laing]

Something like this can be made to work, if you don't care about relaxing 
the type safety which is provided by your current approach:


initialModel = 
{ form : Dict.fromList
[ ("applicant",
{ label = "Applicant name"
, selected = True
, value = ""
})
, ("year",
{ label = "Year"
, selected = True
, value = ""
})
, ("state",
{ label = "State"
, selected = True
, value = ""
})
…
]
…
} 


type Msg
= Update String String


update msg model =
case msg of
Update fieldName query ->
let
entry =
Dict.get fieldName model.form

newEntry =
{ entry | value = query }

form = Dict.insert fieldName newEntry model.form
in
( { model | form = form }, Cmd.none )


You should make it safer by including run-time checks that the first string 
argument (fieldName) is one of your 20 possibilities, before doing the 
above replacement, and if it isn't then you should specify what to do 
(maybe ignore it).

On Monday, September 12, 2016 at 12:08:25 PM UTC-4, Eduardo Cuducos wrote:
>
> Hi all,
>
> I'm writing an application that has a “advanced search” form. In my 
> context it means a form with approx. 20 input fields.
>
> As a newbie the only way I could think of coding this is quite repetitive. 
> I bet that there is a more cleaver and a DRY way to do it, but I couldn't 
> figure out how. Any ideias?
>
> This is the terrible idea I have in mind:
>
> 1. My initial model would have 20 form fields definition like that:
>
> initialModel = 
> { form :
> { applicant =
> { label = "Applicant name"
> , selected = True
> , value = ""
> , msg = UpdateApplicant
> }
> , year =
> { label = "Year"
> , selected = True
> , value = ""
> , msg = UpdateYear
> }
> , state =
> { label = "State"
> , selected = True
> , value = ""
> , msg = UpdateState
> }
> …
> }
> …
> }
>
>
> 2. Consequently my type Msg would have another 20 very similar fields:
>
> type Msg
> = UpdateApplicant String
> | UpdateYear String
> | UpdateState
> | …
>
> 3. And my update would have 20 very similar cases:
>
> update msg model =
> case msg of
> UpdateApplicant query ->
> let
> applicant =
> model.form.applicant
>
> newApplicant =
> { applicant | value = query }
>
> currentForm =
> model.form
>
> form =
> { currentForm | applicant = newApplicant }
> in
> ( { model | form = form }, Cmd.none )
>
> UpdateYear query ->
> let
> year =
> model.form.year
>
> newYear =
> { year | value = query }
>
> currentForm =
> model.form
>
> form =
> { currentForm | year = newYear }
> in
> ( { model | form = form }, Cmd.none )
>
> UpdateState query ->
> let
> state =
> model.form.state
>
> newState =
> { state | value = query }
>
> currentForm =
> model.form
>
> form =
> { currentForm | state = newState }
> in
> ( { model | form = form }, Cmd.none )
>
> Many thanks,
>
>

-- 
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] Human readable

[Ambrose Laing]

At https://groups.google.com/forum/#!msg/elm-discuss/h9VbI4QrJQQ/Z26BaomUAwAJ

On Wednesday, August 17, 2016 at 1:26:46 PM UTC-4, Ambrose Laing wrote:
>
> To everyone who wanted to have the elm-compiler produce line numbers and 
> column numbers that can help a traditional editor (like emacs for example) 
> to navigate to error locations:  I discussed this a bit with Evan, and he 
> suggested working with the json output, so then I came up with this 
> solution for now:
>
> Please see: http://github.com/aklaing/call-elm-make
>
> Let me know if you find this helpful, especially you're not an emacs user 
> :-)
>
> Thanks,
>
> Ambrose
>
>>
>>

-- 
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] Human readable

[Ambrose Laing]

To everyone who wanted to have the elm-compiler produce line numbers and 
column numbers that can help a traditional editor (like emacs for example) 
to navigate to error locations:  I discussed this a bit with Evan, and he 
suggested working with the json output, so then I came up with this 
solution for now:

Please see: http://github.com/aklaing/call-elm-make

Let me know if you find this helpful, especially you're not an emacs user 
:-)

Thanks,

Ambrose

>
>

-- 
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: Should [ 1..5 ] exist?

[Ambrose Laing]

To be completely honest, I would much prefer to keep the notation, but 
suggest a different possible solution.
I would not complain if the notation goes away, but I would also like to 
hear how you feel about the following possible alternative:

Maybe we need a formal way to associate keywords with functions and 
notations in elm.  In your specific use case, the way this
would work is that "range" is a keyword for [ a .. b ].  So on the elm 
documentation page, if you type "range", it will first give you
all the functions which contain range as a substring (the way it does now), 
and then after that also list all functions and/or notations
that contain "range" as a keyword, which should pull up [ a .. b ].

Another example that has bitten me personally, coming from scala, is I want 
to know how to do a flatMap in elm.  As it turns out, it
is called concatMap in elm.  If I were coming from Haskell, I would be 
busily searching for "bind" or something similar.  The concepts
do not have to match exactly, they just have to be close enough, to make 
"flatMap" and "bind" become keywords for "concatMap".
So if I go search for "flatMap" in the docs, I should easily find 
"concatMap", even when elm itself does not have a flatMap function.
If we went crazy with this, most keywords / common functions from other 
languages would be listed as keywords for their elm equivalents
and it could make life easier, I imagine.

What do others think of this?

The arguments against this are that we can't list every possible relevant 
keyword that might be helpful.  My response is that we just do
some of the obvious ones and if possible make it so that the keywords can 
be crowdsourced from elm users.

The only thing is I feel bad suggesting more work that Evan or someone else 
will have to do.



On Thursday, August 4, 2016 at 4:21:55 PM UTC-4, Richard Feldman wrote:
>
> Currently the way you do ranges (like, say, to create the list [ 1, 2, 3, 
> 4, 5 ]) is this:
>
> [ 1..5 ]
>
> This comes up super infrequently, and whenever it does, it's hard to 
> Google for - when you want to know things like "can I use variables in 
> there?" "is [1..5] going to give me 1,2,3,4,5 or 1,2,3,4?" etc.
>
> I'd rather drop this special syntax in favor of a simple function:
>
> List.range : number -> number -> List number
>
> It'd make for one less piece of syntax to learn, would simplify the 
> compiler, and personally I'd find it more convenient to use than the 
> special syntax. This way when I want to know how it works I can look it up 
> in the List docs like normal!
>
> Thoughts?
>

-- 
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?

[Ambrose Laing]

In the previous posting there is a bug -- I should simply use

e = ...

instead of

e = f ...

If you want to make the previous write up work, then you need 

f : X -> E 
and 
... is of type X

rather than the following which is a mistake.

f: E  -> X
and
... is of type E



On Tuesday, August 2, 2016 at 9:05:50 PM UTC-4, Ambrose Laing wrote:
>
> You're right that what I wrote earlier has no way to deal with a Maybe 
> field.  I think it could be generalized to handle Maybe fields, but then we 
> could also think of something that is neither a record nor a Maybe of a 
> record, ...
>
> Anyway, it is not at all pretty but here is a quick idea.  First let me 
> summarize the previous idea using the notation that works best for Maybes:
>
> Suppose that 'a' is of type A, a record, which contains a field called b 
> of type B, which is a record, which contains a field called c which is also 
> a record of type C, which contains a field called d, which is also a record 
> of type D, which contains a field called e, of any type E, and that f is a 
> function of type f : E -> X where X is any type.  Also suppose that ... is 
> an arbitrary elm expression of type E.
>
> Then what I wrote before suggests that we can write:
>
> a.b.c.d.e : E
>
> and, since
>
> a.b.c.d : D
> we can write
> { a.b.c.d | e = f ... } : D  -- where ... is any elm expression which is a 
> valid argument for f.
>
> Also, we have
>
> a.b.c : C
> as well as
> { a.b.c | d.e = f ... } : C
>
> and so on.  So I like this notation up until this point -- it is exactly 
> as I described in my previous post.  However in what follows, I hope to 
> show that adding Maybe's is possible but rather ugly, and while I think it 
> is possible I don't recommend it.  It is just a mental experiment.
>
> In Swift there is a ? operator for dereferencing fields conditionally.
>
> So if everything is just as described above except that c is of type Maybe 
> C, where C is a record type as described above, then we can write this in a 
> similar style to Swift:
>
> a.b.c?.d.e : Maybe E
>
> meaning that if the value of a.b.c is (Just cValue), then a.b.c?.d.e is 
> (Just cValue.d.e)
> but
> if a.b.c is Nothing, then a.b.c?.d.e is Nothing.
>
> Similarly we could have
>
> a.b.c?.d : Maybe D
>
> with the obvious semantics.
>
> However a.b : B
>
> and a : A
>
> I am not a Swift person, but based on my limited understanding of that 
> language, that is what their ? dereference operator means.  Anyone please 
> correct me here.
>
> And if that syntax were ever to find its way into elm (I'm not suggesting 
> that it should, but just addressing this very specific hypothetical 
> question of how it would work with this possible record syntax): then we 
> could also have expressions like this:
>
> { a.b.c?.d | e = f ... } : Maybe D
>
> And this would be 
>
> Just { cValue.d | e = f ... }
>
> if c is (Just cValue), but it would be Nothing if c is Nothing.
>
> Similarly you could have:
>
> { a.b | c?.d.e = f ...} : B
>
> meaning the value of type B in which c.d.e is set to (f ...) if c is (Just 
> cValue) but in which nothing changes if c is Nothing.
>
> It is crazy but it looks well-defined to me.  Caveat I am not a 
> programming languages person.
>
> Having said all this, my instinct is that mixing record syntax with ? 
> dereference is rather unwieldy.  And I would not recommend that we go that 
> far.  Just my opinion.  However I hope that just the records of records of 
> records aspect gets some consideration. :-)
>
>

-- 
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?

[Ambrose Laing]

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

[elm-discuss] Re: I dislike the names of certain standard library functions.

[Ambrose Laing]

I feel quite strongly that max/min, ||/&& and string should stay.  I would 
argue that one benefit of doing things the "traditional" way is that once 
new programmers get used to it, they get a lot of mileage when 
transitioning to or working with other languages.  Polyglots are valuable 
and the easier it is to be a polyglot the better.

With 'filter', I have never really had a problem remembering which way it 
goes -- maybe that is because I also work with scala.  Personally I prefer 
List.contains over List.includes, because for some reason the latter 
suggests the math operation "is a subset of" rather than "is a member of". 
 Though I could also see how List.contains could evoke the "is a subset of" 
operation.  I don't feel strongly about this particular one.

Maybe its my scala background again, but reduce and foldl are different 
concepts to me.  For a fuller discussion, please see:

http://stackoverflow.com/questions/7764197/difference-between-foldleft-and-reduceleft-in-scala

In scala, reduce works with the base type of the list, requires no default, 
and requires a non-empty list.

Elm's foldl (like scala's foldLeft) works with an empty list, requires a 
default, and can work with types identical or unrelated to the base type of 
the list.

Renaming Elm's foldl to reduce will make it slightly harder to learn the 
differences between scala and elm, and unnecessarily increase the friction 
of rapidly transitioning back and forth between those two.  I strongly 
recommend against dropping foldr -- the two of them have different uses. 
 Maybe similar arguments
can be made by people with a haskell background as well.


On Thursday, July 14, 2016 at 12:34:45 AM UTC-4, Max Goldstein wrote:
>
> It's great that Elm can appeal to new programmers, but it's mainly 
> targeting web developers. As such, things like max/min, ||/&&, and "string" 
> are going to stick around. No need to reinvent what's been standard(-ish) 
> since C.
>
> The biggest name annoyance, IMHO, is *filter*. It doesn't immediately 
> convey whether you're selecting in or out. For my money, Ruby got this one 
> right: *select* and *reject*. They sound similar and they are similar, 
> and the names convey which way the predicate goes. I wouldn't be adverse to 
> stealing a few other Ruby or near-Ruby names; perhaps List.includes instead 
> of member, and reduce to replace foldl (dropping foldr and renaming it fold 
> could also work).
>
> That said, I'm not convinced much of this will happen. Evan is a "big 
> picture" guy, and this would break a lot of code, although deprecation 
> (having both copies for awhile) could help.
>

-- 
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: Adding a transformation layer to the Elm Architecture

[Ambrose Laing]

Could you do something like this:

Tell the Elm Architecture (as it is right now) that your model is

(modelA, modelB)

where modelA is the type that you want to have as a "stage1" domain, and 
modelB is what you want for your "stage2".

And then as Peter Damoc suggested, compose functions to achieve what you 
want.  The update function will be made up of two parts, f1, which looks at 
the pair, but updates modelA only, based on the Msgs, and lets the modelB 
pass through unmodified.  The second function will be f2, which updates 
modelB while only looking at modelA, and ignoring the Msgs.  Then you tell 
the Elm Architecture (in the initialization) that the update function is f1 
andThen f2.  Then you write your view function to only look at the modelB 
part of what Elm thinks the model is.  I am not using exact syntax, but I 
am quite certain that something similar to this could be gotten to work, 
without changing the underlying architecture itself.

If you could get this to work, it would have the advantage that if someone 
else comes along with even more complicated requirements for a three-stage 
transformation, or even a tree-like non-linear number of stages, it can 
still be modeled in a similar fashion without changing the base Elm 
architecture.  Just an idea to try to flesh out.





On Friday, July 1, 2016 at 6:03:44 AM UTC-4, Robert Walter wrote:
>
> Hello all,
>
> not having a strong web development background, but rather coming from the 
> area of domain-specific languages, model-driven development, and IDE 
> development (i.e. building tools for developers and development platforms), 
> Elm made me curious because of a lot of the ideas and features that are 
> built into the language that I know from other technologies. While I 
> understand that Elm is specifically targeted to make the lives of front-end 
> web developers easier and offer them an alternative to JavaScript and the 
> zoo of libraries there, I'd like to discuss if Elm could become even bigger 
> eventually (especially given technologies like Electron that allow us 
> easily to target the desktop as well). 
>
> One of the key selling points for me is the thoroughness that is used to 
> identify what we know as the Elm Architecture. Elm guides you to define a 
> model of your "world" and to specify how this model changes ("update") due 
> to effects from outside or inside ("subscriptions" and "commands"). Also, 
> you define how the model is going to be presented to the user ("view"). And 
> Elm takes care of wiring these components together. It's great and I see 
> Elm as a great language not only for veterans, but also for beginners!
>
> In model-driven development, there are a lot of similarities, but also 
> some differences. Often, your world is made up of several domains ("model 
> schemas"), and you define transformations from one domain to the other. 
> That means applications are composed of domains that are wired by 
> transformations. A system that allows you to build applications that work 
> that way is MPS, by Jetbrains , in case 
> you would like to see an example.
>
> One could say that we have a simplified version of that in the Elm 
> Architecture, where we define one domain ("model") and one transformation 
> ("view") in which we transform our "domain model" to a "rendering model", 
> that is passed on to a rendering engine for display.
>
> So, some of you might say "that's all nice and good, but why do you bring 
> it up"? Well, I really think that there is a lot of potential in the idea 
> of model-driven development and projectional editing and I feel like Elm 
> would be an interesting technology to build something like this on due to 
> its functional nature and thoroughness put into its architecture. I'd like 
> to discuss this with the community. 
>
> To make things a bit more specific, I wonder what you think about 
> generalizing the Elm Architecture in a way that we not only transform from 
> a domain model to a Html model (a.k.a. view), but to allow for a series of 
> transformations if necessary. I like that the current architecture allows 
> us to do something like that to a certain degree. Looking at the Mdl 
> package for example, I consider this a "Widget domain" and I can 
> incorporate it into my "view" function, basically reusing portions of their 
> "domain model to Html" transformation for my own purpuses.
> But if I want to use Elm to transform gradually from a model of low 
> abstraction to Html via intermediate domains, it is hard to do. A 
> suggestion would be to have an optional callback called "transformations" 
> that takes in a model of type A and spits out a model of type B, which is 
> then again used as input for the final transformation step, which would 
> still be "view". Optional means that, if no transformation is defined, A == 
> B.
>
> I hope all of this does make a little bit of sense to some of you and I 
> really hope it is not too