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

[Richard Feldman]

>
> However, strings and numbers still need to be used in production apps for 
> several reasons:
> 1) Union Types is not supported in Json, so one needs to convert to/from 
> strings or numbers for communicating with other systems.
> 2) Union Types are not comparable, and so cannot be used as keys in Sets 
> or Dicts.
>

Worth noting that (1) could also be fixed by having a deriving-esque way to 
generate encoders and decoders automatically, so long as it worked for 
union types as well as records. (Granted, the serialized format is less 
obvious with union types compared to records.)

Also worth noting that (2) is already slated to be fixed directly. It's a 
lower priority than other things in the hopper right now, but it'd probably 
still be higher priority than adding an enum feature. 

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

[Richard Feldman]

Mark - this seems like a great addition to the error message catalog 
! I've heard of people 
encountering this too.

Seems like it should be easy enough to detect, and the compiler could 
either provide a concise explanation of what's going on or link to a longer 
explanation.

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

[Mark Hamburg]

Something like this would probably address a "puzzle" I just resolved
yesterday for one of the engineers on my team. He was testing character
codes and did what one would be inclined to do in most programming
languages and defined names for referencing the values — e.g., leftArrowKey
: Int. He then tried to case on them and was puzzled at why the following
code complained about a redundant pattern:

case keyCode of
leftArrowKey -> ...
rightArrowKey -> ...
_ -> ...


Of course, what's happening here is that the mentions of leftArrowKey and
rightArrowKey in the case statement are each creating new pattern variables
that have nothing to do with the definitions elsewhere of those names. So,
Elm's error message is correct but in this case not helpful. More to the
point, however, the fixes were to either just use the constant values
directly or to replace the case expression with a sequence of if
expressions. Neither of those are particularly attractive. The conclusion
of our exchange was that it would be nice to have some form of named
constants that could be used in case expressions, but adding them would run
counter to Elm's minimalist inclinations.

Mark

On Wed, Aug 2, 2017 at 7:00 AM, Robin Heggelund Hansen  wrote:

> I think most people find that Union Types are a wonderfull thing. I would
> argue that much of the beauty of Union Types comes from using them in a
> case-of statement, having the compiler complain when there is a case one
> haven't covered.
>
> Strings and numbers are not so wonderfull, because they span essentially
> unlimited values, so case-of statements become less valuable.
>
> However, strings and numbers still need to be used in production apps for
> several reasons:
> 1) Union Types is not supported in Json, so one needs to convert to/from
> strings or numbers for communicating with other systems.
> 2) Union Types are not comparable, and so cannot be used as keys in Sets
> or Dicts.
>
> So a server might send me some json where the current user language is
> represented by an Int (0  and 1, norwegian and english) and the current
> game being played is a string ("chess", "checkers", "reversi"). It would be
> great to have some compiler help for these values (say, you forgot the case
> statement for "reversi"), AND it would be great to avoid writing
> encoders/decoders for the union types and converting back and forth several
> places.
>
> Enums would help with this.
>
> The way I imagine this to work is that an enum essentially represents a
> restricted set of String or Number. Once the compiler sees that you're
> working with an enum, it could help you out in case statements. And since
> an enum is just a string, or just a number, they can be used in the same
> places where one would normally use them, like as a value in a select.
>
> One would need a way to check that a string/number matches the values of
> an enum though. Something like `Enum.matches : MyStringEnum -> Maybe (Enum
> MyStringEnum)`.
>
> The one thing I can think of which makes this a bad addition to Elm, is
> that it might be a bit confusing for beginners when to use enum and when to
> use unions... maybe.
>
> Anyway, what do people think of this?
>
> --
> 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-tools/parser: how to access intermediate parsed objects downstream in parsing pipeline?

[Yosuke Torii]

>
> how do I know what row/col the mistake came from in the input String?


Have you looked at Parser.LowLevel

module?
I haven't tried it yet but it should help tracking the error position.


2017-08-03 2:59 GMT+09:00 Dave Doty :

> Thanks! I assumed andThen would be involved somehow but didn't quite see
> how to use it.
>
> That said, I don't think validation is necessary during the parsing
>> process. You can check it after everything is parsed. That is much simpler.
>
>
> If I check everything after it is parsed, how do I know what row/col the
> mistake came from in the input String? If the parsing succeeds, then the
> result is simply type OK DFA, but if I find a mistake then I want to be
> able to report which specific part of the input String caused that problem.
>
> --
> 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/gxy9D6bncIQ/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: elm-tools/parser: how to access intermediate parsed objects downstream in parsing pipeline?

[Dave Doty]

Thanks! I assumed andThen would be involved somehow but didn't quite see 
how to use it.

That said, I don't think validation is necessary during the parsing 
> process. You can check it after everything is parsed. That is much simpler.


If I check everything after it is parsed, how do I know what row/col the 
mistake came from in the input String? If the parsing succeeds, then the 
result is simply type OK DFA, but if I find a mistake then I want to be 
able to report which specific part of the input String caused that problem.

-- 
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-tools/parser: how to access intermediate parsed objects downstream in parsing pipeline?

[Yosuke Torii]

You cannot do like that in the middle of pipeline, but instead you can use `
andThen 
` 
to 
make a new parser based on the previous value you parsed.

For example, you can pass `states` value to parse `acceptStates` like this. 
(Simplified a lot, not tested)

dfaParser : Parser.Parser DFA
dfaParser =
  statesParser
|> andThen (\states ->
  succeed (DFA states)
|= alphabetParser
|= acceptStateParser states
|= ...
)

