"sins" (aka, acknowledged language problems)

[William Tanksley]

On Tue, 28 Dec 1999 07:20:46 +1100, skaller wrote:
>Alex Martelli wrote:

>> But as soon as they published, and the book was
>> such an instant success, I started using their
>> design pattern names with abandon (with a biblio
>> reference in a comment, when I remembered:-).

>	I found the book interesting, and nothing
>more.

I didn't consider it enourmously interesting, although I dutifully took
note of the nomenclature it used.  It turns out that the nomenclature is
precisely what makes the book so useful.

>I gained no enlightenment from it, other than
>the mild assertion than some patterns could not
>be encoded IN the language. It turns out this
>assertion is false in general -- it is language specific.
>Functional languages have no problem encoding it.

They didn't make that assertion in general (although, let it be noted that
your statement about functional languages is also false in general; there
are functional languages which cannot implement specifc patterns, and no
functional language can implement all patterns).  They made it in specific
about C++ and Smalltalk; they also noted that had the book's target
language been C, they would have documented some other patterns, such as
"prototyping object system" and such.

>> I particularly appreciated Java's abandonment
>> of classical rules for nested lexical scopes -- the
>> idea that an identifier in an inner scope hides the
>> existing outer one silently.  Java makes it an
>> error to have such a 'hiding', and although the
>> idea was totally novel to me when I tried Java out,
>> I think it substantially reduced mistakes without any
>> real cost in expressiveness.

>	Yeah, but the scopes still nest and control
>object lifetimes accordingly, right? The fact that
>shadowing generates an error may have some
>advantages, but it also has disadvantages too:
>hiding supports 'cut and paste'.

This is why it's easier to refactor Forth than Scheme.

>> If the wrappers are standardized, readability is no
>> problem.  

>	Most people think highly bracketted expressions
>are unreadable (eg LISP :-)

>	Or, (did I (actually) mean), that, (most),
>(people are (finding (that (highly (bracketed)))))
>expressions are hard to read. :-)

That's more like what I think.  Rebol discards the brackets while keeping
the backward execution; it's a bit odd, but winds up looking not too bad,
so long as you don't get fancy.

>>And efficiency need not be, either; why
>> cannot you parse and optimize:

>>         for key,value in kv_enum(sequence):

>> just as easily as

>>         ifor key,value in sequence:

>	Well, in Python 'kv_enum' could be
>anything. It may default to a standard function,
>but the client can write:

>	kv_enum = myfunction

>This cannot be done for the 'ifor' form, since 'ifor'
>is a keyword.

Please don't use ifor!  You're inventing a new keyword to do what 'for'
does perfectly well.  What you actually want is a way to iterate over both
sequence items and locations at the same time.  Why not define a method
which is valid for all sequences; I'll call it "items" because
dictionaries already have such a method.

for index,value in x.items():
   assert x[index] = value

>> >       Quite a lot of the time, you CAN provide the y:
>> > using functional programming with map and reduce etc.

>> Yep -- and O-O wrappings work for it, too.

>	The difference is that the 'OO' wrappings, in general,
>cannot be localised. This leads to spagetti.

And spaghetti leads to hate, which leads to suffering.

Seriously, though, I don't understand your usage of the word "localized".
In my dictionary localizing a program means translating it to be
appropriate for some specific language/locality.

>> > This works well in functional programming languages,
>> > but it doesn't work nearly as well in python
>> > What I mean  is, the 'y' becomes so cluttered the reader
>> > isn't sure what is happening.

>> Why would it be less cluttered in a functional PL?

>	At least in ML languages, function calling does
>not require brackets. Of course, you still need them
>to override the default precedence. :-(

Many functional languages implement function calls via currying.
Interesting, and makes parentheses irrelevant.

>John Skaller, mailto:skaller at maxtal.com.au

-- 
-William "Billy" Tanksley, in hoc signo hack