date:20170120

[elm-discuss] Elm Documentation

2017-01-20 Thread Paul Dijou

Now that 0.18 is out for some time, wouldn't it be better to focus on 
improving the documentation rather than already starting new features? The task 
page  of the Elm guide 
has been empty for months while being one the core concept of Elm.

Is there any plan to have documentation on effect modules? On native code? 
I understand that those topics are quite complex and not at all for all 
users but with the ecosystem growing, more and more libs or production 
projects need to use them (just like Elm Core does) but I think most people 
only learn it by reading at other libs source code and trial&error, which 
is not the best way to develop a safe and sound project. We could put those 
pages inside "Advanced topics ".

I would love to help but, as I just said, I'm not even sure of what I'm 
coding (even if it works so far...)

-- 
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] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Martin Cerny

Hi all,
I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It is 
probably deeply wrong, but I want to understand why it is wrong :-)

What I was trying to do was to define a type like this:

type alias Convertor a =
{ convert : b -> a
}


Here I get "Type alias `Convertor` must declare its use of type variable b"
Now, I understand, why you cannot have 

type alias X a =  { field1: a, field2: b }

But with the source type of functions, things are IMHO different than with 
values. You cannot write values of unbound types and you could not decide 
whether two instances of X are really the same type. 
But you can easily write functions that have unbound source types - like 
this one:

convertString: a -> String 
convertString x =
(toString x) ++ "_Foo"


And since all of functions with this signature really have the same type at 
JavaScript level, two instances of 'Convertor a' would always had the same 
type.

Now if I had
c: Convertor String
c = {convert = convertString}
the whole thing seems type-safe...

So my question is:
Is this syntax forbidden, because it is an obscure feature that is not 
worth supporting, or would this syntax really allow for some type unsafe 
code?

Thanks!

Martin


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

2017-01-20 Thread Alexandre Rousseau

Seconded. I came back to Elm after a 6 month absence following what I felt was 
an inconsistent  documentation set. Things have improved since then hence my 
coming back 2 weeks ago but some holes exist such as this one.

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

2017-01-20 Thread Alexandre Rousseau

That said, Tasks are covered in the core doc set so it's not all that bad. But 
the guide is the first document that I went through before realizing some key 
topics were amiss.

-- 
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: Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Maxime Dantec

Imagine a list of `Convertor a` like this :

convertors : List (Convertor x)
convertors =
  convertor1 :: convertor2 :: []

mapConvertors = List.map (\c -> c.convert "foo") convertors


You can see here, that you cannot map over `Convertor::convert` if you 
don't know what to give to the function.

Is it clear ? I can be more thorough if you want.


On Friday, January 20, 2017 at 12:06:49 PM UTC+1, Martin Cerny wrote:
>
> Hi all,
> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It 
> is probably deeply wrong, but I want to understand why it is wrong :-)
>
> What I was trying to do was to define a type like this:
>
> type alias Convertor a =
> { convert : b -> a
> }
>
>
> Here I get "Type alias `Convertor` must declare its use of type variable b"
> Now, I understand, why you cannot have 
>
> type alias X a =  { field1: a, field2: b }
>
> But with the source type of functions, things are IMHO different than with 
> values. You cannot write values of unbound types and you could not decide 
> whether two instances of X are really the same type. 
> But you can easily write functions that have unbound source types - like 
> this one:
>
> convertString: a -> String 
> convertString x =
> (toString x) ++ "_Foo"
>
>
> And since all of functions with this signature really have the same type 
> at JavaScript level, two instances of 'Convertor a' would always had the 
> same type.
>
> Now if I had
> c: Convertor String
> c = {convert = convertString}
> the whole thing seems type-safe...
>
> So my question is:
> Is this syntax forbidden, because it is an obscure feature that is not 
> worth supporting, or would this syntax really allow for some type unsafe 
> code?
>
> Thanks!
>
> Martin
>
>
>

-- 
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: Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Martin Cerny

Hi,
thanks for the answer. I however think I am missing something here - why 
wouldn't the compiler know what to give to the function? If I understand 
Elm correctly, it does not create multiple instances of functions with type 
variables for each type they are used with (as C++ would do). Instead Elm 
acts  akin to Java's type erasure: there is only one copy of a generic 
function and it is supposed to handle any input (and Elm indeed generates 
only one copy of the function). So in your example, all 'c.convert' 
functions accept anything (so the "foo" string is not a problem) and return 
an X so the result is 'List X'.

Or is this just a quirk the current Elm compiler implementation?

Thanks
Martin

On Friday, 20 January 2017 16:56:23 UTC+1, Maxime Dantec wrote:
>
> Imagine a list of `Convertor a` like this :
>
> convertors : List (Convertor x)
> convertors =
>   convertor1 :: convertor2 :: []
>
> mapConvertors = List.map (\c -> c.convert "foo") convertors
>
>
> You can see here, that you cannot map over `Convertor::convert` if you 
> don't know what to give to the function.
>
> Is it clear ? I can be more thorough if you want.
>
>
> On Friday, January 20, 2017 at 12:06:49 PM UTC+1, Martin Cerny wrote:
>>
>> Hi all,
>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It 
>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>
>> What I was trying to do was to define a type like this:
>>
>> type alias Convertor a =
>> { convert : b -> a
>> }
>>
>>
>> Here I get "Type alias `Convertor` must declare its use of type variable 
>> b"
>> Now, I understand, why you cannot have 
>>
>> type alias X a =  { field1: a, field2: b }
>>
>> But with the source type of functions, things are IMHO different than 
>> with values. You cannot write values of unbound types and you could not 
>> decide whether two instances of X are really the same type. 
>> But you can easily write functions that have unbound source types - like 
>> this one:
>>
>> convertString: a -> String 
>> convertString x =
>> (toString x) ++ "_Foo"
>>
>>
>> And since all of functions with this signature really have the same type 
>> at JavaScript level, two instances of 'Convertor a' would always had the 
>> same type.
>>
>> Now if I had
>> c: Convertor String
>> c = {convert = convertString}
>> the whole thing seems type-safe...
>>
>> So my question is:
>> Is this syntax forbidden, because it is an obscure feature that is not 
>> worth supporting, or would this syntax really allow for some type unsafe 
>> code?
>>
>> Thanks!
>>
>> Martin
>>
>>
>>

