Why do you feel it is contradictory? I think having method names end with "?" whenever they return a boolean value is quite intuitive. They seem to stand out more than having such method names start with "is" or "has". YMMV.
Looking back at some Dylan code again now, I still find its richer, Lisp-derived, hyphenated naming approach more readable-and-expressive than either camelCase or underscore_separated identifiers.
When Dylan switched from Lisp syntax this was something that was fretted over an awful lot, for obvious reasons, but we went with it and it worked fine.
I'd love to see some other algebraic (non Lisp) syntax language get more creative in this direction again one day.
More precisely, "functions that modify their arguments". For example,
append(list,value)
returns a new list;
append!(list,value)
modifies at least one of its arguments, typically, its first argument, but it could be another or multiple ones.
By the way, all of these are conventions. The language doesn't require you to use the punctuation (http://opendylan.org/documentation/intro-dylan/expressions-v...). The conventions grow on you soon, though (I never really wrote anything in lisp or dylan, but still would like to see more flexibility in allowed characters in names)
> A Common Lisp-style condition system is a pretty key thing for me.
What does that mean? I absolutely agree with you about using ! and ? (and other special characters too!) in symbol names. That's something I'd like to see more languages adopt.
Perl 6 has baked in some stuff @Larry may have stolen from CL that is intended to enable unified succinct expression of desired sync or async handling in response to errors and callstack events (including exceptions).
That's obviously a contrived example but I think it shows the basics.
Some related excerpts from spec doc S04 (blocks and statements):
Warnings are produced in Perl 6 by throwing a resumable control exception to the outermost scope, which by default prints the warning and resumes the exception by extracting a resume continuation from the exception, which must be supplied by the warn() function (or equivalent).
...
Since warnings are processed using the standard control exception mechanism, they may be intercepted and either suppressed or fatalized anywhere within the dynamic scope by supplying a suitable CONTROL block.
...
As with calls to return, the warning control exception is an abstraction that the compiler is free to optimize away (along with the associated continuation) when the compiler or runtime can determine that the semantics would be preserved by merely printing out the error and going on.
...
One additional level of control is the notion of lazy warnings. ... Numeric and string conversions use these lazy warnings to allow (but not require) failsoft semantics.
It is highly readable. And you can use '!' and '?' in names!
An optimized implementation of multimethods is always nice.
The ability to apply optional static typing is great for putting stuff into production and feeling good about it.
Having multiple return values, keyword arguments and rest arguments is nice (and yes, Python can do much of that).