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

[Mark Hamburg]

Definitely the big reason from my perspective to make more things
comparable is to allow their use with dictionaries and sets. For that
usage, the comparison could even be compiler dependent (or even execution
dependent) but I'm sure that someone would build code that depended on
properties of some particular implementation.

Mark

P.S. Since this forum likes examples, rather than passing around naked
strings, I pass around type AccountID = AccountID String. This is great
from a type-checking perspective but means that I can't have a dictionary
keyed by AccountID and instead I need to unwrap the value to get the
underlying string. That's not too bad, but I recently had need to fold over
such a dictionary and so found myself faced with either having a function
to force convert a String into an AccountID or storing the original wrapped
AccountID along with the value. Neither solution was particularly pretty —
one because it is a temptation to undermine type-safety and one because it
complicates the dictionary for all other uses.

On Fri, Aug 4, 2017 at 7:54 AM, Richard Feldman  wrote:

> 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.
>>
>
> Having talked to Evan about it, it seems like the design work is what's
> hard. The implementation is actually not a ton of work, apparently.
>
> That said, the design work *is* hard. 
>
> Does a union type require that all fields/members are comparable as well?
>>
>
> I think that'd necessarily be true, yeah. But if union types and records
> are comparable (assuming they hold only comparable types), I *think* you
> end up with something like "functions aren't comparable, nor are
> Kernel-implemented values such as Value, Task, Cmd, and Html, but
> everything else is."
>
>
>> As a reader, how easy is it to tell if a union type is comparable
>>
>
> Probably not easy, would be my guess. It's unclear to me how big of a deal
> that would be though.
>
>
>> and is it obvious when one is lesser than another?
>>
>
> Apparently the way Haskell does this is by using the order of the tags
> (e.g. for type Maybe a = Just a | Nothing, we could say that Just "foo" >
> Nothing because Just came before Nothing in the type declaration), which
> seems fine to use since that ordering is currently arbitrary and
> meaningless. Similarly, record fields could be compared alphabetically by
> field name (since record fields definitionally have no ordering; if you
> needed them to be compared in a certain order, you could use a union type).
>
> Considering the main (only?) reason people want them to be comparable is
> so they can be used in Sets and Dict keys, it doesn't seem hugely important
> how they compare, so long as they can be for purposes of internal data
> structure implementation details. I could be missing something though!
>
> It's not straight forward from a design perspective.
>>
>
> I totally agree! 
>
> --
> 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.

Re: [elm-discuss] Elm `reusable views`

[Mark Hamburg]

Wow. If only this stuff were well supported...

On Thu, Aug 3, 2017 at 9:40 AM, Peter Damoc  wrote:

> Indeed, adding a ResizeObserver polyfill allows for the expected behavior:
> https://ellie-app.com/3VFHVxMsW2ya1/1
>
>
> On Thu, Aug 3, 2017 at 7:18 PM, Mark Hamburg 
> wrote:
>
>> We watch for resizing using some resize observation JavaScript code —
>> search on ResizeObserver and you can find a number of hits — and feed the
>> values back through a port tagged with the size of the observed entity.
>> Attaching the observer in a virtual DOM is an interesting problem because
>> elements can come in and out of existence based on what happens in the view
>> function. Our solution to that was to mark observed elements with a class
>> and use that to trigger an insanely fast animation and set up an observer
>> to watch for the notification for when that animation runs. This is the
>> sort of thing that leads to me saying "I hate the web."
>>
>> Mark
>>
>> On Thu, Aug 3, 2017 at 3:53 AM Peter Damoc  wrote:
>>
>>> You could try to use MutationObservers to ferry that information in Elm:
>>> https://ellie-app.com/3VFHVxMsW2ya1/0
>>>
>>> Unfortunately, I don't know enough about them to provide a solution that
>>> would actually monitors their resizing but maybe someone else could.
>>>
>>>
>>>
>>>
>>> On Thu, Aug 3, 2017 at 11:43 AM, enetsee  wrote:
>>>
 Hi,

 I have been trying to create a `resuable view` following the structure
 outlined in evanczs `elm-sortable-table`
  and other examples,
 including:

- abadi199s `datetimepicker`

- thebriticans `elm-autocomplete`


 I was attempting the reproduce the range slider from Palantir's
 BlueprintJS component library (example here
 ).
 My Elm version is here , with a
 live version in Ellie here
 .

 The Elm version extends the original by allowing the user to specify
 the scale that should be used. The live demo shows both a linear and
 logarithmic scale; the latter is particularly useful when asking users to
 select values which have a heavily skewed distribution (common in finance
 and insurance).

 The main limitation of the Elm version compared with the original is
 having to specify a fixed width. The react version seems to use `
 clientWidth
 `
 to determine the rendered width of the component and uses that when
 positioning visual elements. As far as I'm aware there is no way to achieve
 this with Elm.

 I would really appreciate any pointers on my approach, particularly if
 I have misunderstood the `reusable view` approach, and any ideas on how
 overcome the fixed width limitation mentioned above.

 Thanks,

 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.

>>>
>>>
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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] 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: Elm `reusable views`

[Robert Woodhead]

I had to something similar in Elm-Life; it gets a message every time the 
window changes in size, and reports the new size of a particular DOM 
element. You can find the code here: https://github.com/RJWoodhead/elm-life


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

[Richard Feldman]

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

[Richard Feldman]

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

Having talked to Evan about it, it seems like the design work is what's 
hard. The implementation is actually not a ton of work, apparently.

That said, the design work *is* hard. 

Does a union type require that all fields/members are comparable as well?
>

I think that'd necessarily be true, yeah. But if union types and records 
are comparable (assuming they hold only comparable types), I *think* you 
end up with something like "functions aren't comparable, nor are 
Kernel-implemented values such as Value, Task, Cmd, and Html, but 
everything else is."
 

> As a reader, how easy is it to tell if a union type is comparable
>

Probably not easy, would be my guess. It's unclear to me how big of a deal 
that would be though.
 

> and is it obvious when one is lesser than another?
>

Apparently the way Haskell does this is by using the order of the tags 
(e.g. for type Maybe a = Just a | Nothing, we could say that Just "foo" > 
Nothing because Just came before Nothing in the type declaration), which 
seems fine to use since that ordering is currently arbitrary and 
meaningless. Similarly, record fields could be compared alphabetically by 
field name (since record fields definitionally have no ordering; if you 
needed them to be compared in a certain order, you could use a union type).

Considering the main (only?) reason people want them to be comparable is so 
they can be used in Sets and Dict keys, it doesn't seem hugely important 
how they compare, so long as they can be for purposes of internal data 
structure implementation details. I could be missing something though!

It's not straight forward from a design perspective.
>

I totally agree! 

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

[elm-discuss] Drawing Directed Graphs (?) in Elm

[Michael Jones]

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.