# [alexander.schrijver@gmail.com: Re:  RE: [SPAM] Re:  rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]

- Thread: https://externals.io/message/50052
- Original archive: https://news-web.php.net/php.internals/50052
- Started by Alexander Schrijver on 2010-11-01T12:30:58+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #50052 — Alexander Schrijver — 2010-11-01T12:30:58+00:00

URL: https://externals.io/message/50052#50052

Oops, should've sent this to the list too.

----- Forwarded message from Alexander Schrijver <alexander.schrijver@gmail.com> -----

Date: Mon, 1 Nov 2010 13:28:59 +0100
From: Alexander Schrijver <alexander.schrijver@gmail.com>
To: James Butler <james.butler@edigitalresearch.com>
Subject: Re: [PHP-DEV] RE: [SPAM]  Re: [PHP-DEV] rename `T_PAAMAYIM_NEKUDOTAYIM` to `T_DOUBLE_COLON` 
User-Agent: Mutt/1.5.21 (2010-09-15)


> 
> 
> -----Original Message-----
> From: Alexander Schrijver [mailto:alexander.schrijver@gmail.com] 
> Sent: 01 November 2010 12:19
> To: Stefan Marr
> Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net
> Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename `T_PAAMAYIM_NEKUDOTAYIM` to `T_DOUBLE_COLON` 
> 
> 
> > […]
> 
> Right, and be forced to introduce some bullshit hebrew when its done. No, thank you.
> 
> Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized).
> Please grow up...


It's the policy:
> There are two reasons this term will stay.  It is a tip of the hat to
> the amount of PHP work that came out of Israel, and it is a good                                                    
> reminder that there are a lot of other languages in the world.  People
> whose first language is not English, myself included, are forced to work
> with unfamiliar terms every day.  I wouldn't mind having a few more                                                
> non-English identifiers in PHP actually.                                                                          
>                                                                                                                  
> Well, and a third reason, I like it.            

There is some reason this policy will change after i write this new tokenizer?


----- End forwarded message

---

## #50053 — Etienne Kneuss — 2010-11-01T12:36:24+00:00

URL: https://externals.io/message/50052#50053 · In reply to: #50052

> Oops, should've sent this to the list too.
> 
> ----- Forwarded message from Alexander Schrijver <alexander.schrijver@gmail.com> -----
> 
> Date: Mon, 1 Nov 2010 13:28:59 +0100
> From: Alexander Schrijver <alexander.schrijver@gmail.com>
> To: James Butler <james.butler@edigitalresearch.com>
> Subject: Re: [PHP-DEV] RE: [SPAM]  Re: [PHP-DEV] rename `T_PAAMAYIM_NEKUDOTAYIM` to `T_DOUBLE_COLON` 
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> 
> > […]
> 
> 
> It's the policy:
> > […]
> 
> There is some reason this policy will change after i write this new tokenizer?

Yes, there is a reason:

As it was explained before, lemon would not display token names but
actual token "values". So instead of "Unexpected T_PAABLAH" it would say
"Unexpected '::' ..."

Best,

> 
> 
> ----- End forwarded message -----
> 
> -- 
> 
> 
> 

-- 
Etienne Kneuss
http://www.colder.ch

---

## #50054 — Alexander Schrijver — 2010-11-01T12:43:14+00:00

URL: https://externals.io/message/50052#50054 · In reply to: #50053

> > […]
> 
> Yes, there is a reason:
> 
> As it was explained before, lemon would not display token names but
> actual token "values". So instead of "Unexpected T_PAABLAH" it would say
> "Unexpected '::' ..."

But the lesson Rasmus was telling us about would go away. Yet, this is one of
the reasons the token is being kept. I am confused. Are you telling me this is
a lesson for the programmers to be learned? Not for the users?

---

## #50056 — Ferenc Kovacs — 2010-11-01T12:45:38+00:00

URL: https://externals.io/message/50052#50056 · In reply to: #50054

On Mon, Nov 1, 2010 at 1:43 PM, Alexander Schrijver <
alexander.schrijver@gmail.com> wrote:

> 
> > […]
>  People
> > […]
> work
> > […]
> tokenizer?
> > […]
>
> But the lesson Rasmus was telling us about would go away. Yet, this is one
> of
> the reasons the token is being kept. I am confused. Are you telling me this
> is
> a lesson for the programmers to be learned? Not for the users?
>
> --
> 
> 
>
>
I"ve just brought up in the original thread, maybe we should go back there.

Tyrael

---

## #50057 — Etienne Kneuss — 2010-11-01T12:53:52+00:00

URL: https://externals.io/message/50052#50057 · In reply to: #50054

> 
> > […]
> 
> But the lesson Rasmus was telling us about would go away. Yet, this is one of
> the reasons the token is being kept. I am confused. Are you telling me this is
> a lesson for the programmers to be learned? Not for the users?

I believe that what Rasmus meant is that a simple _renaming_ of this
token was not justified.

I don't think that he would be against a parser change that would
bring much more to the table, solely because it would make this gem
disappear (at least I hope).

But then again, even though Felipe did an amazing job with this lemon
switch, few problems still prevent this change from happening in a near
future.

Best,


-- 
Etienne Kneuss
http://www.colder.ch

---

## #50094 — jvlad — 2010-11-03T21:21:33+00:00

URL: https://externals.io/message/50052#50094 · In reply to: #50053

>
> Yes, there is a reason:
>
> As it was explained before, lemon would not display token names but
> actual token "values". So instead of "Unexpected T_PAABLAH" it would say
> "Unexpected '::' ..."
>

hello,
value of some tokens is not what would be expected either. Think a bit about 
 `T_STRING` for example.
There should be a smart algorithm implemented.
BTW bison-createdparsercan use a callback (yytnamerr) to replace tokens with 
something human-readable. Why not use it?
