Re: [elm-discuss] Re: Embedding multiple elements into JS

[Matt Joiner]

Cheers no problem. That was the conclusion on Slack also.

On 25 March 2017 at 10:55, Nicholas Hollon 
wrote:

> err, I meant that message to be a little bit more timely, but it got held
> up in moderation. Glad you got help -.-
>
>
> On Friday, March 24, 2017 at 3:49:24 PM UTC-7, Nicholas Hollon wrote:
>>
>> You should have Elm return the , and embed the program an empty div.
>> I am pretty sure you are only allowed to embed Elm programs in divs anyway,
>> not just any old html tag.
>>
>> On Wednesday, March 22, 2017 at 7:36:44 AM UTC-7, Matt Joiner wrote:
>>>
>>> I'm looking to embed Elm in an existing web application gradually. I
>>> find it most appropriate in my projects to embed multiple elements, not a
>>> single parent element. For example I have some bootstrap:
>>>
>>> 
>>>
>>> I want to run Elm.Main.embed(document.getElementById('some-list')), and
>>> have that main return multiple  elements. Clearly I can't have Elm
>>> return a parent  because then I have . I also can't
>>> have Elm return the  because
>>> then there's no #some-list to embed it on in the first place.
>>>
>>> Look forward to suggestions, thanks.
>>>
>> --
> 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/4wATZxCmbLw/unsubscribe.
> To unsubscribe from this group and all its topics, 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: 'Native' -> 'Kernel': a msgpack example

[Kasey Speakman]

Yeah, I regretted posting that 2nd half. I don't use any native modules 
myself except the one to return decoders out of ports. And I was getting by 
without it via ports, although somewhat less optimally. Maybe some people 
really need native stuff, though. I haven't. (And I'm willing to monkey 
patch what I use native for now if need be.)

On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>
> Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
> native module whitelist (sortof). Expectation management.
>
> User native module blocking was not mentioned. In our current Javascript 
> ecosystem such a thing would make Elm non-viable.
>
> Well, except that repo-forking and monkey-patching exist.
>
> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>>
>> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>>
>>> It's pretty clear that these practices are frowned upon, but the shift 
>>> to 'kernel' sounds like a plan to squeeze the pragmatic programmer's 
>>> options further. I hope that's not the case.
>>>
>>
>> I think all that is happening is that Native is being renamed to Kernel 
>> to reduce confusion. At the moment when we say 'Elm' and 'native' in the 
>> same sentence we could mean an Elm Native module used to implement its 
>> kernel, or native javascript code through ports.
>>
>> I can't be certain of the details but I think your function would just be 
>> re-written as:
>>
>> var _user$project$Kernel_Msgpack = function() { ... }
>>
>> But you won't be able to publish it officially and will have to use 
>> elm-github-install.
>>
>> It makes sense to me anyway, the 'kernel' needs to be carefully managed 
>> as the language takes shape.
>>
>>

-- 
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: Embedding multiple elements into JS

[Nicholas Hollon]

err, I meant that message to be a little bit more timely, but it got held 
up in moderation. Glad you got help -.-

On Friday, March 24, 2017 at 3:49:24 PM UTC-7, Nicholas Hollon wrote:
>
> You should have Elm return the , and embed the program an empty div. I 
> am pretty sure you are only allowed to embed Elm programs in divs anyway, 
> not just any old html tag.
>
> On Wednesday, March 22, 2017 at 7:36:44 AM UTC-7, Matt Joiner wrote:
>>
>> I'm looking to embed Elm in an existing web application gradually. I find 
>> it most appropriate in my projects to embed multiple elements, not a single 
>> parent element. For example I have some bootstrap:
>>
>> 
>>
>> I want to run Elm.Main.embed(document.getElementById('some-list')), and 
>> have that main return multiple  elements. Clearly I can't have Elm 
>> return a parent  because then I have . I also can't 
>> have Elm return the  because 
>> then there's no #some-list to embed it on in the first place.
>>
>> Look forward to suggestions, 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] Kite, An Interactive Visualization Tool for Graph Theory

