ARM syntax and new keywords

[Joshua Bloch]

Jonathan,

Actually I quite like the "try" syntax.  Sun is in possession of a protocol,
and as soon as we think it's in shape for public consumption, we'll get it
out there and you can play with it.

    Happy Thanksgiving,

    Josh

On Thu, Nov 26, 2009 at 6:31 AM, Jonathan Lawson <jonty.lawson at gmail.com>wrote:

> A pretty long post I'm afraid, but I hope it is contributing something of
> value.
>
> I've been following the discussions about ARM and a question about the
> syntax has been niggling at me: wouldn't it be better using a new keyword?
>
> Now as I understand it there is considerable resistance to the idea of new
> keywords, and with reason, but I feel that the associated problems have a
> reasonable solution and that it is a mistake to refuse to at least consider
> using keywords. If the resulting feature is much simpler and clearer using
> a
> keyword then why introduce some new syntax?
>
> As a motivation, consider ARM if we allow new keywords.
>
> Create, say, a new keyword 'autoclose'. This would be a new modifier on
> local variable declarations with much the same semantics as the current
> proposal; in particular that when the variable goes out of scope there will
> be a suitably exception protected call to a close routine. In general the
> keyword would take a 'parameter' giving the name of the close routine,
> thus:
>
> autoclose(close) InputStreamReader in = new FileReader("filename");
>
> The declared type must have a method of the given name that can be called
> with no args. This would be desugared in much the same way as:
>
> try (InputStreamReader in = new FileReader("filename")) {
> statements_to_the_end_of_scope_of_in }
>
> in the current proposal would be.
>
> There should also be a simplified form without the (close) for the common
> cases. There are different ways that this could be defined: either using
> marker interfaces as currently envisaged, or using a name based scheme. For
> example, if the declared type has exactly one method with name "close",
> "dispose", "free", "release" or "unlock" that can be called with no args,
> use that, otherwise it's an error not to specify the name explicitly. This
> is slightly nasty in that it puts those names into the language spec, but
> then again only as defaults, and it has the advantages that it is simple to
> understand, simple to use and will do what's expected. It would create the
> restriction that it would be a breaking change to add a second method from
> the set to an existing library class, but to me that doesn't seem much of a
> burden. It wouldn't require any reworking of the library at all - no new
> marker interfaces etc. So the above example would become:
>
> autoclose InputStreamReader in = new FileReader("filename");
>
> This feature could also be used simply for user defined types, for example:
>
> autoclose(bin) UserBinnable ub = new UserBinnable();
>
> To my eyes it is much clearer than the proposed syntax (not that I find
> that
> unacceptable, but I think this is better). It's so simple to use that it
> will become second nature to use it every time, even in throwaway code. It
> even has a good chance of being correctly interpreted by someone who
> doesn't
> know the feature - surely an indication of a good syntax.
>
> It has the difference relative to the proposed syntax that the programmer
> isn't forced to explicitly show the end of scope via {}, though there is
> nothing to stop it (by putting the declaration at the start of a new
> block).
> The presence of the word 'try' can also be considered an advantage of the
> current approach (reminding you that there is some exception magic going
> on), but personally I don't find this compelling.
>
> It could be extended to the foreach case that has been recently discussed.
> If you allow its use just after the : to indicate that the created iterator
> needs closing:
>
> for (Object o: autoclose somethingIterable)...
>
> which would be expanded as detailed in the current JLS but with autoclose
> added to the iterator declaration. This would require
> somethingIterable.iterator() to return a subtype of Iterator that had a
> close, dispose etc method, otherwise it's an error. The fact that it is
> explicit and compiler checked strikes me as a big advantage over the
> previously discussed idea of just quietly doing it if the passed type
> permits it. Additionally, if the passed type is changed to no longer
> support
> closing then the code no longer compiles, rather than quietly changing its
> functionality.
>
>
>
> Anyway, enough of the ARM case. On to the subject of new keywords.
>
> Obviously, the above syntax is only worthwhile if the cost of introducing
> new keywords isn't too high. At the moment it famously is, of course. So,
> 'source' revisited, but source light.
>
> I totally agree that having the meaning of syntax change so that you can't
> tell what code is doing without looking at the file header is only to be
> tolerated in extreme cases. However, I don't think this applies with new
> keywords. If you are looking at source code in an IDE then you get syntax
> highlighting. This will tell you right away if a name is being treated as
> an
> identifier or as a keyword. If you type the name into your code then you
> will know you that you haven't written an identifier but a keyword (or vice
> versa).
>
> So, the suggested solution is that a contextual keyword called 'keywords'
> should be permitted as the first thing in a file, in which case it is
> followed by a version string which must correspond to a version of the JLS
> (or possibly java version -  TBD). The meaning of this is that the list of
> keywords should be that from the referenced version of the JLS. If a name
> which is a keyword in the latest version of the language (eg 'autoclose')
> appears in the source, but is not present in the version of the JLS given
> in
> the keywords specification, then it will be treated as an ordinary
> identifier rather than a keyword for this file. If no keywords
> specification
> appears at the start of the source file then "keywords 3.0;" is assumed.
>
> This provides many of the advantages of 'source' without most of the
> downsides. The JSL doesn't need to maintain multiple versions. If you add
> 'autoclose' say, then you specify what it does and add it to the new list
> of
> keywords. The functionality is still, in some senses, always present in the
> language, it is simply that if a source file specifies a version preceding
> the version it was added to then the name autoclose refers to an identifier
> rather than the new feature. It doesn't present language designers with the
> temptation to modify its behaviour later. The keywords version merely tells
> you if it is in or out, it doesn't give you information about how to
> interpret it.
>
> IDEs should be able to refactor this relatively easily (just checking that
> no new keywords are currently used as identifiers in the file when altering
> the 'keywords' specifier). They should be able to do the syntax
> highlighting
> pretty straightforwardly as well.
>
> It does create one problem that I can see: if you are writing code using
> the
> new keywords how do you access a member called, for example, autoclose, in
> an existing class? I suppose one answer could be to require the creation of
> a glue class to rename access to the member, but this isn't very elegant
> (but then again if new keywords are chosen carefully there shouldn't be
> very
> many of these cases). Another possibility would be to allow individual
> blocks to be reverted to earlier keyword version by tagging them with a
> local 'keywords' specifier, but this seems a bit heavy handed. Probably the
> best way would be if current proposals to create a syntax for non-standard
> identifiers are implemented. Then this could be used to force the new
> keyword to be treated as an identifier in the given context.
>
>
> Independently of whether the ideas above concerning ARM get any support, I
> feel that discussions about the language would benefit from the freedom to
> at least consider new keywords. I hope this post will encourage this by
> pointing out that the compatibility problems of introducing new keywords
> can
> be easily eliminated.
>
> Jonty
>
>