REBOL3 tracker
  0.9.12 beta
Ticket #0001962 User: anonymous


TypeWish Statussubmitted Date24-Feb-2013 18:25
Versionr3 master CategoryDatatype Submitted byrgchris
PlatformAll Severityminor Prioritynormal

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 format is not permitted.

Possible names include handle! person! user!
Example code
twitter: @rgrebol
stackoverflow: @rgchris
read some-api [posts by @rgchris]

Assigned ton/a Fixed in- Last Update17-Aug-2013 17:19

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.
24-Feb-2013 20:36

Brainstorming in SO chat has resulted in suggestions of name!, at!, and at-name!.
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.
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.
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!
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 @.
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.
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:

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" <>} "test"
any-string? to-email "@fork" is true too.
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.

Candidate for a new datatype, but the priority to do this is low
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 -