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 [email protected].
For more options, visit https://groups.google.com/d/optout.