[Erkal Selman]

About the interaction with d3-force: I was surprised that it worked so fine
and so fast. Because I was mainly interested in the resulting layout after
the simulation cools down, I implemented it without high expectations on
high fps. What happens there is that in every tick of the simulation d3
sends a list of the (vertex,position) pairs to elm. Elm takes them and
assigns these coordinates to each vertex in the Dict. I didn't expect that
this would work so fast that even with large graphs the animations run
smoothly, even on smart phones.

On Fri, Mar 24, 2017 at 9:54 PM, Mark Marlow  wrote:

> Thanks for sharing - particularly interested in seeing your link to d3;
> I'm using it extensively and hoping to use elm!
>
> --
> 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/xbJtuHE3XL8/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Kite, An Interactive Visualization Tool for Graph Theory

[Mark Marlow]

Thanks for sharing - particularly interested in seeing your link to d3; I'm 
using it extensively and hoping to use elm!

-- 
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: Embedding multiple elements into JS

[Nicholas Hollon]

You should have Elm return the , and embed the program an empty div. I 
am pretty sure you are only allowed to embed Elm programs in divs anyway, 
not just any old html tag.

On Wednesday, March 22, 2017 at 7:36:44 AM UTC-7, Matt Joiner wrote:
>
> I'm looking to embed Elm in an existing web application gradually. I find 
> it most appropriate in my projects to embed multiple elements, not a single 
> parent element. For example I have some bootstrap:
>
> 
>
> I want to run Elm.Main.embed(document.getElementById('some-list')), and 
> have that main return multiple  elements. Clearly I can't have Elm 
> return a parent  because then I have . I also can't 
> have Elm return the  because 
> then there's no #some-list to embed it on in the first place.
>
> Look forward to suggestions, 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.

[elm-discuss] Re: To wrap or not to wrap

['Rupert Smith' via Elm Discuss]

On Thursday, March 23, 2017 at 4:21:10 PM UTC, Mark Hamburg wrote:
>
> Should one wrap a model implemented as a record in a type to keep the 
> details private?


If you wrap your Model to keep it private, you will only need to 
wrap/unwrap the functions that the module exposes. Internal functions can 
work with the model directly:

module MyAwesomeModule exposes (update)

type Model = M ModelRecord

type alias ModelRecord = { ... }

update : Msg -> Model -> Model

someUpdateHelper : ModelRecord -> ModelRecord

So perhaps wrapping might not be as great an inconvenience. Just don't 
expose (..) always name the public functions being exposed.



Also, I think if you wrap the model, you may end up with public functions 
just to extract stuff from it:

module MyAwesomeModule exposes (getUsername)

type Model = M ModelRecord
type alias ModelRecord = { userName : String }

getUsername : Model -> String

Which is analogous to Java where, for reasons no-one is prepared to go 
against, we do:

public class Account {
  private String userName;

  public String getUserName() { return userName; }
  public void setUserName(String userName) { this.userName = userName; }
}

When really we could do:

public class Account {
  public String userName;
}

(Sometimes I do this, it really annoys some people :-P)

In common with Java, Elm has a different syntax for extracting the username 
with 'dot' notation and for writing a function/method to do it (some 
languages have the same notation for both, which makes changing how it is 
done transparent to the consumer of the interface).

I think if you have fields that other modules need to read, perhaps don't 
wrap them, just wrap stuff that is really private?

type alias Model = 
  { userName : String
  , private : Private 
  }

type Private = ...

Nothing wrong with a public field, and I think it is better than forcing 
yourself to write extract functions unnecessarily.

-- 
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] elm debugger as a browser extension

[Roman Frołow]

Have you seen this? https://github.com/jinjor/elm-devtool

--
Roman

-- 
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: 'Native' -> 'Kernel': a msgpack example

[Kasey Speakman]

Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
native module whitelist (sortof). Expectation management.

User native module blocking was not mentioned. In our current Javascript 
ecosystem such a thing would make Elm non-viable.

Well, except that repo-forking and monkey-patching exist.

