Re: [elm-discuss] Idris holes - Thoughts for Elm?

[W. Brian Gourlie]

This looks really cool! Unfortunately, being a plugin for a specific 
text-editor makes it quite limiting.

On Tuesday, May 23, 2017 at 12:45:20 AM UTC-5, Aaron VonderHaar wrote:
>
> If you haven't seen it already, https://atom.io/packages/elmjutsu has 
> support for creating case statement scaffolds (search the README for 
> "Insert case/of")
>
> On Mon, May 22, 2017 at 10:06 PM, Zachary Kessin  > wrote:
>
>> totally agree, it would also make it easier to have your editor fill in 
>> the code for me
>>
>> Lets say you have a type like this
>> type Direction = North|South|East | West
>> move: Pos -> Direction -> Pos
>> move pos dir =
>>   case dir of
>>  North -> ?rhs
>>  South -> ?rhs
>> etc
>>
>> What I would like is to write "case dir of" and hit <> (or some 
>> other key) in my editor and have the case statement with holes filled in 
>> for me.
>>
>> I think Idris does this already
>>
>> Zach
>> ᐧ
>>
>> On Tue, May 23, 2017 at 2:11 AM, Witold Szczerba > > wrote:
>>
>>> I think it looks like a good idea. When I am adding new a feature, very 
>>> often I have such a "holes", implementation details, which I do not want to 
>>> code at the time of introduction, because I am not sure the final result of 
>>> my changes. So, in order to make compiler happy, I am improvising with some 
>>> dump implementation just to let me go further and at the end, I have to 
>>> look for them and fix.
>>>
>>> Such a "holes" would be great.
>>>
>>> On Mon, May 22, 2017 at 8:40 PM, W. Brian Gourlie >> > wrote:
>>>
 For the uninitiated, Idris  is 
 a pure functional language with a cutting-edge type system. However, this 
 is not another "We should make Elm's type system more advanced by 
 introducing X." Rather, I ran across a feature in Idris that seems like it 
 would fit nicely into Elm based on the fact that it further empowers the 
 compiler to assist the developer, and empowers the developer to 
 iteratively 
 develop their code. This feature is called holes.

 *What are holes?*

 To put it succinctly, a "hole" is a hole in your implementation. Think 
 of it as an expression whose value is inferred based on surrounding 
 context, but does not actually produce a value. Holes allow our code to 
 type-check while freeing the developer from actually having to worry about 
 implementing every part of a function or program as they're writing it.

 *How does an incomplete program compile?*

 The short answer is, it doesn't. There would need to be a distinction 
 between a program that satisfies the type-checker, and a program that can 
 be compiled. For example, there may be a hypothetical command `elm-make 
 --check`. Or, perhaps, a special compilation mode that would convert holes 
 into Debug.crash statements.

 *A practical example*

 Consider the following code:

 describeTemp : Int -> String
 describeTemp temp =
   if temp > 100 then
 "Really hot!"
   else if temp < 32 then
 "Freezing"
   else if temp < 0 then
 ?belowZeroMessage
  else
 ?catchAllMessage

 In the above example, we declared two holes using the syntax 
 `?holeName`.  The theoretical output of the type checker may be something 
 like:

 Type Checking Succeeded!

 You have 2 holes to fill:

 8| ?belowZeroMessage
^
 belowZeroMessage : String
  
 10| ?catchAllMessage
 

 catchAllMessage : String


 The example is simple and contrived, so it's not necessarily 
 representative of a scenario where it would be useful, but for more 
 complex 
 applications where you want to build things iteratively, with 
 type-checking, without resorting to returning dummy values or things like 
 `Debug.crash`, this would be very useful!

 I'd be curious to know what everyone else thinks.

 Brian

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Elm Discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to elm-discuss...@googlegroups.com .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Zach Kessin
>> Teaching Web Developers to test code to find more bugs in less time
>> Skype: zachkessin
>> +972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213
>>
>> -- 
>> You received this message because you are 

Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned

['Rupert Smith' via Elm Discuss]

On Tuesday, May 23, 2017 at 3:30:44 PM UTC+1, Christophe de Vienne wrote:
>
> It is what I did at first, but it has serious drawbacks. The biggest was 
> that a subscription implies an update of the Nats state... so I had to 
> push the state to all the update functions and they had to sent it 
> back... Very messy. 
>

This use case can be catered for by using a correlation id, I think. Also, 
perhaps the word 'subscription' is getting overloaded here, you have the 
Elm Sub(scription), and the NATS protocol subscription, and the middleware 
subscription (listen), making this conversation a little difficult to nail 
down...

== Module Consuming the NATS Protocol

Elmq.sendString "subscribe" "nats0"
Elmq.listen "nats0"

== The module implementing the NATS protocol

type Msg =
NewNatsSubscription String
| ...

Elmq.listenString "subscribe" (\channel -> NewNatsSubscription)
Elm.send channelName ...

==