You can also make a recursive parser and pass the intermediate state to the 
later parser.

deltaListParser : Context -> Parser.Parser (List Delta)
deltaListParser context =
  oneOf
[ deltaParser
|> andThen (\delta ->
   if checkDuplication delta context then
 deltaListParser (updateContext delta context)
   |> map (\rest -> delta :: rest)
   else
 fail "found duplicated values"
, succeed []
]

deltaParser : Parser.Parser Delta

That said, I don't think validation is necessary during the parsing 
process. You can check it after everything is parsed. That is much simpler.


2017年8月2日水曜日 12時17分57秒 UTC+9 Dave Doty:
>
> The elm-tools/parser documentation recommends using parsing pipelines such 
> as 
>
> type alias Point = { x : Float, y : Float}
> point : Parser Pointpoint =
>   succeed Point
> |. symbol "("
> |. spaces
> |= float
> |. spaces
> |. symbol ","
> |. spaces
> |= float
> |. spaces
> |. symbol ")"
> spaces : Parser ()spaces =
>   ignore zeroOrMore (\c -> c == ' ')
>
>
> I am parsing text in this way, but it is much longer than just two floats. 
> The high-level parser parses text with five major parts in order 
> (describing portions of a finite automaton) and it looks like this (and 
> uses five "subroutine" parsers that I've not shown):
>
> type alias State = String
> type alias DFATransition = State -> Char -> Result String State
> type alias DFA =
> { states : List State
> , inputAlphabet : List Char
> , startState : State
> , acceptStates : List State
> , delta : DFATransition
> }
>
> dfaParser : Parser.Parser DFA
> dfaParser =
> Parser.succeed DFA
> |. spaces
> |. Parser.keyword "states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "input_alphabet:"
> |. spaces
> |= alphabetParser
> |. spaces
> |. Parser.keyword "start_state:"
> |. spaces
> |= startStateParser
> |. spaces
> |. Parser.keyword "accept_states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "delta:"
> |. spaces
> |= deltaParser
> |. spaces
>
> to parse text such as, for instance, 
>
> """
> states:  {q,q0,q00,q000}
> input_alphabet:  {0,1}
> start_state: q
> accept_states:   {q,q0,q00}
> delta:
> q,1-> q
> q0,1   -> q
> q00,1  -> q
> q000,1 -> q
> q,0-> q0
> q0,0   -> q00
> q00,0  -> q000
> q000,0 -> q000
> """
>
> Here's what I want to do: insert code in the middle of the pipeline that 
> can reference the data that has been parsed so far.
>
> For example, after this portion of the pipeline has succeeded: 
>
> dfaParser =
> Parser.succeed DFA
> |. spaces
> |. Parser.keyword "states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "input_alphabet:"
> |. spaces
> |= alphabetParser
> ...
>
> then the data for states and alphabet have been successfully parsed into 
> two Lists. I would like to access those lists by name, later down the 
> pipeline. 
>
> One reason is that I would like to pass those lists as input to subsequent 
> parsers (startStateParser, acceptStatesParser, and deltaParser), to help 
> them do error-checking. 
>
> For example, the next thing parsed is a String parsed by startStateParser, 
> and I want to ensure that the parsed String is an element of the List 
> parsed by statesParser. But at the time I put the line |= startStateParser 
> in the pipeline, the parsed result of statesParser doesn't have a name 
> that I can refer to.
>
> Another reason is that I want to do error-checking in the middle of a 
> pipeline. For example, my implementation of deltaParser reads the lines 
> such as "q,0 -> q0" and "q0,1 -> q" one at a time, and I would like to 
> access data parsed by previous lines when looking for errors on the current 
> line. (For example, it is an error to have duplicates on the left side of 
> -> such as the line "q,1 -> q" followed later by "q,1 -> q0", but to 
> indicate this error and reference the correct line number, I need access to 
> the lines parsed so far as I am processing the line with the error.)
>
> I get the feeling that perhaps I'm structuring this incorrectly, so I 
> welcome advice on a better way to structure the 

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

[Robin Heggelund Hansen]

I think most people find that Union Types are a wonderfull thing. I would 
argue that much of the beauty of Union Types comes from using them in a 
case-of statement, having the compiler complain when there is a case one 
haven't covered.

Strings and numbers are not so wonderfull, because they span essentially 
unlimited values, so case-of statements become less valuable.

However, strings and numbers still need to be used in production apps for 
several reasons:
1) Union Types is not supported in Json, so one needs to convert to/from 
strings or numbers for communicating with other systems.
2) Union Types are not comparable, and so cannot be used as keys in Sets or 
Dicts.

So a server might send me some json where the current user language is 
represented by an Int (0  and 1, norwegian and english) and the current 
game being played is a string ("chess", "checkers", "reversi"). It would be 
great to have some compiler help for these values (say, you forgot the case 
statement for "reversi"), AND it would be great to avoid writing 
encoders/decoders for the union types and converting back and forth several 
places.

Enums would help with this.

The way I imagine this to work is that an enum essentially represents a 
restricted set of String or Number. Once the compiler sees that you're 
working with an enum, it could help you out in case statements. And since 
an enum is just a string, or just a number, they can be used in the same 
places where one would normally use them, like as a value in a select.

One would need a way to check that a string/number matches the values of an 
enum though. Something like `Enum.matches : MyStringEnum -> Maybe (Enum 
MyStringEnum)`.

The one thing I can think of which makes this a bad addition to Elm, is 
that it might be a bit confusing for beginners when to use enum and when to 
use unions... maybe.

Anyway, what do people think of this?

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