On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>
> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>
>> It's pretty clear that these practices are frowned upon, but the shift to 
>> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
>> further. I hope that's not the case.
>>
>
> I think all that is happening is that Native is being renamed to Kernel to 
> reduce confusion. At the moment when we say 'Elm' and 'native' in the same 
> sentence we could mean an Elm Native module used to implement its kernel, 
> or native javascript code through ports.
>
> I can't be certain of the details but I think your function would just be 
> re-written as:
>
> var _user$project$Kernel_Msgpack = function() { ... }
>
> But you won't be able to publish it officially and will have to use 
> elm-github-install.
>
> It makes sense to me anyway, the 'kernel' needs to be carefully managed as 
> the language takes shape.
>
>

-- 
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: To wrap or not to wrap

[Ian Mackenzie]

The core types in my geometry library 

 
use what is in some sense "the worst of both worlds" - I wrap values 
implemented as tuples or records, but only to provide type safety, not to 
keep internal details private (the constructors are exposed):

type Vector3d
= Vector3d ( Float, Float, Float )

type Point3d
= Point3d ( Float, Float, Float )

type Direction3d
= Direction3d ( Float, Float, Float )

type Axis3d
= Axis3d { originPoint : Point3d, direction : Direction3d }


This allows client code to directly construct a Vector3d ( 1, 2, 3 ) or a 
Point3d 
( 1, 2, 3 ) or an Axis3d { originPoint = ..., direction = ... }, but once 
they are constructed you can't pass a Vector3d where a Point3d is expected. 
You could destructure/unwrap the constructed values if you wanted to, but 
there are enough accessor functions (Axis3d.originPoint, Point3d.coordinates, 
Point3d.xCoordinate etc.) that normally you don't need to. I'm not sure 
this is a good pattern in general (I don't think I'll continue to use it 
for more complex future types like parametric surfaces or solid bodies 
where the representation is much more complex) but I think it works well 
for fairly low-level, primitive types.

On Thursday, 23 March 2017 12:21:10 UTC-4, Mark Hamburg wrote:
>
> Should one wrap a model implemented as a record in a type to keep the 
> details private? In other words:
>
> type alias Model = { foo : Foo, baz : Baz }
>
> - or -
>
> type Model = M { foo : Foo, baz : Baz }
>
> The former is much easier to work with because one isn't constantly 
> unwrapping and rewrapping.
>
> The latter keeps code better encapsulated.
>
> I had this discussion with a fellow programmer and he asked whether 
> immutability makes the encapsulation irrelevant. I argued no because the 
> exposure of internals means that client code can adopt dependencies on 
> internal choices — "Just because I have a field named 'foo' doesn't mean I 
> want a client to know about it" — and more significantly it allows 
> arbitrary code to create values purporting to be valid Model values. If one 
> can achieve "make invalid states impossible", that's obviously great but in 
> practice we rely on limiting construction to impose further invariants. 
> (For example, if the structures implementing an AVL tree were exposed, the 
> type system would ensure that we had a DAG but it could do nothing to 
> ensure anything about ordering or the height values.)
>
> The balance we were left with was that "we're all programmers of good 
> character and we will consider other modules Models to be opaque even if 
> they aren't." (I'd have said "we're all gentlemen" but that's sexist.) 
> This, of course, works until we hire a programmer whose character isn't 
> quite as good in this regard.
>
> How do others choose in this regard?
>
> Mark
>
> P.S. What I would like — though it would break a lot of existing code — is 
> for the fields of a record to only be exposed on export if explicitly 
> exposed a la exposing constructors for types.
>

-- 
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: Web components vs. Native

[Maxwell Gurewitz]

Hey Rupert.  I'm not comparing web components to ports.  Of course ports 
are a standard, important part of elm.  My comparison is to native elm, 
which is different.  For example,

https://github.com/elm-lang/persistent-cache/tree/master/src/Native

Ports can't break the debugger's guarantees because the debugger doesn't 
run port code during replays.

On Friday, March 24, 2017 at 4:29:53 AM UTC-7, Rupert Smith wrote:
>
> On Wednesday, March 22, 2017 at 11:57:22 PM UTC, Maxwell Gurewitz wrote:
>>
>> Hi all.  I'm creating this thread to discuss the relative merits of web 
>> components and native code.
>>
>
> One of the merits is that you can avoid ports to some extent, because a 
> web component can be set up by passing it attributes or properties, and can 
> tell your Elm code about events through custom event handlers and using 
> Html.Events.on. 
>
> Perhaps this is why you get the impression that web-components are favored 
> over ports?
>
> I think the custom event handler can be very useful and save on Elm coding 
> needed to set up a subscription. Of course, there is no need to use the web 
> components standard to do these things a minimal amount of javascript can 
> be used instead.
>
> I think you are somehow getting the wrong impression that web-components 
> are favored. They can be problematic as mentioned already - placing them 
> within the DOM that Elm controls can lead to them being re-rendered and 
> losing their internal state. There is an impedance mismatch between 
> web-components which are object oriented and encapsulate state and 
> functional Elm code that does not.
>

-- 
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] elm debugger as a browser extension

[Eirik Sletteberg]

It would be nice to have the elm debugger (the overlay one you get when 
running apps with elm-reactor) as a browser extension, instead of being 
embedded in the document. Something like the 
redux-devtools-extension: https://github.com/zalmoxisus/redux-devtools-extension
How would one approach solving such a problem?
Is it possible to make the elm compiler output debug hooks that a browser 
extension can hook into? And then the debugger could simply be rendered in 
a browser extension?

-- 
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: 'Native' -> 'Kernel': a msgpack example

['Rupert Smith' via Elm Discuss]

On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>
> It's pretty clear that these practices are frowned upon, but the shift to 
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
> further. I hope that's not the case.
>

I think all that is happening is that Native is being renamed to Kernel to 
reduce confusion. At the moment when we say 'Elm' and 'native' in the same 
sentence we could mean an Elm Native module used to implement its kernel, 
or native javascript code through ports.

I can't be certain of the details but I think your function would just be 
re-written as:

var _user$project$Kernel_Msgpack = function() { ... }

But you won't be able to publish it officially and will have to use 
elm-github-install.

It makes sense to me anyway, the 'kernel' needs to be carefully managed as 
the language takes shape.

-- 
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: Web components vs. Native

['Rupert Smith' via Elm Discuss]

On Wednesday, March 22, 2017 at 11:57:22 PM UTC, Maxwell Gurewitz wrote:
>
> Hi all.  I'm creating this thread to discuss the relative merits of web 
> components and native code.
>

One of the merits is that you can avoid ports to some extent, because a web 
component can be set up by passing it attributes or properties, and can 
tell your Elm code about events through custom event handlers and using 
Html.Events.on. 

Perhaps this is why you get the impression that web-components are favored 
over ports?

I think the custom event handler can be very useful and save on Elm coding 
needed to set up a subscription. Of course, there is no need to use the web 
components standard to do these things a minimal amount of javascript can 
be used instead.

I think you are somehow getting the wrong impression that web-components 
are favored. They can be problematic as mentioned already - placing them 
within the DOM that Elm controls can lead to them being re-rendered and 
losing their internal state. There is an impedance mismatch between 
web-components which are object oriented and encapsulate state and 
functional Elm code that does not.

-- 
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: Kite, An Interactive Visualization Tool for Graph Theory

[Robert Walter]

Great stuff, thanks for making it open source!

