If you want something that can hold arbitrary string keys like a JavaScript object, you can use a Dict.
Making keywords context-sensitive would be a language designer's nightmare. I don't think most languages allow this. Which contexts would the keywords be reserved, and which would they not be? Even if you can specify the special rules consistently, your compiler will become more complicated, more prone to bugs. And if you get everything working, the only benefit you've gained is fixing this one slightly inconvenient use case. On Thu, Dec 15, 2016 at 2:15 PM, Paul Dijou <[email protected]> wrote: > Both solutions are valid (I'm actually using both depending on the > situation) but my main question is why is there such a limitation? Reserved > keywords could (should?) depend on the context. You cannot define a real > port inside a record, you just want a string to name a property. > > For example, in JavaScript, you can create an object with any property you > want, including reserved keywords, because, at the end of the day, it's > just string names. Some old browsers required to wrap the key inside quotes > so I would be fine with writing { "port" = 80 } in Elm if that would solve > the problem. > > Le jeudi 15 décembre 2016 16:20:25 UTC+1, Paul Dijou a écrit : >> >> Hi, >> >> I understand that "port" is a reserved keyword when writing Elm code but >> is there a reason to fail compilation when used as the name of a record >> field? It's a bummer when sending records through a port (a real one) and >> the JavaScript is expecting the property "port" (in the record). >> >> Thanks >> > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
