Re: Extended identifiers in named attributes

[Marcel Timmerman]

Hi Ralph,
Thanks for your answer.

The name 'attributes' was wrong, I meant 'arguments'. Sorry for that. I 
was working on XML files and mixed up some terms.

I don't think you're supposed to be able to have extended identifiers
as named parameter/argument identifiers. They are meant for a few
specific scenarios where there's special value in having adverbs aka
pairs embedded in identifiers:

* Alternations in grammars. Typically of form `foo:sym`.

* Appending :api<>, :auth<>, :ver<> to package identifiers.

They *may* work in a couple of other scenarios but in general,
don't do that.

By the way, "attributes" has a specific meaning in Raku, namely the
fields of object instances.

Regards,
Marcel


--
love, raiph


On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman > wrote:


Hi everyone,

I was experimenting with extended identifiers and found that it is
not possible to use it in named attributes. E.g.

> sub a (:$x:y) { say $x:y; }
===SORRY!=== Error while compiling:
Unsupported use of y///.  In Raku please use: tr///.
--> sub a (:$x:y⏏) { say $x:y; }


> sub a (:$abc:def) { say $abc:def; }
===SORRY!=== Error while compiling:
Invalid typename 'def' in parameter declaration.
--> sub a (:$abc:def⏏) { say $abc:def; }

Is there a trick of some sort to get this done? At the moment I
can only use a slurpy hash and check for its keys. This is good
enough for me but out of curiosity I ask. If not possible, an
extra note in the documentation on named arguments would be necessary.

regards,
Marcel

Re: Extended identifiers in named attributes

[yary]

I wonder what was intended with these extended identifiers?
https://github.com/Raku/problem-solving/issues/224* - Extended
identifiers-why and where, exactly?*
-y


On Fri, Aug 28, 2020 at 8:26 AM Ralph Mellor 
wrote:

> I don't think you're supposed to be able to have extended identifiers
> as named parameter/argument identifiers. They are meant for a few
> specific scenarios where there's special value in having adverbs aka
> pairs embedded in identifiers:
>
> * Alternations in grammars. Typically of form `foo:sym`.
>
> * Appending :api<>, :auth<>, :ver<> to package identifiers.
>
> They *may* work in a couple of other scenarios but in general,
> don't do that.
>
> By the way, "attributes" has a specific meaning in Raku, namely the
> fields of object instances.
>
> --
> love, raiph
>
>
> On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman  wrote:
>
>> Hi everyone,
>>
>> I was experimenting with extended identifiers and found that it is not
>> possible to use it in named attributes. E.g.
>>
>> > sub a (:$x:y) { say $x:y; }
>> ===SORRY!=== Error while compiling:
>> Unsupported use of y///.  In Raku please use: tr///.
>> --> sub a (:$x:y⏏) { say $x:y; }
>>
>>
>> > sub a (:$abc:def) { say $abc:def; }
>> ===SORRY!=== Error while compiling:
>> Invalid typename 'def' in parameter declaration.
>> --> sub a (:$abc:def⏏) { say $abc:def; }
>>
>>
>> Is there a trick of some sort to get this done? At the moment I can only
>> use a slurpy hash and check for its keys. This is good enough for me but
>> out of curiosity I ask. If not possible, an extra note in the documentation
>> on named arguments would be necessary.
>>
>> regards,
>> Marcel
>>
>>
>>

Re: Extended identifiers in named attributes

[Ralph Mellor]

I don't think you're supposed to be able to have extended identifiers
as named parameter/argument identifiers. They are meant for a few
specific scenarios where there's special value in having adverbs aka
pairs embedded in identifiers:

* Alternations in grammars. Typically of form `foo:sym`.

* Appending :api<>, :auth<>, :ver<> to package identifiers.

They *may* work in a couple of other scenarios but in general,
don't do that.

By the way, "attributes" has a specific meaning in Raku, namely the
fields of object instances.

--
love, raiph


On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman  wrote:

> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }
>
>
> Is there a trick of some sort to get this done? At the moment I can only
> use a slurpy hash and check for its keys. This is good enough for me but
> out of curiosity I ask. If not possible, an extra note in the documentation
> on named arguments would be necessary.
>
> regards,
> Marcel
>
>
>