On Thursday, March 23, 2017 at 11:26:50 PM UTC+1, Erkal Selman wrote:
>
> I would like to announce that I open sourced my hobby project, which I 
> named Kite. Here is the demo . Here is the 
> source .
>
> I am interested in visualising mathematical ideas, in particular, 
> constructions, algorithms and games from the areas mathematical logic, 
> combinatorics and theoretical computer science. 
>
> My journey with Elm started 2 years ago with this question in Elm Discuss 
> .
>
> I am not a developer and I am sure that my code has many problems. I would 
> be very happy if you would take a look over the code and point out the 
> wrong practices. 
>
> I try to keep the number of libraries that I depend on as small as 
> possible. I try to write my own small libraries which serve my own 
> purposes. Some of them may be useful for your projects, too. There are two 
> modules in Kite, of which I think that they may be useful in other contexts:
>
>- FileSystem 
> 
>can be used with any file type, not only for graphs. Say, you want to 
>implement something like the Atom text editor in Elm, you can use this 
>module.
>- PanAndZoom 
>
>  
>can be used for panning and zooming on SVG elements. I think that my code 
>organization for this module is bad. But I also couldn't find a better 
> way. 
>I certainly need help here.
>
> I am planning to add many functionalities to Kite. My gut feeling is that 
> first I should simplify the basis infrastructure as much as possible before 
> adding new features. Therefore, ideas about simplification are most 
> welcome. But I would be happy for any kind comment or pull-request.
>

-- 
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: To wrap or not to wrap

[Robert Walter]

I try to answer myself the question whether or not a type is going to be 
exposed (used by client code) or if I just want to wrap some fields into an 
alias for convenience.
As soon as a type becomes exposed, I prefer strong types because of their 
stricter contract. Also, strong types are easier to extend in hindsight 
without breaking other code. If I would add another constructor "M2" to 
your "type Model", I wouldn't have to worry about client code that uses 
"M". First, I didn't really appreciate the necessity to expose constructors 
explicitly, but I actually like that fact because it allows me to NOT 
expose constructors and instead expose custom functions for client code to 
interact with a type. This allows you to change the internals of a type 
without breaking client code.

Still, type aliases can be convenient to juggle logical units of fields 
internally. 

On Thursday, March 23, 2017 at 5:21:10 PM UTC+1, Mark Hamburg wrote:
>
> Should one wrap a model implemented as a record in a type to keep the 
> details private? In other words:
>
> type alias Model = { foo : Foo, baz : Baz }
>
> - or -
>
> type Model = M { foo : Foo, baz : Baz }
>
> The former is much easier to work with because one isn't constantly 
> unwrapping and rewrapping.
>
> The latter keeps code better encapsulated.
>
> I had this discussion with a fellow programmer and he asked whether 
> immutability makes the encapsulation irrelevant. I argued no because the 
> exposure of internals means that client code can adopt dependencies on 
> internal choices — "Just because I have a field named 'foo' doesn't mean I 
> want a client to know about it" — and more significantly it allows 
> arbitrary code to create values purporting to be valid Model values. If one 
> can achieve "make invalid states impossible", that's obviously great but in 
> practice we rely on limiting construction to impose further invariants. 
> (For example, if the structures implementing an AVL tree were exposed, the 
> type system would ensure that we had a DAG but it could do nothing to 
> ensure anything about ordering or the height values.)
>
> The balance we were left with was that "we're all programmers of good 
> character and we will consider other modules Models to be opaque even if 
> they aren't." (I'd have said "we're all gentlemen" but that's sexist.) 
> This, of course, works until we hire a programmer whose character isn't 
> quite as good in this regard.
>
> How do others choose in this regard?
>
> Mark
>
> P.S. What I would like — though it would break a lot of existing code — is 
> for the fields of a record to only be exposed on export if explicitly 
> exposed a la exposing constructors for types.
>

-- 
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: 'Native' -> 'Kernel': a msgpack example

[Noah Hall]

> The work around is a native file along the lines of (or see this NoRedInk 
> library):

Sidenote: That is not a NoRedInk library. I do not work at NoRedInk
any more. It's a eeue56 library. It's important to distinct the two.

On Fri, Mar 24, 2017 at 4:19 AM, Martin Bailey  wrote:
> I suggested in elm-dev that adding a BitStream interface in Elm would make
> this kind of JS interop unnecessary. As it stands, one can't implement
> MsgPack in Elm since the only link to the outside world is JSON/String and
> binary data isn't valid UTF-16. I'd like to implement LZ-String in Elm for
> local storage compression but am not sure whether that'll be possible at
> some point. In the meantime, you can still write native/kernel code but just
> can't share it with the ecosystem.
>
> --
> 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.