| Type | Wish | Status | submitted | Date | 24-Feb-2013 18:25 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Datatype | Submitted by | rgchris |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Datatype for @handle Type Notation. |
|---|---|
| Description |
Reflects now established convention of @name notation referring to a person in web/online services. There's a strong semantic case for this as a datatype for use in data exchange/storage and dialecting.
Twitter defines a handle as `["@" 1 15 [alphanum | #"_"]]` though generally longer names could be supported with possibly more characters to support a wider range of services. Does not conflict with email! literal as @domain.com format is not permitted. Possible names include handle! person! user! |
| Example code |
twitter: @rgrebol stackoverflow: @rgchris read some-api [posts by @rgchris] |
| Assigned to | n/a | Fixed in | - | Last Update | 17-Aug-2013 17:19 |
|---|
| Comments | |
|---|---|
|
(0003493)
BrianH 24-Feb-2013 19:00 |
The syntax doesn't really conflict with email!, but not because of any domain checking or dots: it's because it doesn't have anything before the @. And it triggers an error when you write one, which is a problem if this syntax is used as much as you say in regular communication. However, it's a benefit for us because it means that we might be able to have a new datatype without breaking existing code. It seems to me that having the distinction between this and email might help with block parsing where the difference might affect what you do with the information. It should be a string type.
However, we already have a handle! type, and it's not inappropriately named. Is there some term for your concept that isn't just Twitter jargon borrowed from CB jargon? I don't use Twitter, so I don't know. Suggestions? We need to remember though that adding a new datatype is a really big deal. Due to structural reasons we are limited to 64 datatypes, including internal ones like end!. If there is any possible way to do this without adding a new datatype, we should seriously consider it. For instance, have you considered making email! not choke on syntax that doesn't include the name portion? It seems to me that we can easily distinguish between Twitter handles and email using similar code that we use to distinguish between files and directories, which also share the same datatype. Maybe that approach would serve us well here. |
|
(0003495)
BrianH 24-Feb-2013 20:36 |
Brainstorming in SO chat has resulted in suggestions of name!, at!, and at-name!. |
|
(0003496)
fork 24-Feb-2013 20:36 |
It does seem useful and "savvy" considering that it doesn't really conflict in the parser, and is so insanely popular these days. (I type @Someone a lot more often than their email address these days, in fact.)
However, I don't like the idea of it being called something too semantic just because of how it's used somewhere. It would be like calling PAREN! something like PRECEDENCE!, and then telling dialect authors "oh that's one use of it, but you can override it in your dialect for other meanings". So my suggestion is to call it AT! ... the only real downside is that it might be confused with the AT native. Perhaps not a problem. Whether it would be an ANY-STRING! vs ANY-WORD! is an interesting question. With ISSUE! now a word type, it might be confusing if something people see used as hashtags in dialects behaved differently. I would think consistency with ISSUE! could be more important than consistency with email, url, etc. |
|
(0003497)
BrianH 24-Feb-2013 20:53 |
We'd have to decide whether the thematic inconsistency between the not-type-related AT function and an at! type would be a problem.
A much bigger problem is, what benefit would we get from not counting these as the email! type, and would that benefit outweigh the really serious downside of allocating one of our precious few available datatypes to make that distinction? For instance, which is more important, separate at! and email! types, or a possible bignum type that would justify being a separate datatype by requiring a different kind of math? Because that is how high the bar is for adding a datatype. |
|
(0003546)
fork 1-Mar-2013 04:11 |
It sounds pretty clearly to me like the answer is not to make a new datatype, then.
So... unify with email, just don't call it email? I don't like handle at all, it's a loaded term in computer programming and will confuse people. If AT! is rejected because of AT, then I'd at least expect something in the spirit of USERNAME! |
|
(0003547)
adrians 1-Mar-2013 04:32 |
Not sure I would agree with unification. That would dilute the already not-quite-per-spec aspect of the current implementation, by necessity. I'd say just fix up email so it doesn't error out on blanks before the @. |
|
(0003921)
Ladislav 14-Aug-2013 10:09 |
@username is currently not recognized as an email! value. Which is good, in my opinion, since it would most probably violate some email-related standards. Thus, I am against the "unification" pretending these are emails.
If the question is whether we do want a new datatype then I surely do not, having quite some work with existing datatypes: function! datatype needs revamp, closure! datatype needs revamp, object! datatype needs revamp, char! datatype needs revamp, string! datatype (and many related to it) needs revamp, url! datatype needs revamp (the only clean way I see is to relate it to binary! datatype), error! datatype needs revamp, ..., and I would prefer to save the available space for other datatypes that might prove even more useful. |
|
(0003922)
onetom 14-Aug-2013 14:24 |
I'm against unification too.
I would expect EMAIL! to be an RFC complaint validator, but which RFC?... The topic is quite complex as we all are very aware: http://en.wikipedia.org/wiki/Email_address Have you noticed how email! was always referred to with lowercase letters, while almost all other datatypes are all-caps? I'm not sure what does it mean, but looks like "an error in the Matrix". I don't see a clash with AT, btw. one is a datatype, the other one is a function... It would be easier to decide this matter if everyone would provide some example usage of this imaginary new AT! type first. And let's not forget that this is how you send email with a human readable name: send to-email {"Hostile Fork" <hf@host.com>} "test" and any-string? to-email "@fork" is true too. |
|
(0003932)
johnk 17-Aug-2013 14:54 |
This is a summary of recent discussions on SO chat re handles.
We do not want to rename email as it is well understood, widely accepted and used. It may be improved by following the RFC more closely, but that is for another ticket. Relaxing the email datatype to allow @handles would not be a good solution as it breaks the email spec and is not well named for a handle. If we do want a new datatype there is support for at!, username! and nick! with no clear favorite. Raw poll results: 3 email! 0 handle! 3 at! 0 name! 0 person! 1 user! 3 username! 1 nick! 0 nickname! 11 Total The @handle type is not consistently specified across social media channels. eg facebook vs twitter allow different characters in their handles. There is concern over the current 64 datatype limit. Summary: Candidate for a new datatype, but the priority to do this is low |
|
(0003933)
onetom 17-Aug-2013 17:19 |
There was a poll about this issue announced on SO. I guess you pulled your conclusion from that, but instead of just stating your opinion, please include the actual results here too. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 18-Aug-2013 13:27 | Ladislav | Comment : 0003921 | Modified | - |
| 18-Aug-2013 05:05 | johnk | Comment : 0003932 | Modified | - |
| 17-Aug-2013 17:19 | onetom | Comment : 0003933 | Added | - |
| 17-Aug-2013 14:54 | johnk | Comment : 0003932 | Added | - |
| 14-Aug-2013 14:29 | onetom | Comment : 0003922 | Modified | - |
| 14-Aug-2013 14:28 | onetom | Comment : 0003922 | Modified | - |
| 14-Aug-2013 14:24 | onetom | Comment : 0003922 | Added | - |
| 14-Aug-2013 10:12 | Ladislav | Comment : 0003921 | Modified | - |
| 14-Aug-2013 10:10 | Ladislav | Comment : 0003921 | Modified | - |
| 14-Aug-2013 10:09 | Ladislav | Comment : 0003921 | Added | - |
| 1-Mar-2013 04:48 | adrians | Comment : 0003547 | Modified | - |
| 1-Mar-2013 04:32 | adrians | Comment : 0003547 | Added | - |
| 1-Mar-2013 04:11 | Fork | Comment : 0003546 | Added | - |
| 24-Feb-2013 20:53 | BrianH | Comment : 0003497 | Added | - |
| 24-Feb-2013 20:45 | BrianH | Comment : 0003493 | Modified | - |
| 24-Feb-2013 20:43 | BrianH | Comment : 0003493 | Modified | - |
| 24-Feb-2013 20:36 | Fork | Comment : 0003496 | Added | - |
| 24-Feb-2013 20:36 | BrianH | Comment : 0003495 | Added | - |
| 24-Feb-2013 19:00 | BrianH | Comment : 0003493 | Added | - |
| 24-Feb-2013 18:25 | rgchris | Ticket | Added | - |