| Type | Wish | Status | submitted | Date | 5-Apr-2013 02:04 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Ports | Submitted by | mmcghan |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Rename "port!" abstraction to avoid confusion with TCP port and physical port |
|---|---|
| Description |
Editing the document "Writing a Network Scheme for Rebol 3" by Graham Chiu sparked my interest in clearing up confusing terminology. "Port!" is used differently in Rebol than in TCP terminology, and sometimes interchangeably to mean "Port number". It took me personally a fairly long while when first learning about Internet conventions to realize that an Internet "port" wasn't some kind of hole in some machine, somewhere! I'm starting to get so annoyed at this word that I'm going to call where ships go "harbors" from now on. :) Graham indicated that the word "conn" has been used to signify the connection inside of port! objects, instead of "sub-port" to clear up potential confusion. However, in the interest of clarity of language usage, using abbreviations seems to not be a good idea. I would wish for using a whole word like "connector" (does that have an existing meaning in programming contexts?) instead of "port." To my inexperienced eyes, this makes more sense. It seems like Rebol wants to embrace the internet, and if the word is used differently from the "port" of internet convention, it could be off-putting. |
| Example code |
old naming convention: >> x: open http://meredithmcghan.com:80 >> type? x == port! one of many possibilities for a new naming convention: >> x: open http://meredithmcghan.com:80 >> type? x == connector! |
| Assigned to | n/a | Fixed in | - | Last Update | 8-Apr-2013 12:35 |
|---|
| Comments | |
|---|---|
|
(0003779)
BrianH 5-Apr-2013 04:00 |
Rebol is not a pre-1.0 product, it's a pre-3.0 product. There are a lot of very practical reasons that we can't change the name of a datatype that has existed for more than a decade. In general, we can only change the names of new datatypes that were added in 3.0, and that is only until 3.0 comes out of alpha, at which even those names will be set.
I can refer you to the other rejected tickets requesting type names be changed if you like, but here is the basic issue: Type names are a special case of the backwards compatibility rules because of the TYPE?/word function, which returns the canonical name of a type as a word value. This function is used a lot, whenever you need compare the datatype of a value to some known type, by name. When you are comparing a datatype by value (as returned by the TYPE? function without /word) its name doesn't matter - the same type could be assigned to many names. But the TYPE?/word function can only return one name, and a lot of code depends on it being a particular name, particularly code that uses FIND or SWITCH. A similar issue is that some code depends on the textual representation of a type as generated by MOLD, FORM or TO-STRING being the same, but that is generally more rare. Most of the time people who save a type to a string or file, load the string or file before making their comparisons, rather than comparing the string or binary data directly. So it's not as much of a problem as long as you still have the old name around. Same goes for datatype names used as keywords in dialects, you can add a new keyword as long as the old one is still there. So, you can add a new name for a type, but it is not that useful to do so, and you can't change the primary name of a type without breaking a lot of code. |
|
(0003782)
fork 5-Apr-2013 09:20 |
Okay, rant time.
I don't personally know about connector, as a name. It's unabbreviated from "conn" in Graham's paper and that's a kind of arbitrary reason to pick it, without study of how it's used in other languages (I don't offhand know of an established meaning). But I agree that "port" will likely contribute to repeated misunderstandings and therefore lost opportunities. This will come from new people who are just confused--or experienced people who think Rebol is stubborn by not engaging the way words are used by the broader Internet community (and really doesn't have a justification outside of historical reasons for sticking with a not-generally-known meaning). This particular detail is small issue, when compared to the broader issue of mentality captured in @BrianH's statement: "Rebol is not a pre-1.0 product, it's a pre-3.0 product". The fears of changing the system despite possibly making it more coherent and palatable to new audiences does keep coming up as a contention. It seems to be built on three major pillars: (a) Maintaining compatibility and ease of upgrading Rebol 2 codebases to Rebol 3. This the TYPE?/WORD "bugaboo" that @BrianH very-frequently-mentions, as the kind of thing that should scare us of renaming EMAIL! to something more general in the spirit of HANDLE! if it's extended to allow things like [@BrianH] (b) Not wanting to cause confusion with recorded legacy documentation on the world wide web about Rebol 2. If long-held assumptions or terminology are changed, it is thought this will create chaos when people are trying to reconcile that documentation without realizing which version of Rebol is being discussed. (c) A belief that the decisions that have been made are right by fiat, for reasons such as "port in the Rebol sense was how the word was used by the Amiga, and it was on the scene first, so it deserves the word!" I do not believe these arguments truly hold water when critical thinking is applied. So this small issue is a lens through which I feel Rebol could better understand some aspects of its history of marginalization, despite impressive technical virtuosity in many areas. I'm sorry to sound dismissive of the work that has been done by saying the existing market penetration of Rebol is insignificant in the "scheme" of things. But perhaps consider the brighter side of the statement as optimistic by saying that Rebol Has Not Yet Begun To Fight...! RE: (a) I'll take @BrianH's "word" that TYPE?/WORD appears often in codebases he has written, or seen. But in the grand "scheme" of changes, that's the kind of thing that a search-and-replace tactic can fix. There are much more insidious alterations that need to be addressed which simple inspection of the code can't easily repair. The existing few Rebol applications (as a percentage of the whole, or compared to any popular language) are written by authors who seem in the best position to roll with the punches and patch things up. Plus Cheyenne will not be having a new version written in Rebol 3, CureCode will not be having a new version in Rebol 3, AltME will not be having a Rebol 3 "port" any time soon. I have seen firsthand--also--the technical challenges in porting an R2 codebase, even after this conservative attitude has been employed. RE: (b) Rebol's web presence is barely a blip yet, and can (and should) have a massive cleanup campaign. There are some mailing lists, but like any other old Usenet posts most of them will be lost to history. Sites like reboltutorial.com have just disappeared. It wouldn't be hard for the few remaining stakeholders--who have any search rank--to be contacted to restructure things. And if we promote, use, and import Q&A into systems like StackOverflow (instead of cruddy mailing lists that can't be wiki-edited by us) then the risk of information that can't be updated or discerned drops. RE: (c) For a first point, hubris can be a bit of a turn off. But this is the kind of Amiga/Rebol folklore that's using a selective interpretation of history to suit an existing handful of users. One can *choose* to debate that the rise of the web came later than certain achievements in Amiga or Rebol history...yet a more mainstream view would be that Berkeley sockets were released in 1983. So if history is to be cited then they own the word "port" in the numeric sense. Again: I don't think this is all that big an issue in isolation. If Rebol wants to say "We use port in a different sense than you may be used to, and what most people on the Internet call a port we refer to as a legacy concept called tcp-port-number"...this alone isn't the end of the world. It makes things a bit harder for indoctrination, but if you hammer people over the head with it from the very beginning they'll learn like they learn about the rest of Rebol's peculiarities. I think there's just a matter of being self aware that you're taking a Humpty Dumpty attitude about the need for common terminology, and owning up to it: http://www.fecundity.com/pmagnus/humpty.html Unfortunately, it's not the greatest way to get popular. My real complaint is this belief that what's about to be released is not "Rebol X" but "Rebol 3", in a world where the significance of Rebol 1 and 2's installed base should not be a notable driver of decision. I will repeat my mantra that if you get 100 smart non-Rebol programmers into a room who you'd like to convince them of the language's merits, and they all vote on a questionaire "wow, that's not what port means, this sucks"...then that matters. This is called *metrics* and I have almost never seen them used in Rebol lore for anything, ever. Such a policy will *ensure* Rebol's continued marginalization. I don't know whether they'd think it doesn't matter or not--depends on the audience--but one must define the target market. Anyway, success can be defined in many ways. The Rebol product and brand may seek to please the taste of its installed base instead of focusing on growing the audience. If so, then perhaps proposals like this belong in the Red issue tracker instead. |
|
(0003783)
bitsoma 5-Apr-2013 09:38 |
This comment has nothing to do with the topic itself, but I feel I need to say this anyway as a long time Rebol 2 user:
@fork: +100 |
|
(0003785)
fork 5-Apr-2013 10:34 |
@bitsoma thanks...
In the meantime, @DocKimbel sent me a good argument that it's common Internet usage that broke from the more general CS traditions. If you don't start from the Berkeley sockets article on Wikipedia, but rather start from their definition of "Port (Computer Networking)", it supports Rebol's usage: http://en.wikipedia.org/wiki/Port_(computer_networking) (For that matter, why should one ever have embraced the word "socket" anyway? Can you adjust a TCP socket with a "TCP socket wrench"? Can you wear a TCP socket in your "TCP shoelet"? Where did this come from? :-P) This makes a good case for keeping it as PORT! and then calling the numbers things like PORT-NUMBER (Doc also pointed out that it's not just TCP that has ports, but UDP too.) Yet this means that everyone writing Rebol documents or code should be consistent and firm on the distinction, even possibly being diligent of hyperlinking PORT-NUMBER to a well-written essay explaining why a potentially confusing usage was chosen, seeming to fly in the face of conventions most people know. After all, Rebol is in many ways a re-education effort. But being conscious and clear and citing compelling evidence for why any given re-education is necessary is critical to that process. I just want us to build consensus that "guru meditating" and making a case for what's correct is still of vital importance. It's more important than things like TYPE?/WORD or worrying about going back on questionable decisions. However in this *particular* case, it looks like the best course of action is just to rename some internal variables in scheme handlers to reflect a consistent view, and fix documentation. |
|
(0003787)
abolka 5-Apr-2013 14:48 |
A port! in Rebol is used for much more than networking. It is really more like an interface to a multitude of other systems; and therefore, in usage, much closer to the other common concept of port:
https://en.wikipedia.org/wiki/Computer_port_(hardware) (Think: USB port, printer port, display port, ...) In Rebol, we have TCP ports, DNS ports, event ports, file ports, the system port, etc. Port seems like a perfectly fine name for that concept. |
|
(0003788)
BrianH 5-Apr-2013 19:04 |
Fork, the problem isn't the TYPE?/word function in particular, it is what that function does, which is return a word that corresponds to a datatype value. It can only return one word, and that word becomes the primary name of the datatype. I can show you the type of code that requires word comparison rather than datatype comparison, and such code can't necessarily be rewritten in some cases without significant overhead.
So ignore that TYPE?/word is the function currently used, and realize that there will need to be some function that does that, and any such function will cause the same constraint. Datatypes aren't like functions, their name actually matters. We can't change these names once they're standardized. This isn't an R2 thing, this would be the case for R3 as well, which is why any types introduced in R3 would need to keep the same name once 3.0 comes out as a non-alpha. Nonetheless, I agree with you and abolka here, we are using the word "port" in a way that is more metaphorically accurate than TCP/UDP does. If we need to change the number-after-the-colon-in-the-address-section to port-number or something, that would work. |
|
(0003807)
Ladislav 8-Apr-2013 12:35 |
"Type names are a special case of the backwards compatibility rules because of the TYPE?/word function" - this may seem off topic here, but TYPE?/WORD is another ad hoc solution to a more general problem. I dislike it since a better general alternative exists. However, the proper alternative: #[datatype! none!] also needs "stable type names". |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 8-Apr-2013 12:35 | Ladislav | Comment : 0003807 | Added | - |
| 5-Apr-2013 19:06 | BrianH | Comment : 0003788 | Modified | - |
| 5-Apr-2013 19:04 | BrianH | Comment : 0003788 | Added | - |
| 5-Apr-2013 14:48 | abolka | Comment : 0003787 | Added | - |
| 5-Apr-2013 10:36 | fork | Comment : 0003785 | Modified | - |
| 5-Apr-2013 10:34 | fork | Comment : 0003785 | Added | - |
| 5-Apr-2013 09:38 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:38 | bitsoma | Comment : 0003783 | Added | - |
| 5-Apr-2013 09:30 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:29 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:24 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:23 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:20 | fork | Comment : 0003782 | Modified | - |
| 5-Apr-2013 09:20 | fork | Comment : 0003782 | Added | - |
| 5-Apr-2013 04:00 | BrianH | Comment : 0003779 | Added | - |
| 5-Apr-2013 02:07 | mmcghan | Description | Modified | - |
| 5-Apr-2013 02:06 | mmcghan | Description | Modified | - |
| 5-Apr-2013 02:06 | mmcghan | Code | Modified | - |
| 5-Apr-2013 02:06 | mmcghan | Description | Modified | - |
| 5-Apr-2013 02:04 | mmcghan | Ticket | Added | - |