-- 
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: Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Maxime Dantec

Oh I see. I didn't noticed the Basic.toString. This is the only function in 
Elm that accepts anything anyway. If you swap that particular function to 
anything else it cannot work.

On Friday, January 20, 2017 at 5:41:48 PM UTC+1, Martin Cerny wrote:
>
> Hi,
> thanks for the answer. I however think I am missing something here - why 
> wouldn't the compiler know what to give to the function? If I understand 
> Elm correctly, it does not create multiple instances of functions with type 
> variables for each type they are used with (as C++ would do). Instead Elm 
> acts  akin to Java's type erasure: there is only one copy of a generic 
> function and it is supposed to handle any input (and Elm indeed generates 
> only one copy of the function). So in your example, all 'c.convert' 
> functions accept anything (so the "foo" string is not a problem) and return 
> an X so the result is 'List X'.
>
> Or is this just a quirk the current Elm compiler implementation?
>
> Thanks
> Martin
>
> On Friday, 20 January 2017 16:56:23 UTC+1, Maxime Dantec wrote:
>>
>> Imagine a list of `Convertor a` like this :
>>
>> convertors : List (Convertor x)
>> convertors =
>>   convertor1 :: convertor2 :: []
>>
>> mapConvertors = List.map (\c -> c.convert "foo") convertors
>>
>>
>> You can see here, that you cannot map over `Convertor::convert` if you 
>> don't know what to give to the function.
>>
>> Is it clear ? I can be more thorough if you want.
>>
>>
>> On Friday, January 20, 2017 at 12:06:49 PM UTC+1, Martin Cerny wrote:
>>>
>>> Hi all,
>>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It 
>>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>>
>>> What I was trying to do was to define a type like this:
>>>
>>> type alias Convertor a =
>>> { convert : b -> a
>>> }
>>>
>>>
>>> Here I get "Type alias `Convertor` must declare its use of type variable 
>>> b"
>>> Now, I understand, why you cannot have 
>>>
>>> type alias X a =  { field1: a, field2: b }
>>>
>>> But with the source type of functions, things are IMHO different than 
>>> with values. You cannot write values of unbound types and you could not 
>>> decide whether two instances of X are really the same type. 
>>> But you can easily write functions that have unbound source types - like 
>>> this one:
>>>
>>> convertString: a -> String 
>>> convertString x =
>>> (toString x) ++ "_Foo"
>>>
>>>
>>> And since all of functions with this signature really have the same type 
>>> at JavaScript level, two instances of 'Convertor a' would always had the 
>>> same type.
>>>
>>> Now if I had
>>> c: Convertor String
>>> c = {convert = convertString}
>>> the whole thing seems type-safe...
>>>
>>> So my question is:
>>> Is this syntax forbidden, because it is an obscure feature that is not 
>>> worth supporting, or would this syntax really allow for some type unsafe 
>>> code?
>>>
>>> Thanks!
>>>
>>> Martin
>>>
>>>
>>>

-- 
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] Maintainers wanted

2017-01-20 Thread Bogdan Popa

Hi folks,

Due to various reasons, I will no longer be focusing my attention on Elm 
for the foreseeable future. Unfortunately, this means that the libraries 
that I have created/have been maintaining so far will no longer be 
maintained by me. AFAICT, the following libraries are seeing a decent 
amount of use:

* elm-combine
* elm-datepicker
* elm-route
* elm-time

It would be sad to see them die off and I would feel bad letting down any 
of their current users by not providing a path forward. If you depend on 
any of these and would like to step up and start maintaining one or more of 
them, please e-mail me directly.

I had also been maintaining the Elm mode for Emacs for the past couple of 
years. I cannot give others commit access to that repository, but I'm sure 
@jcollard would happily do it if anyone wants to step up and maintain the 
project.

Thanks!
Bogdan

-- 
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 doesn't seem to do do TCO in my case. Bug?

2017-01-20 Thread mrbackend (Roy Brokvam)

Consider:
type Nat
= Zero
| Succ Nat


nat : Int -> Nat
nat n =
nat_ n Zero


nat_ : Int -> Nat -> Nat
nat_ n curr =
if n <= 0 then
curr
else
nat_ (n - 1) (Succ curr)

Using tail recursion, this should be stack safe in Elm (as far as I 
understand). But I get a stack overflow for large values of n (>= 5000). Is 
my function really tail recursive, or might there be a bug in 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] Rx-like subscription to View's events

2017-01-20 Thread Илья Толлю

Hello, everybody!

I'm new to Elm and I like its architecture very much. Except one nuance 
annoys me.
If you take e.g. CycleJS there we observe view's events by selectors 
external to view. I.e. view is not responsible for routing its events. That 
responsibility is given to another part of code, which creates Observables. 
So, we can use Jade/Pug or another templating technology and cleanly 
separate view declaration and events listening declaration. 
Considering that Elm is functional language, there can be some pattern that 
aims to achieve the same result, so I could write View and Observables in 
different sections.

It would be great to know your opinion and experience.

Best regards! 
Ilja Tollu

-- 
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 doesn't seem to do do TCO in my case. Bug?

2017-01-20 Thread OvermindDL1

On Friday, January 20, 2017 at 11:17:32 AM UTC-7, mrbackend (Roy Brokvam) 
wrote:
>
> Consider:
> type Nat
> = Zero
> | Succ Nat
>
>
> nat : Int -> Nat
> nat n =
> nat_ n Zero
>
>
> nat_ : Int -> Nat -> Nat
> nat_ n curr =
> if n <= 0 then
> curr
> else
> nat_ (n - 1) (Succ curr)
>
> Using tail recursion, this should be stack safe in Elm (as far as I 
> understand). But I get a stack overflow for large values of n (>= 5000). Is 
> my function really tail recursive, or might there be a bug in Elm?
>
 
