> From: david nicol <[EMAIL PROTECTED]>
> Date: 15 Nov 2002 18:56:35 -0600
>
I don't know if you haven't been paying attention, or you're
summarizing what's happened. I'll assume the former. Forgive me if
I've misunderstood you.
>
> 1: string cat is an old and reliable horsehide drum. I've been
> doing C programming recently, where you can concat two literal
> strings by having no other language tokens between them. Really.
> That's the real basis for repeating the suggestion of juxtaposition
> as a string joining operator. Syntactic arguments can all be deflated
> by retreating what gets recognized as a string juxtaposition to the
> point where it is clear that other things are happenind when other
> things are meant to happen. Besides, there's always join('',...).
>
If you're saying that juxtaposition should be string cat, see Larry's
post on the subject. If you're saying that string I<literal>
juxtaposition should concatenate, that's more sane, but why if we
already have a cat? If you're saying juxtaposition is bad, good for
you.
>
> 2: deprecating bitwise ops. I've also been working with C++ recently
> where the
> bitwise ops, particularly shift-left, were completely overrun and are
> rarely missed.
> Multiple dispatch means the same syntax can mean completely different
> things. A
> more perlish solution to the situation might be, since bitwise ops are
> used rarely, to
> explicitly bring them in with a pragma.
Bitwise ops in their traditional form are depricated. They're
replaced by I-don't-know-what-godawful-symbol (I think .& and .|, but
I don't remember well). The | and & are junction constructors now
(which I<I> think is fantastic).
> {
> use bitwiseops;
> ...
> }
>
> 3: I propose "means" as a postfix macro indicator. Macros are not
> allowed to alter
> the blocking structure, theymust be block-sane (like Lisp, unlike C).
>
> Tokens on both sides are the pieces that get replaced. Tokens and other
> syntax on the
> left that does not appear on the right is the pattern that will get
> matched to invoke the
> macro. The right hand side guides the rewriting.
> No reserved begin and end markers are required because of the blocking
> sanity
> requirement. For example
>
> for( initialize ; test ; increment ) body
> means
> {initialize ; while (test) {body ; increment }}
> ;
Ummm... why? Why not just grammar-munge or define a sub?
FYI, this macro thing has been discussed before, and failed to reach a
conclusion. People wanted the power of Lisp macros, but found it
would be hard to do because Perl has so much more structural
complexity than Lisp. C-like-macros (as this is) don't give a big
advantage in a spicy language like Perl. That is, unless you can come
up with a good advantage....
Luke