So I sent a subscription request to Nats, and when Nats processed it, it 
sends back messages on the named channel. The channel name is used as a 
correlation id to link together the act of creating the subscription and 
the messages that then flow over that subscription.

I don't know the specific of NATS and whether it has named channels etc. 
but hopefully you get what I am on about?

-- 
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: Best practices to create examples for an elm package?

[Christophe de Vienne]

Le 23/05/2017 à 17:44, 'Rupert Smith' via Elm Discuss a écrit :
> On Monday, May 8, 2017 at 3:38:55 PM UTC+1, Eirik Sletteberg wrote:
> 
> Maybe write an example in the form of an integration test - then you
> know your example will be up to date with the actual code, and it
> may even discover bugs!
> 
> 
> I think there is an issue here that did not come up for discussion yet:
> 
> Suppose I have some examples or some tests, and those need packages that
> the actual library does not use. Those packages get sucked in as
> dependencies even though the library itself does not use them?
> 
> Is there a way to have tests or examples and for those to use extra
> packages, but for those packages not to be included as transitive
> dependencies of the library itself? 

For the example I have a separate 'elm-package.json' in the 'example'
directory, and it has '../src', '.' as source-directory.

About test, with elm-tests you also have a separate elm-package.json in
tests/.

-- 
Christophe de Vienne

-- 
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: Best practices to create examples for an elm package?

['Rupert Smith' via Elm Discuss]

On Monday, May 8, 2017 at 3:38:55 PM UTC+1, Eirik Sletteberg wrote:
>
> Maybe write an example in the form of an integration test - then you know 
> your example will be up to date with the actual code, and it may even 
> discover bugs!


I think there is an issue here that did not come up for discussion yet:

Suppose I have some examples or some tests, and those need packages that 
the actual library does not use. Those packages get sucked in as 
dependencies even though the library itself does not use them?

Is there a way to have tests or examples and for those to use extra 
packages, but for those packages not to be included as transitive 
dependencies of the library itself? 

-- 
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: Implementing websocket-based protocol - lessons learned

[Christophe de Vienne]

Le 23/05/2017 à 16:23, 'Rupert Smith' via Elm Discuss a écrit :
> On Tuesday, May 23, 2017 at 3:04:01 PM UTC+1, Christophe de Vienne wrote:
> 
> A discussion around a concept of "middleware", able to define its own
> Cmd and Sub that it could rewrite along with updating its own state
> (which can be a part of the app model), would be interesting.
> 
> Cmd and Sub are pretty opaque beasts from where I stand, may be we can
> already do such a thing.
> 
> 
> There are modules that build their own subscriptions, for example:
> 
> http://package.elm-lang.org/packages/mdgriffith/elm-style-animation/3.5.5/Animation
> 
> provides a function to build a subscription. This is just a convenience
> function; under the covers the animations are being iterated as a timer
> ticks, so the real Sub being created is a timer one.
> 
> So I think if you can define what flexible 'command' and 'subscription'
> constructor functions you think the middleware needs, and we can try and
> map those down to the simplest Cmd and Sub implementations that cover
> all the needed use cases, then that gives us what we would need to
> implement in an effects module. Essentially, it would be a messaging
> kernel that is flexible enough that any reasonable messaging application
> you like can be built on top of it.

It is what I did at first, but it has serious drawbacks. The biggest was
that a subscription implies an update of the Nats state... so I had to
push the state to all the update functions and they had to sent it
back... Very messy.

The final API I have, although it has some boilerplate, is a lot nicer.

-- 
Christophe de Vienne

-- 
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: Implementing websocket-based protocol - lessons learned

['Rupert Smith' via Elm Discuss]

On Tuesday, May 23, 2017 at 3:04:01 PM UTC+1, Christophe de Vienne wrote:
>
> A discussion around a concept of "middleware", able to define its own 
> Cmd and Sub that it could rewrite along with updating its own state 
> (which can be a part of the app model), would be interesting. 
>
> Cmd and Sub are pretty opaque beasts from where I stand, may be we can 
> already do such a thing. 
>

There are modules that build their own subscriptions, for example:

http://package.elm-lang.org/packages/mdgriffith/elm-style-animation/3.5.5/Animation

provides a function to build a subscription. This is just a convenience 
function; under the covers the animations are being iterated as a timer 
ticks, so the real Sub being created is a timer one.

So I think if you can define what flexible 'command' and 'subscription' 
constructor functions you think the middleware needs, and we can try and 
map those down to the simplest Cmd and Sub implementations that cover all 
the needed use cases, then that gives us what we would need to implement in 
an effects module. Essentially, it would be a messaging kernel that is 
flexible enough that any reasonable messaging application you like can be 
built on top of it.

I once had a great job, which was to be paid to work on an open source 
implementation of the AMQP protocol (Apache Qpid). In Java land the 
messaging API is called JMS, and it is just what I described above - a 
messaging API (and implied kernel) that is generic enough to fit most 
reasonable middleware needs and implementations.

-- 
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: Implementing websocket-based protocol - lessons learned

