New features

[Brian Rice]

On Apr 14, 2005, at 11:22 PM, David Hopwood wrote:

> Brian Rice wrote:
>> On Apr 14, 2005, at 7:54 PM, David Hopwood wrote:
>>> Brian Rice wrote:
>>>> On Apr 13, 2005, at 12:32 PM, Brian Rice wrote:
>>>>
>>>> On further thought, concatenateAll: and such probably deserve a 
>>>> more succinct selector. The equivalent of this is "join" in 
>>>> perl/python(/ruby? I forget), although Common Lisp / Dylan just 
>>>> call it "concatenate". [...] Ideas?
>>>
>>> Haskell calls it "concat". I don't see the motivation for ";*".
>> You don't see the motivation for the particular selector, for the 
>> idea of join, or for a separate concatenation from binary 
>> concatenation? Which is it?
>
> For the particular selector. It's fairly obvious what "concat" or
> "concatenate" does, but I'd never remember what ";*" does.

Well, both are available, and #;* allSelectorsSent will tell you (once 
loaded) that it's #concatenateAll:. Besides, #; is already the selector 
for concatenation, along with #;; for lazy concatenation, using Cords 
(a binary tree type), as mentioned in my rationale for it. Both are 
also covered in the manual. The * suffix is just similar to a Kleene 
star operator to represent arbitrary repetition of some base thing.

It's basically just a variation on Smalltalk's #, for concatenation, 
but we only use it for tuple-construction. It's a different tradition 
from the Haskell and Lisp tradition, but this also kind of goes along 
with the difference of the Smalltalk syntax approach 
(unary/binary/keywords with /super/-simple precedence based on the 
lexical reading and not the context) from the SEXP or pattern syntax 
approach.

I'm not unaware of these differences and appreciate your point, but the 
particular Slate "ecosystem" of method names admits that kind of thing 
and not the other.

Eventually, we'll work towards making this apparent obfuscation less 
insistent upon the user to read. For example, Unicode support at the 
language level and taken to the appropriate ends would allow us to use 
a mathematical notation for it. As with any notation, it'd be arbitrary 
and in some tradition, but making it distinguishable and abstracted 
means that these kinds of decisions might not have as much effect on 
the reader of the code in the long run. Is that acceptable for now? 
Bear in mind we may decide in the other direction just as quickly (in 
the long road approaching 1.0), and that I will not forget your 
reservation.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/