Re: Extended identifiers in named attributes

[Brad Gilbert]

The problem is that often adverbs are chained without a comma.

my %h = (a => 1);

%h{'a'}:exists:delete # True
say %h.keys; # ()

---

my %h = (a => 1);

postcircumfix:< { } >( %h{'a'}, :exists:delete ) # True
say %h.keys; # ()

On Wed, Aug 26, 2020 at 7:31 AM Marcel Timmerman  wrote:

> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }
>
>
> Is there a trick of some sort to get this done? At the moment I can only
> use a slurpy hash and check for its keys. This is good enough for me but
> out of curiosity I ask. If not possible, an extra note in the documentation
> on named arguments would be necessary.
>
> regards,
> Marcel
>
>
>

Re: Extended identifiers in named attributes

[Marcel Timmerman]

On 2020-08-26 17:48, Tom Browder wrote:
On Wed, Aug 26, 2020 at 07:31 Marcel Timmerman > wrote:


I was experimenting with extended identifiers and found that it is

not possible to use it in named attributes. E.g.

> sub a (:$x:y) { say $x:y; }

Are you sure that is supposed to work without some kind of () or <> 
like a module identifier? But a doc note would be helpful.


Best regards,

-Tom

Hi Tom,

One example from the doc is: WOW:That'sAwesome, so yes, I believe that 
should be possible. Also I've already used this in Xml::Actions where 
function names can be named like abc:def:start(). A small REPL test 
shows also that a simple assignment works on these type of variables;



my $abc:def = 10;

10

say $abc:def;

10

Regards,
Marcel

Re: Extended identifiers in named attributes

[Tom Browder]

On Wed, Aug 26, 2020 at 07:31 Marcel Timmerman  wrote:

I was experimenting with extended identifiers and found that it is
>
> not possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
>
> Are you sure that is supposed to work without some kind of () or <> like a
module identifier? But a doc note would be helpful.

Best regards,

-Tom

Re: Extended identifiers in named attributes

[Gianni Ceccarelli]

On Wed, 26 Aug 2020 14:31:06 +0200
Marcel Timmerman  wrote:

> I was experimenting with extended identifiers and found that it is
> not possible to use it in named attributes. E.g.
> 
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
> 
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }

Also::

  > sub a( :foo($a:x) ) { say $a:x; }
  ===SORRY!=== Error while compiling:
  Unable to parse named parameter; couldn't find right parenthesis
  --> sub a( :foo($a⏏:x) ) { say $a:x; }

feels like a parse problem to me. I'd say submit a bug report.

-- 
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

Re: Extended identifiers in named attributes

[William Michels via perl6-users]

Hi Marcel, It almost looks to me that a pair of characters--possibly
the two colons--is being interpreted as an alternative delimiter for
the tr/// operator. I'd suggest this is a bug, so you should consider
opening an issue on Github. But I have little experience with "named
attributes", so does anyone else care to chime in?

Best, Bill.


On Wed, Aug 26, 2020 at 5:31 AM Marcel Timmerman  wrote:
>
> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not 
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def) { say $abc:def; }
>
> Is there a trick of some sort to get this done? At the moment I can only use 
> a slurpy hash and check for its keys. This is good enough for me but out of 
> curiosity I ask. If not possible, an extra note in the documentation on named 
> arguments would be necessary.
>
> regards,
> Marcel
>
>

Extended identifiers in named attributes

[Marcel Timmerman]

Hi everyone,

I was experimenting with extended identifiers and found that it is not 
possible to use it in named attributes. E.g.



sub a (:$x:y) { say $x:y; }

===SORRY!=== Error while compiling:
Unsupported use of y///.  In Raku please use: tr///.
--> sub a (:$x:y⏏) { say $x:y; }



sub a (:$abc:def) { say $abc:def; }

===SORRY!=== Error while compiling:
Invalid typename 'def' in parameter declaration.
--> sub a (:$abc:def⏏) { say $abc:def; }

Is there a trick of some sort to get this done? At the moment I can only 
use a slurpy hash and check for its keys. This is good enough for me but 
out of curiosity I ask. If not possible, an extra note in the 
documentation on named arguments would be necessary.


regards,
Marcel