It compiles into this:
```elm
var _user$project$Temp1484937158714761$Succ = function (a) {
return {ctor: 'Succ', _0: a};
};
var _user$project$Temp1484937158714761$nat_ = F2(
function (n, curr) {
nat_:
while (true) {
if (_elm_lang$core$Native_Utils.cmp(n, 0) < 1) {
return curr;
} else {
var _v0 = n - 1,
_v1 = _user$project$Temp1484937158714761$Succ(curr);
n = _v0;
curr = _v1;
continue nat_;
}
}
});
var _user$project$Temp1484937158714761$Zero = {ctor: 'Zero'};
var _user$project$Temp1484937158714761$nat = function (n) {
return A2(_user$project$Temp1484937158714761$nat_, n, 
_user$project$Temp1484937158714761$Zero);
};
```
So it does look TCO'd, what is the exact stack trace that you got?

-- 
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] Rx-like subscription to View's events

2017-01-20 Thread Peter Damoc

Hi Ilja,

It is very common to reach for previous knowledge, previous ways of
approaching code structure.

My advice is to spend more time with Elm and just do things its way.

If after one more week with Elm you still feel the same way, write actua
code in the two ways: the official way and the way you would ideally want
to write it and present it here side by side.
In the Elm community there is a strong emphasis on using practical examples
in order to discuss various issues.

Show us some code and we'll better understand your needs.



On Fri, Jan 20, 2017 at 1:38 PM, Илья Толлю  wrote:

> Hello, everybody!
>
> I'm new to Elm and I like its architecture very much. Except one nuance
> annoys me.
> If you take e.g. CycleJS there we observe view's events by selectors
> external to view. I.e. view is not responsible for routing its events. That
> responsibility is given to another part of code, which creates Observables.
> So, we can use Jade/Pug or another templating technology and cleanly
> separate view declaration and events listening declaration.
> Considering that Elm is functional language, there can be some pattern
> that aims to achieve the same result, so I could write View and Observables
> in different sections.
>
> It would be great to know your opinion and experience.
>
> Best regards!
> Ilja Tollu
>
> --
> 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.

Re: [elm-discuss] Maintainers wanted

2017-01-20 Thread Joey Eremondi

Might these be candidates for migrating to elm-community?

On Fri, Jan 20, 2017 at 2:29 AM, Bogdan Popa  wrote:

> Hi folks,
>
> Due to various reasons, I will no longer be focusing my attention on Elm
> for the foreseeable future. Unfortunately, this means that the libraries
> that I have created/have been maintaining so far will no longer be
> maintained by me. AFAICT, the following libraries are seeing a decent
> amount of use:
>
> * elm-combine
> * elm-datepicker
> * elm-route
> * elm-time
>
> It would be sad to see them die off and I would feel bad letting down any
> of their current users by not providing a path forward. If you depend on
> any of these and would like to step up and start maintaining one or more of
> them, please e-mail me directly.
>
> I had also been maintaining the Elm mode for Emacs for the past couple of
> years. I cannot give others commit access to that repository, but I'm sure
> @jcollard would happily do it if anyone wants to step up and maintain the
> project.
>
> Thanks!
> Bogdan
>
> --
> 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] Maintainers wanted

2017-01-20 Thread Noah Hall

Please move these to elm-community. I can help move them over. Reach
on slack on #elm-community

On Fri, Jan 20, 2017 at 7:38 PM, Joey Eremondi  wrote:
> Might these be candidates for migrating to elm-community?
>
> On Fri, Jan 20, 2017 at 2:29 AM, Bogdan Popa  wrote:
>>
>> Hi folks,
>>
>> Due to various reasons, I will no longer be focusing my attention on Elm
>> for the foreseeable future. Unfortunately, this means that the libraries
>> that I have created/have been maintaining so far will no longer be
>> maintained by me. AFAICT, the following libraries are seeing a decent amount
>> of use:
>>
>> * elm-combine
>> * elm-datepicker
>> * elm-route
>> * elm-time
>>
>> It would be sad to see them die off and I would feel bad letting down any
>> of their current users by not providing a path forward. If you depend on any
>> of these and would like to step up and start maintaining one or more of
>> them, please e-mail me directly.
>>
>> I had also been maintaining the Elm mode for Emacs for the past couple of
>> years. I cannot give others commit access to that repository, but I'm sure
>> @jcollard would happily do it if anyone wants to step up and maintain the
>> project.
>>
>> Thanks!
>> Bogdan
>>
>> --
>> 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.

-- 
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] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Nick H

All type variables need to be mentioned on the left side of the type alias
definition. But that doesn't mean you need to bind them. This compiles fine:

type alias Convertor b a =
{ convert : b -> a
}

c: Convertor b String
c = {convert = convertString}

In other words, the unbound type variable needs to be mentioned in the type
signature, even if you are wrapping more abstractions over it.

On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  wrote:

> Hi all,
> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
> is probably deeply wrong, but I want to understand why it is wrong :-)
>
> What I was trying to do was to define a type like this:
>
> type alias Convertor a =
> { convert : b -> a
> }
>
>
> Here I get "Type alias `Convertor` must declare its use of type variable b"
> Now, I understand, why you cannot have
>
> type alias X a =  { field1: a, field2: b }
>
> But with the source type of functions, things are IMHO different than with
> values. You cannot write values of unbound types and you could not decide
> whether two instances of X are really the same type.
> But you can easily write functions that have unbound source types - like
> this one:
>
> convertString: a -> String
> convertString x =
> (toString x) ++ "_Foo"
>
>
> And since all of functions with this signature really have the same type
> at JavaScript level, two instances of 'Convertor a' would always had the
> same type.
>
> Now if I had
> c: Convertor String
> c = {convert = convertString}
> the whole thing seems type-safe...
>
> So my question is:
> Is this syntax forbidden, because it is an obscure feature that is not
> worth supporting, or would this syntax really allow for some type unsafe
> code?
>
> Thanks!
>
> Martin
>
>
> --
> 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] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Martin Cerny

Thanks for the ideas, but neither is satisfactory for my (crazy and 
contrived) use case :-)

@Maxime:
Once again, I maybe missing something, but Basic.toString is not the only 
function that does that. My particular aim was to combine native functions 
and functions that simply ignore the parameter which are both examples of 
functions that can accept anything.