['Rupert Smith' via Elm Discuss]

On Tuesday, May 23, 2017 at 3:06:29 PM UTC+1, Rupert Smith wrote:
>
> There was someone else who wrote a 'middleware' component for Elm, but did 
> it with 'out messages' instead of as an effect module. There was a routing 
> part that you put in you top-level update function. Let me see if I can 
> find it...
>

This:

https://groups.google.com/forum/#!searchin/elm-discuss/messaging%7Csort:relevance/elm-discuss/gSkvCgTj4q0/TJJCtcX9BgAJ

https://github.com/RJWoodhead/elm-memo 

-- 
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: Implementing websocket-based protocol - lessons learned

['Rupert Smith' via Elm Discuss]

On Tuesday, May 23, 2017 at 2:50:05 PM UTC+1, Rupert Smith wrote:
>
> I'm going to the upcoming Elm Europe conference, so I can talk to the core 
> devs there and see what they think of it. As I said before, perhaps its not 
> an 'architectural' direction that they like; on the other hand it does seem 
> both simple and useful.
>

There was someone else who wrote a 'middleware' component for Elm, but did 
it with 'out messages' instead of as an effect module. There was a routing 
part that you put in you top-level update function. Let me see if I can 
find it...

One criticism of elmq might be that it is not so transparent. So if a 
module sends a message, the Cmd for that is passed into the Elm kernel, and 
from then on it sort of disappears from the compilers view - the messages 
are untyped in so far as that they are Json.Encode.Values. There is no way 
for the compiler to check that whatever receives them has a matching type, 
or indeed that there is any receiver listening at all. At least with 'out 
messages' the type checking will flow across the modules. Of course there 
could still be a bug in code where the 'out messages' are ignored and not 
processed. It may be possible to improve the elmq API to mitigate these 
issues - for example, an option to discard messages when there is no 
receiver and so on.

-- 
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: Implementing websocket-based protocol - lessons learned

[Christophe de Vienne]

Hi

Le 23/05/2017 à 15:50, 'Rupert Smith' via Elm Discuss a écrit :
> On Monday, May 22, 2017 at 4:08:13 PM UTC+1, Christophe de Vienne wrote:
> 
> I will make some tests with now that the plain version is working
> properly.
> 
> 
> Would be interesting to see if elmq has enough features to support your
> use case, or if it needs some extension. I think gathering use cases,
> reviewing what other language do and so on is the work that needs to be
> done prior to proposing adding it as a supported effects module. Also,
> nice that you did it without an effects module, as that is one more
> example to compare the code with/without elmq, if you were to redo it on
> top of elmq.

I hope I am wrong but I do not think I can achieve a natural
subscription API on top of elmq. I cannot work on it right now but will.

> 
> I'm going to the upcoming Elm Europe conference, so I can talk to the
> core devs there and see what they think of it. As I said before, perhaps
> its not an 'architectural' direction that they like; on the other hand
> it does seem both simple and useful.

A discussion around a concept of "middleware", able to define its own
Cmd and Sub that it could rewrite along with updating its own state
(which can be a part of the app model), would be interesting.

Cmd and Sub are pretty opaque beasts from where I stand, may be we can
already do such a thing.

-- 
Christophe de Vienne

-- 
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: Implementing websocket-based protocol - lessons learned

['Rupert Smith' via Elm Discuss]

On Monday, May 22, 2017 at 4:08:13 PM UTC+1, Christophe de Vienne wrote:
>
> I should have had a better look at what elmq allowed indeed. 
>
> That said until elmq (or something equivalent) is published on 
> package.elm-lang.org, we get a non-publishable package. 
>

Yes, it would make your package non-publishable too.
 

> I will make some tests with now that the plain version is working 
> properly. 
>

Would be interesting to see if elmq has enough features to support your use 
case, or if it needs some extension. I think gathering use cases, reviewing 
what other language do and so on is the work that needs to be done prior to 
proposing adding it as a supported effects module. Also, nice that you did 
it without an effects module, as that is one more example to compare the 
code with/without elmq, if you were to redo it on top of elmq.

I'm going to the upcoming Elm Europe conference, so I can talk to the core 
devs there and see what they think of it. As I said before, perhaps its not 
an 'architectural' direction that they like; on the other hand it does seem 
both simple and useful.

-- 
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] Idris holes - Thoughts for Elm?

['Rupert Smith' via Elm Discuss]

On Tuesday, May 23, 2017 at 6:45:20 AM UTC+1, Aaron VonderHaar wrote:
>
> If you haven't seen it already, https://atom.io/packages/elmjutsu has 
> support for creating case statement scaffolds (search the README for 
> "Insert case/of")
>

Elmjutsu is also already making use of 'type holes' to infer types, but it 
is hacked without explicit support from the compiler:

https://atom.io/packages/elmjutsu#infer-type
http://blog.jenkster.com/2016/11/type-bombs-in-elm.html 

Some improved compiler support certainly wouldn't hurt.

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