Mailing List Archive: Perl: porters

new given/when syntax proposal

Index | Next | Previous | View Threaded

uri at stemsystems

Jul 14, 2012, 6:27 PM

Post #1 of 9 (108 views)
Permalink

new given/when syntax proposal

ok, here is a brainstorm (or fart). it is a very rough idea for a better
given/when syntax that uses existing perl ops to show the kind of match
you want. we still use the given/when to set the topic but we use
standard perl ops to show the kind of match. something like this:

given( $foo ) {

when =~ /regex/ { blah } ;
when eq 'string' { blah } ;
when == $num {blah} ;
when in $low .. $high { blah } ; # number (or string) in a range
when any @array {blah} ; # in the array - still needs to decide
# on == vs eq.
when eq @array # this is any for strings
when == @array # this is any for numbers
when exists %hash {blah} ;

when sort of aliases the topic directly as well as a keyword. it expects
an op afterward and the op controls the type of the comparison and the
type wanted of the value.

this allows for easy expansion, easy control, easy understanding and
parsing looks pretty easy as well.

flames and plaudits are welcome.

thanx,

uri

jvromans at squirrel

Jul 15, 2012, 2:01 AM

Post #2 of 9 (104 views)
Permalink

Re: new given/when syntax proposal [In reply to]

Uri Guttman <uri [at] stemsystems> writes:

> it is a very rough idea for a better given/when syntax that uses
> existing perl ops to show the kind of match you want. we still use the
> given/when to set the topic but we use standard perl ops to show the
> kind of match. something like this:

It looks to me as "I will not write chained if/then/else at any cost".

> when eq @array # this is any for strings
> when == @array # this is any for numbers
> when exists %hash {blah} ;

These are particulary misleading. While the others can be explained as

"when == $num" means "when ( $_ == $num )"

you cannot say "when ( $_ == @array )", at least not with the meaning
that is intended.

I'm afraid that given/when is just not viable (anymore) except for the
trivial cases.

-- Johan

klaus03 at gmail

Jul 15, 2012, 5:28 AM

Post #3 of 9 (104 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On 15 juil, 03:27, u...@stemsystems.com (Uri Guttman) wrote:
> ok, here is a brainstorm (or fart). it is a very rough idea for a better
> given/when syntax that uses existing perl ops to show the kind of match
> you want. we still use the given/when to set the topic but we use
> standard perl ops to show the kind of match. something like this:
>
> given( $foo ) {
>
> when =~ /regex/ { blah } ;
> when eq 'string' { blah } ;
> when == $num {blah} ;

Thanks for your suggestion.

I basically agree with your suggestion (with some minor changes, see
below)

given( $foo ) {
when true ($_ eq 'abc') { blah } ;
# evaluates condition as is
when true (/regex/) { blah } ;
# translates naturally into $_ =~/regex/
when eq ('str1', 'str2') { blah } ;
# translates into $_ in ('str1', 'str2'), which
# translates into $_ eq 'str1' or $_ eq 'str2'
when eq ('str1') { blah } ;
# translates into $_ in ('str1'), which
# translates into $_ eq 'str1'
when == (4, 5) { blah } ;
# translates into $_ in_== (4, 5), which
# translates into $_ == 4 or $_ == 5
when == (4) { blah } ;
# translates into $_ in_== (4), which
# translates into $_ == 4

> when in $low .. $high { blah } ; # number (or string) in a range

We need to be careful about whether we want number or strings, so I
suggest:

when range_eq ('abc'..'def') { blah }
# translates into $_ ge 'abc' and $_ le 'def'

when range_== (4..6) { blah }
# translates into $_ >= 4 and $_ <= 6

We also must not confuse

when == (4..6) { blah }
# translates into $_ == 4 or $_ == 5 or $_ == 6

> when any @array {blah} ; # in the array - still needs to decide
> # on == vs eq.

We need to be careful about whether we want number or strings, so we
use

when eq (@array) { blah } ;
# translates into $_ in @array, which
# translates into $_ eq $array[0] or $_ eq $array[1] or ...

when == (@array) { blah } ;
# translates into $_ in_== @array, which
# translates into $_ == $array[0] or $_ == $array[1] or ...

> when eq @array # this is any for strings
> when == @array # this is any for numbers

...exactly

> when exists %hash {blah} ;

I assume this would translate into

exists($hash{$_})

> when sort of aliases the topic directly as well as a keyword. it expects
> an op afterward and the op controls the type of the comparison and the
> type wanted of the value.
>
> this allows for easy expansion, easy control, easy understanding and
> parsing looks pretty easy as well.
>
> flames and plaudits are welcome.

I applaude your initiative.

-- Klaus

nick at ccl4

Jul 16, 2012, 3:34 AM

Post #4 of 9 (103 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On Sun, Jul 15, 2012 at 11:01:46AM +0200, Johan Vromans wrote:
> Uri Guttman <uri [at] stemsystems> writes:
>
> > it is a very rough idea for a better given/when syntax that uses
> > existing perl ops to show the kind of match you want. we still use the
> > given/when to set the topic but we use standard perl ops to show the
> > kind of match. something like this:
>
> It looks to me as "I will not write chained if/then/else at any cost".

I have to say that I agree.

Perfection is achieved not when there is nothing more to add, but rather
when there is nothing more to take away.

Antoine de Saint-Exupéry

I don't think that the complex proposals are producing anything that
justifies its paycheque within the language. A lot of the talk here seems
to assume as an axiom that we need a given/when type construction, and then
proceed to design from there. That axiom is not valid.

> > when eq @array # this is any for strings
> > when == @array # this is any for numbers
> > when exists %hash {blah} ;
>
> These are particulary misleading. While the others can be explained as
>
> "when == $num" means "when ( $_ == $num )"
>
> you cannot say "when ( $_ == @array )", at least not with the meaning
> that is intended.
>
> I'm afraid that given/when is just not viable (anymore) except for the
> trivial cases.

I'm not sure what you mean by trivial cases. I'm still thinking that it can
make sense for scalar vs scalar (specifically undef, number, string, regex),
but it *does* only make sense (to me) as using one comparison mechanism,
which would seem to be a "smart"match, for some value of smart.

But for anything that involves memorising a rule table, it's not worth it.
And if some of those rules are O(1), and some are O(n), that's another
dimension of bad.

(Checking a hash key is O(1), whereas scanning an array for an element match
is O(n))

Nicholas Clark

uri at stemsystems

Jul 16, 2012, 4:45 AM

Post #5 of 9 (102 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On 07/16/2012 06:34 AM, Nicholas Clark wrote:
> On Sun, Jul 15, 2012 at 11:01:46AM +0200, Johan Vromans wrote:
>> Uri Guttman<uri [at] stemsystems> writes:
>>
>>> it is a very rough idea for a better given/when syntax that uses
>>> existing perl ops to show the kind of match you want. we still use the
>>> given/when to set the topic but we use standard perl ops to show the
>>> kind of match. something like this:
>>
>> It looks to me as "I will not write chained if/then/else at any cost".
>
> I have to say that I agree.

that isn't my direct intent. actually i like to eschew else and even
gave a talk on it years ago. in a 10k line system i had maybe 13 else's
and only 3 elsif's. and no one would call the code contorted or anything
like that. it is just clear thinking of the logic flow and using
statement modifiers, early exits, etc. chained if/else is ugly to my
eyes. :)

>
> Perfection is achieved not when there is nothing more to add, but rather
> when there is nothing more to take away.
>
> Antoine de Saint-Exupéry
>
>
> I don't think that the complex proposals are producing anything that
> justifies its paycheque within the language. A lot of the talk here seems
> to assume as an axiom that we need a given/when type construction, and then
> proceed to design from there. That axiom is not valid.
>
>>> when eq @array # this is any for strings
>>> when == @array # this is any for numbers
>>> when exists %hash {blah} ;
>>
>> These are particulary misleading. While the others can be explained as
>>
>> "when == $num" means "when ( $_ == $num )"
>>
>> you cannot say "when ( $_ == @array )", at least not with the meaning
>> that is intended.
>>
>> I'm afraid that given/when is just not viable (anymore) except for the
>> trivial cases.
>
> I'm not sure what you mean by trivial cases. I'm still thinking that it can
> make sense for scalar vs scalar (specifically undef, number, string, regex),
> but it *does* only make sense (to me) as using one comparison mechanism,
> which would seem to be a "smart"match, for some value of smart.
>
> But for anything that involves memorising a rule table, it's not worth it.
> And if some of those rules are O(1), and some are O(n), that's another
> dimension of bad.
>
> (Checking a hash key is O(1), whereas scanning an array for an element match
> is O(n))

what if perl super optimized that and converts the array to a hidden
hash and used that to make it O(1)? :)

also remember all of Quantum::Superpositions is done in O(1)!!! (at
least that is damian's claim).

uri

uri

fawaka at gmail

Jul 16, 2012, 4:49 AM

Post #6 of 9 (104 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On Sun, Jul 15, 2012 at 4:27 AM, Uri Guttman <uri [at] stemsystems> wrote:
> ok, here is a brainstorm (or fart). it is a very rough idea for a better
> given/when syntax that uses existing perl ops to show the kind of match you
> want. we still use the given/when to set the topic but we use standard perl
> ops to show the kind of match. something like this:
>
> given( $foo ) {
>
> when =~ /regex/ { blah } ;
> when eq 'string' { blah } ;
> when == $num {blah} ;
> when in $low .. $high { blah } ; # number (or string) in a range
> when any @array {blah} ; # in the array - still needs to decide
> # on == vs eq.
> when eq @array # this is any for strings
> when == @array # this is any for numbers
> when exists %hash {blah} ;
>
> when sort of aliases the topic directly as well as a keyword. it expects an
> op afterward and the op controls the type of the comparison and the type
> wanted of the value.
>
> this allows for easy expansion, easy control, easy understanding and parsing
> looks pretty easy as well.
>
> flames and plaudits are welcome.

I'm not seeing the point of this. The current semantics have many
flaws, but does one thing right: it's extensible on CPAN. You can
already do all of this and more, and IMHO with less ambiguity than in
this proposal.

Leon

jvromans at squirrel

Jul 16, 2012, 5:19 AM

Post #7 of 9 (101 views)
Permalink

Re: new given/when syntax proposal [In reply to]

Nicholas Clark <nick [at] ccl4> writes:

> On Sun, Jul 15, 2012 at 11:01:46AM +0200, Johan Vromans wrote:
>> I'm afraid that given/when is just not viable (anymore) except for the
>> trivial cases.
>
> I'm not sure what you mean by trivial cases. [...]
> But for anything that involves memorising a rule table, it's not worth it.

I think defined exactly what I meant with "trivial cases".

-- Johan

klaus03 at gmail

Jul 16, 2012, 12:31 PM

Post #8 of 9 (97 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On 16 juil, 13:49, faw...@gmail.com (Leon Timmermans) wrote:
> On Sun, Jul 15, 2012 at 4:27 AM, Uri Guttman <u...@stemsystems.com> wrote:
> > ok, here is a brainstorm (or fart). it is a very rough idea for a better
> > given/when syntax
> >
> > flames and plaudits are welcome.
>
> I'm not seeing the point of this. The current semantics have many
> flaws, but does one thing right: it's extensible on CPAN. You can
> already do all of this and more, and IMHO with less ambiguity than in
> this proposal.

I very much agree with that, actions speak louder than words.

I would very much like to write a CPAN module with what I believe
would be the right extension for given/when, so my question is:

I am just an average Perl programmer with a little knowledge of C, but
no knowledge of XS, is there any documentation (perldoc, blogs,
documents on the internet, etc...) that help me to write a given/when
extension on CPAN ? (I prefer a pure perl aproach, but I am willing to
learn XS if needed).

nick at ccl4

Jul 26, 2012, 8:02 AM

Post #9 of 9 (72 views)
Permalink

Re: new given/when syntax proposal [In reply to]

On Mon, Jul 16, 2012 at 12:31:01PM -0700, Klaus wrote:
> On 16 juil, 13:49, faw...@gmail.com (Leon Timmermans) wrote:
> > On Sun, Jul 15, 2012 at 4:27 AM, Uri Guttman <u...@stemsystems.com> wrote:
> > > ok, here is a brainstorm (or fart). it is a very rough idea for a better
> > > given/when syntax
> > >
> > > flames and plaudits are welcome.
> >
> > I'm not seeing the point of this. The current semantics have many
> > flaws, but does one thing right: it's extensible on CPAN. You can
> > already do all of this and more, and IMHO with less ambiguity than in
> > this proposal.
>
> I very much agree with that, actions speak louder than words.
>
> I would very much like to write a CPAN module with what I believe
> would be the right extension for given/when, so my question is:
>
> I am just an average Perl programmer with a little knowledge of C, but
> no knowledge of XS, is there any documentation (perldoc, blogs,
> documents on the internet, etc...) that help me to write a given/when
> extension on CPAN ? (I prefer a pure perl aproach, but I am willing to
> learn XS if needed).

So, no-one answered.

I'm not aware of any documentation that specifically describes what one
would need to do to write a given/when extension on CPAN.

I don't even know which modules currently on CPAN do things related to
smartmatch, but I'd guess the way to go from here is to find them, look
at what they do (and can't do), and where it's not obvious what's going on,
ask the relevant authors specific questions, or (if it's messy XS code) ask
here.

Nicholas Clark

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads