[erlang-questions] [proposal] Declarative syntax for metadata (long!)
Mon Mar 22 09:00:24 CET 2010
On Sat, Mar 20, 2010 at 23:16, Dominic Williams
>>> But for everyday programming, I'm afraid introducing reification would actually make Erlang less simple, less easy to reason about, less reliable... and these properties of Erlang are more important to me, given that I want to ship working software quickly, than being able to do cool things with reification.
>> Well, for the first thing, this kind of functionality shouldn't affect
>> anything else unless it is used, just as little as I would not be
>> affected at all if asn1 or megaco would be the buggiest applications
>> on the planet.
> But asn1 and megaco are just erlang applications and modules. Using them or not does not affect the appearance and understandability of one's code. What you are suggesting is a change in the language. People will use it, so the possible disadvantages have to weighed against the possible benefits.
I'm not sure exactly what we are talking about in the piece above: my
suggestion to use domain specific languages instead of strings for
some meta-data, or Joe's addition regarding reification? They are
related, but the latter is not really a language change but a library
erl_scan, erl_parse, erl_syntax have to keep track of the exact
erl_pp shall use that info.
Some new constructs will be handled, but that doesn't affect code that
doesn't mind about them.
>>> I can see one area which would become much easier to work on: development tools.
>> Yes, that is one. And my (partial) opinion is that they are quite
> Agreed, tool support is important. But if it's the only area that needs reification?
Well, it's not. Any code manipulation tool or code generator would
benefit from that. Parse transforms would be easier to write and read.
I agree these aren't the most common applications, but they might
become more common if they will be easier to write.
>>> I've always been a fan of Joe's principle that for every thing one adds to Erlang, one should remove something else - so since Joe is supporting adding introspection, I'm interested to hear what he would be prepared to remove in exchange?
>> I'm not Joe, but in my previous message to the list I mentioned
>> something that could be removed :)
> Sorry, I've read your previous message 3 times but cannot see it.
Oh, it was in the parallel thread where I revealed what I thought was
a feature but it really was a bug (optional parentheses around
More information about the erlang-questions