Well, it certainly seems easier to make a robust parser if keywords are not
context-dependent. Yes, perhaps you could tell that { port = "foo" } is a
record with a 'port' field, but what about port = "foo"? Is that a record
missing its opening and closing braces, or a messed-up declaration of an
Elm port? What sort of error should the compiler report?
In any case, I can't speak for Evan but I rather suspect that tweaking the
parser to allow context-sensitive keywords (even if that was agreed to be a
good idea in general) would be way, way down the list of priorities for at
least the next few years.
On Thursday, 15 December 2016 17:15:00 UTC-5, Paul Dijou 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
