# from wren ng thornton
# on Sunday 26 February 2006 09:06 pm:
>So, I sent this to usenet but my usenet source is acting up and it
> looks like it never got through. Also cc'ed [email protected],
> though I might get bounced since I'm pretty sure I'm not on the list.
> something else that might be worth
>considering is transforming the Perlish notation into "B A C" or
>"B->A(C)". This would mean you're doing things like
>`L(' ')->join(@foo)` which may seem backwards though it gives an
>operator look (i.e. "A op B") so might be worth a moment's thought.
Interesting, but likely to introduce inconsistency. This is a
left-to-right flow as opposed to the lisp/functional right-to-left.
Yeah, so eventually everything comes out on the left at the lvalue, and
now I'm sending the lvalues rightward on to some unknown doom, but the
main goal here is that when the behavior of a chained call changes that
I think this approach can more easily minimize the amount of typing
required there (e.g. you just snip the step out of the middle of the
chain.)
>One potential benefit to the variation is, many of the functions in
>question take strings (or regexes) as their first argument and so if
>you're blessing that into your L class, the original `join L(' ')
> @foo` notation (note the missing comma) will still work (presuming
> the interpreter doesn't complain about using keywords improperly).
> This could be considered good or bad.
Ouch. I'm going to vote bad. For starters, scalar references don't
click as nicely as list references. The list reference is a package of
things. The scalar reference is a package of a thing. I would love it
if Perl somehow had scalar objects, but perl5 just doesn't and I don't
think it's worth the extra dereferencing syntax to try to force them.
>This version would be literally backwards from your Rubyish version in
>many cases. The downside is that it may be less chainable, though it
>would allow chains like `L(' ')->split($foo)->reverse->join` instead
> of `L(split ' ', $foo)->reverse->join(' ')` which is worse than the
> native Perl imho.
OK, but I'm thinking that the starting point is most frequently a list
and the primary case where we start with a scalar is split, so what if
I meet you partway with an exported Split:
Split('', $foo)->reverse->map->(sub {uc($_)})->join('')
>So perhaps the take-home lesson is not that this variation is a good
>approach, but rather that it'd be good to find a way to fit
>scalar-to-array and array-to-scalar commands into the framework.
I agree that that needs work. I'll have to poke at it. I believe EO
has already implemented a lot of this, but turning perl into ruby isn't
my goal, Time.now.to_i.to_s, func(a,b) != func(list_of_a_and_b) and
what-not.
> Perhaps by having the L class for "lists" and S for "scalars" with
> the appropriate conversion methods taking one and returning the
> other. So the above could be done with `S($foo)->split('
> ')->reverse->join(' ')` which really does look prettier than the
> above two versions and is likely more intelligible than `join ' ',
> reverse split ' ', $foo`.
But shouldn't join then return an S, which I would then have to to_s?
That's the inconsistency and extra syntax that I want to avoid. I'm
only in the beginning class for language designers atm :-)
>As for the new push and unshift, I'd recommend they return an L object
>so you can keep chaining them indefinitely, rather than returning the
>new length (some method "length" could always return that if you want
I've got l_push, l_unshift, l_pop, and l_shift for that. The natively
named forms behave exactly like the native versions. My opinion there
is that you would occasionally want the side effect value and
occasionally want the chain. And of course, consistency.
>One change that I'd make (only having scanned the code, not having
> tried to use it, mind) is to dynamically figure out whether to return
> an L or an actual array.
I've thought about that, but IIRC, there are some weird cases where
wantarray can't quite figure out how to dwim so right now I'm leaning
toward the explicit flatten.
>I'd use "to_array" or "array" rather than "flatten" as those names are
>more intuitive to me, but yes, a method would look better than using
> @{}.
How about @a = $l->to_a; Might as well steal someone else's ideas.
Though I've been pondering $l->_; because the underscore is flat (/me
ducks.)
--Eric
--
hobgoblin n 1: (folklore) a small grotesque supernatural creature that
makes trouble for human beings
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