Also, more broadly you could have definitions such as:
type alias Mapper a =
{ map : List b -> (b -> a) -> List a
}

now - due to the erasing implementation of Elm, I can execute the map 
function safely for any type of input as long as the first two parameters 
match. Now this latter case would require the compiler to infer things like
m : Mapper Int

x = m.map ["a" "b"]
--x: (String -> Int) -> List Int

Which may and may not be the exact same thing the compiler already does for 
regular functions.
There might even be a non-crazy use case for that :-)

@Nick:
I am aware of that possiblity, but adding type variables is not an option 
in my use case. I need to be able to call things like (highly contrived for 
brevity),
func: Convertor a -> Int -> String -> (a,a)
func conv i s =
  (conv.convert i, conv.convert s)

which I could not do if I bind the type variable outside the individual 
subexpressions.

In case you are wondering why would I want such madness, I was toying with 
the idea of having automatic serialization/deserialization (JSON/XML etc.) 
of arbitrary non-function types (records and possibly also union types) in 
almost pure Elm, with only a single magic native function. The idea was 
like that:
--pure Elm type
type TypeInfo a = ...

--JavaScript magic
getTypeInfo: a -> TypeInfo a

--pure Elm
decoder: TypeInfo a -> Json.Decode.Decoder a

However, I ended up requiring the functions of the aforementioned weird 
form in TypeInfo a so it probably cannot work. I am aware of cases that 
could not be solved in principle without help from compiler even if 
everything worked as I hoped it would (and maybe there are other problems I 
missed), but I had fun trying :-)

Still curious, if this idea could work in general or if it implies some 
problems for the whole type system...

Thanks
Martin

On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>
> All type variables need to be mentioned on the left side of the type alias 
> definition. But that doesn't mean you need to bind them. This compiles fine:
>
> type alias Convertor b a =
> { convert : b -> a
> }
>
> c: Convertor b String
> c = {convert = convertString}
>
> In other words, the unbound type variable needs to be mentioned in the 
> type signature, even if you are wrapping more abstractions over it.
>
> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  > wrote:
>
>> Hi all,
>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It 
>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>
>> What I was trying to do was to define a type like this:
>>
>> type alias Convertor a =
>> { convert : b -> a
>> }
>>
>>
>> Here I get "Type alias `Convertor` must declare its use of type variable 
>> b"
>> Now, I understand, why you cannot have 
>>
>> type alias X a =  { field1: a, field2: b }
>>
>> But with the source type of functions, things are IMHO different than 
>> with values. You cannot write values of unbound types and you could not 
>> decide whether two instances of X are really the same type. 
>> But you can easily write functions that have unbound source types - like 
>> this one:
>>
>> convertString: a -> String 
>> convertString x =
>> (toString x) ++ "_Foo"
>>
>>
>> And since all of functions with this signature really have the same type 
>> at JavaScript level, two instances of 'Convertor a' would always had the 
>> same type.
>>
>> Now if I had
>> c: Convertor String
>> c = {convert = convertString}
>> the whole thing seems type-safe...
>>
>> So my question is:
>> Is this syntax forbidden, because it is an obscure feature that is not 
>> worth supporting, or would this syntax really allow for some type unsafe 
>> code?
>>
>> Thanks!
>>
>> Martin
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Joey Eremondi

I'm still grokking what you want, but I think what you're describing is
higher-rank polymorphism.

This is unlikely to end up in Elm any time soon: it's pretty advanced, and
it breaks type inference. If you *really* want a language that has it, try
Haskell(GHCJS) or PureScript.

But I suspect there is a way to get the results you want in Elm, the road
there might just be different.

On Fri, Jan 20, 2017 at 11:06 AM, Martin Cerny  wrote:

> Thanks for the ideas, but neither is satisfactory for my (crazy and
> contrived) use case :-)
>
> @Maxime:
> Once again, I maybe missing something, but Basic.toString is not the only
> function that does that. My particular aim was to combine native functions
> and functions that simply ignore the parameter which are both examples of
> functions that can accept anything.
>
> Also, more broadly you could have definitions such as:
> type alias Mapper a =
> { map : List b -> (b -> a) -> List a
> }
>
> now - due to the erasing implementation of Elm, I can execute the map
> function safely for any type of input as long as the first two parameters
> match. Now this latter case would require the compiler to infer things like
> m : Mapper Int
>
> x = m.map ["a" "b"]
> --x: (String -> Int) -> List Int
>
> Which may and may not be the exact same thing the compiler already does
> for regular functions.
> There might even be a non-crazy use case for that :-)
>
> @Nick:
> I am aware of that possiblity, but adding type variables is not an option
> in my use case. I need to be able to call things like (highly contrived for
> brevity),
> func: Convertor a -> Int -> String -> (a,a)
> func conv i s =
>   (conv.convert i, conv.convert s)
>
> which I could not do if I bind the type variable outside the individual
> subexpressions.
>
> In case you are wondering why would I want such madness, I was toying with
> the idea of having automatic serialization/deserialization (JSON/XML etc.)
> of arbitrary non-function types (records and possibly also union types) in
> almost pure Elm, with only a single magic native function. The idea was
> like that:
> --pure Elm type
> type TypeInfo a = ...
>
> --JavaScript magic
> getTypeInfo: a -> TypeInfo a
>
> --pure Elm
> decoder: TypeInfo a -> Json.Decode.Decoder a
>
> However, I ended up requiring the functions of the aforementioned weird
> form in TypeInfo a so it probably cannot work. I am aware of cases that
> could not be solved in principle without help from compiler even if
> everything worked as I hoped it would (and maybe there are other problems I
> missed), but I had fun trying :-)
>
> Still curious, if this idea could work in general or if it implies some
> problems for the whole type system...
>
> Thanks
> Martin
>
>
> On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>>
>> All type variables need to be mentioned on the left side of the type
>> alias definition. But that doesn't mean you need to bind them. This
>> compiles fine:
>>
>> type alias Convertor b a =
>> { convert : b -> a
>> }
>>
>> c: Convertor b String
>> c = {convert = convertString}
>>
>> In other words, the unbound type variable needs to be mentioned in the
>> type signature, even if you are wrapping more abstractions over it.
>>
>> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  wrote:
>>
>>> Hi all,
>>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
>>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>>
>>> What I was trying to do was to define a type like this:
>>>
>>> type alias Convertor a =
>>> { convert : b -> a
>>> }
>>>
>>>
>>> Here I get "Type alias `Convertor` must declare its use of type variable
>>> b"
>>> Now, I understand, why you cannot have
>>>
>>> type alias X a =  { field1: a, field2: b }
>>>
>>> But with the source type of functions, things are IMHO different than
>>> with values. You cannot write values of unbound types and you could not
>>> decide whether two instances of X are really the same type.
>>> But you can easily write functions that have unbound source types - like
>>> this one:
>>>
>>> convertString: a -> String
>>> convertString x =
>>> (toString x) ++ "_Foo"
>>>
>>>
>>> And since all of functions with this signature really have the same type
>>> at JavaScript level, two instances of 'Convertor a' would always had the
>>> same type.
>>>
>>> Now if I had
>>> c: Convertor String
>>> c = {convert = convertString}
>>> the whole thing seems type-safe...
>>>
>>> So my question is:
>>> Is this syntax forbidden, because it is an obscure feature that is not
>>> worth supporting, or would this syntax really allow for some type unsafe
>>> code?
>>>
>>> Thanks!
>>>
>>> Martin
>>>
>>>
>>> --
>>> 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/optou

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Nick H

OK, I understand... you're up in the stratosphere somewhere :-)

I can't offer anymore insight, but to back up Maxime. toString and the
equality operators are the only functions that take arguments of
unspecified type and return a value with a fixed type.

On Fri, Jan 20, 2017 at 11:06 AM, Martin Cerny  wrote:

> Thanks for the ideas, but neither is satisfactory for my (crazy and
> contrived) use case :-)
>
> @Maxime:
> Once again, I maybe missing something, but Basic.toString is not the only
> function that does that. My particular aim was to combine native functions
> and functions that simply ignore the parameter which are both examples of
> functions that can accept anything.
>
> Also, more broadly you could have definitions such as:
> type alias Mapper a =
> { map : List b -> (b -> a) -> List a
> }
>
> now - due to the erasing implementation of Elm, I can execute the map
> function safely for any type of input as long as the first two parameters
> match. Now this latter case would require the compiler to infer things like
> m : Mapper Int
>
> x = m.map ["a" "b"]
> --x: (String -> Int) -> List Int
>
> Which may and may not be the exact same thing the compiler already does
> for regular functions.
> There might even be a non-crazy use case for that :-)
>
> @Nick:
> I am aware of that possiblity, but adding type variables is not an option
> in my use case. I need to be able to call things like (highly contrived for
> brevity),
> func: Convertor a -> Int -> String -> (a,a)
> func conv i s =
>   (conv.convert i, conv.convert s)
>
> which I could not do if I bind the type variable outside the individual
> subexpressions.
>
> In case you are wondering why would I want such madness, I was toying with
> the idea of having automatic serialization/deserialization (JSON/XML etc.)
> of arbitrary non-function types (records and possibly also union types) in
> almost pure Elm, with only a single magic native function. The idea was
> like that:
> --pure Elm type
> type TypeInfo a = ...
>
> --JavaScript magic
> getTypeInfo: a -> TypeInfo a
>
> --pure Elm
> decoder: TypeInfo a -> Json.Decode.Decoder a
>
> However, I ended up requiring the functions of the aforementioned weird
> form in TypeInfo a so it probably cannot work. I am aware of cases that
> could not be solved in principle without help from compiler even if
> everything worked as I hoped it would (and maybe there are other problems I
> missed), but I had fun trying :-)
>
> Still curious, if this idea could work in general or if it implies some
> problems for the whole type system...
>
> Thanks
> Martin
>
>
> On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>>
>> All type variables need to be mentioned on the left side of the type
>> alias definition. But that doesn't mean you need to bind them. This
>> compiles fine:
>>
>> type alias Convertor b a =
>> { convert : b -> a
>> }
>>
>> c: Convertor b String
>> c = {convert = convertString}
>>
>> In other words, the unbound type variable needs to be mentioned in the
>> type signature, even if you are wrapping more abstractions over it.
>>
>> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  wrote:
>>
>>> Hi all,
>>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
>>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>>
>>> What I was trying to do was to define a type like this:
>>>
>>> type alias Convertor a =
>>> { convert : b -> a
>>> }
>>>
>>>
>>> Here I get "Type alias `Convertor` must declare its use of type variable
>>> b"
>>> Now, I understand, why you cannot have
>>>
>>> type alias X a =  { field1: a, field2: b }
>>>
>>> But with the source type of functions, things are IMHO different than
>>> with values. You cannot write values of unbound types and you could not
>>> decide whether two instances of X are really the same type.
>>> But you can easily write functions that have unbound source types - like
>>> this one:
>>>
>>> convertString: a -> String
>>> convertString x =
>>> (toString x) ++ "_Foo"
>>>
>>>
>>> And since all of functions with this signature really have the same type
>>> at JavaScript level, two instances of 'Convertor a' would always had the
>>> same type.
>>>
>>> Now if I had
>>> c: Convertor String
>>> c = {convert = convertString}
>>> the whole thing seems type-safe...
>>>
>>> So my question is:
>>> Is this syntax forbidden, because it is an obscure feature that is not
>>> worth supporting, or would this syntax really allow for some type unsafe
>>> code?
>>>
>>> Thanks!
>>>
>>> Martin
>>>
>>>
>>> --
>>> 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 unsubscri

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

2017-01-20 Thread Joey Eremondi

>
> toString and the equality operators are the only functions that take
> arguments of unspecified type and return a value with a fixed type


Except for functions that ignore their argument.

It's perfectly valid to do
intoInt : a -> Int
intoInt _ = 3

But it's probably not what you're looking for.

On Fri, Jan 20, 2017 at 11:20 AM, Nick H  wrote:

> OK, I understand... you're up in the stratosphere somewhere :-)
>
> I can't offer anymore insight, but to back up Maxime. toString and the
> equality operators are the only functions that take arguments of
> unspecified type and return a value with a fixed type.
>
> On Fri, Jan 20, 2017 at 11:06 AM, Martin Cerny  wrote:
>
>> Thanks for the ideas, but neither is satisfactory for my (crazy and
>> contrived) use case :-)
>>
>> @Maxime:
>> Once again, I maybe missing something, but Basic.toString is not the
>> only function that does that. My particular aim was to combine native
>> functions and functions that simply ignore the parameter which are both
>> examples of functions that can accept anything.
>>
>> Also, more broadly you could have definitions such as:
>> type alias Mapper a =
>> { map : List b -> (b -> a) -> List a
>> }
>>
>> now - due to the erasing implementation of Elm, I can execute the map
>> function safely for any type of input as long as the first two parameters
>> match. Now this latter case would require the compiler to infer things like
>> m : Mapper Int
>>
>> x = m.map ["a" "b"]
>> --x: (String -> Int) -> List Int
>>
>> Which may and may not be the exact same thing the compiler already does
>> for regular functions.
>> There might even be a non-crazy use case for that :-)
>>
>> @Nick:
>> I am aware of that possiblity, but adding type variables is not an option
>> in my use case. I need to be able to call things like (highly contrived for
>> brevity),
>> func: Convertor a -> Int -> String -> (a,a)
>> func conv i s =
>>   (conv.convert i, conv.convert s)
>>
>> which I could not do if I bind the type variable outside the individual
>> subexpressions.
>>
>> In case you are wondering why would I want such madness, I was toying
>> with the idea of having automatic serialization/deserialization (JSON/XML
>> etc.) of arbitrary non-function types (records and possibly also union
>> types) in almost pure Elm, with only a single magic native function. The
>> idea was like that:
>> --pure Elm type
>> type TypeInfo a = ...
>>
>> --JavaScript magic
>> getTypeInfo: a -> TypeInfo a
>>
>> --pure Elm
>> decoder: TypeInfo a -> Json.Decode.Decoder a
>>
>> However, I ended up requiring the functions of the aforementioned weird
>> form in TypeInfo a so it probably cannot work. I am aware of cases that
>> could not be solved in principle without help from compiler even if
>> everything worked as I hoped it would (and maybe there are other problems I
>> missed), but I had fun trying :-)
>>
>> Still curious, if this idea could work in general or if it implies some
>> problems for the whole type system...
>>
>> Thanks
>> Martin
>>
>>
>> On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>>>
>>> All type variables need to be mentioned on the left side of the type
>>> alias definition. But that doesn't mean you need to bind them. This
>>> compiles fine:
>>>
>>> type alias Convertor b a =
>>> { convert : b -> a
>>> }
>>>
>>> c: Convertor b String
>>> c = {convert = convertString}
>>>
>>> In other words, the unbound type variable needs to be mentioned in the
>>> type signature, even if you are wrapping more abstractions over it.
>>>
>>> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  wrote:
>>>
 Hi all,
 I was trying to do some Elm Voodoo and I stumbled upon a funny thing.
 It is probably deeply wrong, but I want to understand why it is wrong :-)

 What I was trying to do was to define a type like this:

 type alias Convertor a =
 { convert : b -> a
 }


 Here I get "Type alias `Convertor` must declare its use of type
 variable b"
 Now, I understand, why you cannot have

 type alias X a =  { field1: a, field2: b }

 But with the source type of functions, things are IMHO different than
 with values. You cannot write values of unbound types and you could not
 decide whether two instances of X are really the same type.
 But you can easily write functions that have unbound source types -
 like this one:

 convertString: a -> String
 convertString x =
 (toString x) ++ "_Foo"


 And since all of functions with this signature really have the same
 type at JavaScript level, two instances of 'Convertor a' would always had
 the same type.

 Now if I had
 c: Convertor String
 c = {convert = convertString}
 the whole thing seems type-safe...

 So my question is:
 Is this syntax forbidden, because it is an obscure feature that is not
 worth supporting, or would this syntax really allow for so

[elm-discuss] Re: Rx-like subscription to View's events

2017-01-20 Thread jphedley

I wasn't aware of Jade Templates being a common use case for the Cycle.js 
community. I was only aware of this issue-
https://github.com/cyclejs/cyclejs/issues/321
resulting in this proof of concept-
http://www.webpackbin.com/Nkd5aKiIf
which is made possible by Cycle.JS not attaching event handlers in the view 
function, as noted by Andre Statlz in this discussion,
https://www.reddit.com/r/javascript/comments/3zr6i0/conversation_whats_the_core_differences_between/
unlike Elm.

I really enjoy thinking in the pure functions of Hyperscript-Helpers or Elm 
of the Html package, for which the creator of Cycle.JS seemingly strongly 
supports
http://staltz.com/some-problems-with-react-redux.html
https://medium.com/@jador/jsx-4b978fbeb290#.8g4fr4fnc
over "templates" like JSX. But to each their own.

On Friday, January 20, 2017 at 10:17:32 AM UTC-8, Илья Толлю wrote:
>
> Hello, everybody!
>
> I'm new to Elm and I like its architecture very much. Except one nuance 
> annoys me.
> If you take e.g. CycleJS there we observe view's events by selectors 
> external to view. I.e. view is not responsible for routing its events. That 
> responsibility is given to another part of code, which creates Observables. 
> So, we can use Jade/Pug or another templating technology and cleanly 
> separate view declaration and events listening declaration. 
> Considering that Elm is functional language, there can be some pattern 
> that aims to achieve the same result, so I could write View and Observables 
> in different sections.
>
> It would be great to know your opinion and experience.
>
> Best regards! 
> Ilja Tollu
>

-- 
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] Rx-like subscription to View's events

2017-01-20 Thread jphedley

Very interesting. I didn't realize this was a common use case in the 
Cycle.JS community. I was only aware of this issue
https://github.com/cyclejs/cyclejs/issues/321
resulting in this proof of concept
http://www.webpackbin.com/Nkd5aKiIf
but you're correct that Elm attaching event handlers in the view produces 
this limitation, not found in Cycle.JS, cause the don't, as noted by Andre 
Staltz in this exchange
https://www.reddit.com/r/javascript/comments/3zr6i0/conversation_whats_the_core_differences_between/

I really love Hyperscript Helpers for Cycle.JS and Elm's Html package, but 
perhaps this is due to my background. To each their own. 


On Friday, January 20, 2017 at 10:37:10 AM UTC-8, Peter Damoc wrote:
>
> Hi Ilja, 
>
> It is very common to reach for previous knowledge, previous ways of 
> approaching code structure. 
>
> My advice is to spend more time with Elm and just do things its way. 
>
> If after one more week with Elm you still feel the same way, write actua 
> code in the two ways: the official way and the way you would ideally want 
> to write it and present it here side by side. 
> In the Elm community there is a strong emphasis on using practical 
> examples in order to discuss various issues. 
>
> Show us some code and we'll better understand your needs. 
>
>
>
> On Fri, Jan 20, 2017 at 1:38 PM, Илья Толлю  > wrote:
>
>> Hello, everybody!
>>
>> I'm new to Elm and I like its architecture very much. Except one nuance 
>> annoys me.
>> If you take e.g. CycleJS there we observe view's events by selectors 
>> external to view. I.e. view is not responsible for routing its events. That 
>> responsibility is given to another part of code, which creates Observables. 
>> So, we can use Jade/Pug or another templating technology and cleanly 
>> separate view declaration and events listening declaration. 
>> Considering that Elm is functional language, there can be some pattern 
>> that aims to achieve the same result, so I could write View and Observables 
>> in different sections.
>>
>> It would be great to know your opinion and experience.
>>
>> Best regards! 
>> Ilja Tollu
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> 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.

[elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

2017-01-20 Thread GordonBGood

The code is TCO'ed but look at the data structure:  the code is 
successively calling the `Succ` function to build a successively nested 
record structure, which overflows the stack at about 5000 recursive nests 
in the case of the OP.

On Saturday, 21 January 2017 01:36:36 UTC+7, OvermindDL1 wrote:
>
> On Friday, January 20, 2017 at 11:17:32 AM UTC-7, mrbackend (Roy Brokvam) 
> wrote:
>>
>> Consider:
>> type Nat
>> = Zero
>> | Succ Nat
>>
>>
>> nat : Int -> Nat
>> nat n =
>> nat_ n Zero
>>
>>
>> nat_ : Int -> Nat -> Nat
>> nat_ n curr =
>> if n <= 0 then
>> curr
>> else
>> nat_ (n - 1) (Succ curr)
>>
>> Using tail recursion, this should be stack safe in Elm (as far as I 
>> understand). But I get a stack overflow for large values of n (>= 5000). Is 
>> my function really tail recursive, or might there be a bug in Elm?
>>
>  
> It compiles into this:
> ```elm
> var _user$project$Temp1484937158714761$Succ = function (a) {
> return {ctor: 'Succ', _0: a};
> };
> var _user$project$Temp1484937158714761$nat_ = F2(
> function (n, curr) {
> nat_:
> while (true) {
> if (_elm_lang$core$Native_Utils.cmp(n, 0) < 1) {
> return curr;
> } else {
> var _v0 = n - 1,
> _v1 = _user$project$Temp1484937158714761$Succ(curr);
> n = _v0;
> curr = _v1;
> continue nat_;
> }
> }
> });
> var _user$project$Temp1484937158714761$Zero = {ctor: 'Zero'};
> var _user$project$Temp1484937158714761$nat = function (n) {
> return A2(_user$project$Temp1484937158714761$nat_, n, 
> _user$project$Temp1484937158714761$Zero);
> };
> ```
> So it does look TCO'd, what is the exact stack trace that you got?
>

-- 
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: Elm doesn't seem to do do TCO in my case. Bug?

2017-01-20 Thread Joey Eremondi

But Succ shouldn't be called recursively, it should just take its argument,
wrap it in a record, and return immediately. So Succ is getting called 5000
times, but never in a stack 5000 deep. (This is clearly the case, because
if it wasn't returning, we'd never hit the continue to jump back to the
while loop and loop again).

Are you perhaps trying to print it? The print function would likely be
recursive, and it could easily stack-overflow.

On Fri, Jan 20, 2017 at 6:12 PM, GordonBGood  wrote:

> The code is TCO'ed but look at the data structure:  the code is
> successively calling the `Succ` function to build a successively nested
> record structure, which overflows the stack at about 5000 recursive nests
> in the case of the OP.
>
>
> On Saturday, 21 January 2017 01:36:36 UTC+7, OvermindDL1 wrote:
>>
>> On Friday, January 20, 2017 at 11:17:32 AM UTC-7, mrbackend (Roy Brokvam)
>> wrote:
>>>
>>> Consider:
>>> type Nat
>>> = Zero
>>> | Succ Nat
>>>
>>>
>>> nat : Int -> Nat
>>> nat n =
>>> nat_ n Zero
>>>
>>>
>>> nat_ : Int -> Nat -> Nat
>>> nat_ n curr =
>>> if n <= 0 then
>>> curr
>>> else
>>> nat_ (n - 1) (Succ curr)
>>>
>>> Using tail recursion, this should be stack safe in Elm (as far as I
>>> understand). But I get a stack overflow for large values of n (>= 5000). Is
>>> my function really tail recursive, or might there be a bug in Elm?
>>>
>>
>> It compiles into this:
>> ```elm
>> var _user$project$Temp1484937158714761$Succ = function (a) {
>> return {ctor: 'Succ', _0: a};
>> };
>> var _user$project$Temp1484937158714761$nat_ = F2(
>> function (n, curr) {
>> nat_:
>> while (true) {
>> if (_elm_lang$core$Native_Utils.cmp(n, 0) < 1) {
>> return curr;
>> } else {
>> var _v0 = n - 1,
>> _v1 = _user$project$Temp1484937158714761$Succ(curr);
>> n = _v0;
>> curr = _v1;
>> continue nat_;
>> }
>> }
>> });
>> var _user$project$Temp1484937158714761$Zero = {ctor: 'Zero'};
>> var _user$project$Temp1484937158714761$nat = function (n) {
>> return A2(_user$project$Temp1484937158714761$nat_, n,
>> _user$project$Temp1484937158714761$Zero);
>> };
>> ```
>> So it does look TCO'd, what is the exact stack trace that you got?
>>
> --
> 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] Re: Elm doesn't seem to do do TCO in my case. Bug?

2017-01-20 Thread mrbackend (Roy Brokvam)

I can confirm that the problem was that elm-repl got a stack overflow when 
trying to print the value. Stupid me for not thinking about that... :(

On Saturday, 21 January 2017 03:16:57 UTC+1, Joey Eremondi wrote:
>
> But Succ shouldn't be called recursively, it should just take its 
> argument, wrap it in a record, and return immediately. So Succ is getting 
> called 5000 times, but never in a stack 5000 deep. (This is clearly the 
> case, because if it wasn't returning, we'd never hit the continue to jump 
> back to the while loop and loop again).
>
> Are you perhaps trying to print it? The print function would likely be 
> recursive, and it could easily stack-overflow.
>
> On Fri, Jan 20, 2017 at 6:12 PM, GordonBGood  > wrote:
>
>> The code is TCO'ed but look at the data structure:  the code is 
>> successively calling the `Succ` function to build a successively nested 
>> record structure, which overflows the stack at about 5000 recursive nests 
>> in the case of the OP.
>>
>>
>> On Saturday, 21 January 2017 01:36:36 UTC+7, OvermindDL1 wrote:
>>>
>>> On Friday, January 20, 2017 at 11:17:32 AM UTC-7, mrbackend (Roy 
>>> Brokvam) wrote:

 Consider:
 type Nat
 = Zero
 | Succ Nat


 nat : Int -> Nat
 nat n =
 nat_ n Zero


 nat_ : Int -> Nat -> Nat
 nat_ n curr =
 if n <= 0 then
 curr
 else
 nat_ (n - 1) (Succ curr)

 Using tail recursion, this should be stack safe in Elm (as far as I 
 understand). But I get a stack overflow for large values of n (>= 5000). 
 Is 
 my function really tail recursive, or might there be a bug in Elm?

>>>  
>>> It compiles into this:
>>> ```elm
>>> var _user$project$Temp1484937158714761$Succ = function (a) {
>>> return {ctor: 'Succ', _0: a};
>>> };
>>> var _user$project$Temp1484937158714761$nat_ = F2(
>>> function (n, curr) {
>>> nat_:
>>> while (true) {
>>> if (_elm_lang$core$Native_Utils.cmp(n, 0) < 1) {
>>> return curr;
>>> } else {
>>> var _v0 = n - 1,
>>> _v1 = _user$project$Temp1484937158714761$Succ(curr);
>>> n = _v0;
>>> curr = _v1;
>>> continue nat_;
>>> }
>>> }
>>> });
>>> var _user$project$Temp1484937158714761$Zero = {ctor: 'Zero'};
>>> var _user$project$Temp1484937158714761$nat = function (n) {
>>> return A2(_user$project$Temp1484937158714761$nat_, n, 
>>> _user$project$Temp1484937158714761$Zero);
>>> };
>>> ```
>>> So it does look TCO'd, what is the exact stack trace that you got?
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Re: Rx-like subscription to View's events

2017-01-20 Thread Peter Damoc

On Sat, Jan 21, 2017 at 2:15 AM, jphedley  wrote:

> I wasn't aware of Jade Templates being a common use case for the Cycle.js
> community. I was only aware of this issue-
> https://github.com/cyclejs/cyclejs/issues/321
> resulting in this proof of concept-
> http://www.webpackbin.com/Nkd5aKiIf
> which is made possible by Cycle.JS not attaching event handlers in the
> view function, as noted by Andre Statlz in this discussion,
> https://www.reddit.com/r/javascript/comments/3zr6i0/
> conversation_whats_the_core_differences_between/
> unlike Elm.
>

Well, Elm doesn't have templates because elm doesn't need templates. It has
the entire language available for you to build whatever html you want based
on your model.

Also, Elm doesn't attach event handlers in the view function, it just
describes what kind of message would the event generate.
You can think of these as translators from the language of the html element
to the language of your app.
So, instead of generating a "click" event, a button will generate a
specific message.

If you want your template to have no idea of these messages you can give it
the messages as parameters.
You will then use this template in some Elm Architecture construct

Your entire example, in Elm would look like this:

module Main exposing (..)

import Html exposing (beginnerProgram, div, button, h1, text)
import Html.Events exposing (onClick)

main =
beginnerProgram { model = 0, view = view, update = update }

incTemplate msg count =
div []
[ button [ onClick msg ] [ text "Click me" ]
, h1 [] [ text (toString count) ]
]

view model =
incTemplate Increment model

type Msg
= Increment

update msg model =
case msg of
Increment ->
model + 1

I think it looks clearer.

As a side note, the Elm that is mentioned in that reddit discussion you
linked is no more.
Signals and FRP constructs are gone from the language.
All we have now is The Elm Architecture.

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

[elm-discuss] Elm Documentation

[elm-discuss] Why are unbound type variables forbidden for functions in records?

[elm-discuss] Elm Documentation

[elm-discuss] Elm Documentation

[elm-discuss] Re: Why are unbound type variables forbidden for functions in records?

[elm-discuss] Re: Why are unbound type variables forbidden for functions in records?

[elm-discuss] Re: Why are unbound type variables forbidden for functions in records?

[elm-discuss] Maintainers wanted

[elm-discuss] Elm doesn't seem to do do TCO in my case. Bug?

[elm-discuss] Rx-like subscription to View's events

[elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

Re: [elm-discuss] Rx-like subscription to View's events

Re: [elm-discuss] Maintainers wanted

Re: [elm-discuss] Maintainers wanted

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

[elm-discuss] Re: Rx-like subscription to View's events

Re: [elm-discuss] Rx-like subscription to View's events

[elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

Re: [elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

Re: [elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

Re: [elm-discuss] Re: Rx-like subscription to View's events

25 matches

Site Navigation

Mail list logo

Footer information