REBOL3 tracker
  0.9.12 beta
Ticket #0002156 User: anonymous

Project:

Previous Next
rss
TypeWish Statusdismissed Date15-Jun-2014 22:09
Versionr3 master CategorySyntax Submitted byfork
PlatformAll Severityminor Prioritynormal

Summary Default comma and period to something that terminates expressions
Description In CC#2155 I suggested an equivalence between comma and period in word lookup.

Which seems like a good idea regardless (as opposed to forbidding commas in words), but it was to enable a specific proposal of something that a lone comma (or period) could be used for -- as a punctuator of expressions.

Imagine using the definition:

,: does [exit]

As applied to the following:

if all [1 < 2 , add 10 , 5 < 6] [
print "The incomplete ADD will choke."
]

The concept is to apply comma as an *optional* expression separator. Hardened Rebol code would generally not want to use such a thing -- much as how the use of parentheses is discouraged for precedence in advanced coding. But to have such a tool would help those trying to learn, or if you wanted to make it more clear where the expression breaks are.

It could also be a first line of defense in debugging; anyone who hits situations like the one described in CC#2152 could be told to start their diagnosis by "punctuating".

The equality between period and comma is actually a win here, because a full stop after a line of code indicated by a period could be similarly useful.

do [print 1 , print 1 + 2 , print 3] .
print "Hi" .
x: add 10 .
probe x .
Example code

			

Assigned ton/a Fixed in- Last Update3-May-2015 21:30


Comments
(0004441)
giuliolunati
15-Jun-2014 23:37

That would be great! +1
(0004444)
fork
16-Jun-2014 08:40

For purposes of both efficiency and clarity of the error message, this couldbe a separate type that is *like* unset!, that the Do_Next evaluation loop tolerates as long as you don't try to pass it to a function. So then it would be:

,: #[punctuator!]

That way you don't need to make a function call, and the error could be more coherent.

Due to the evaluator logic, this won't work with #[unset!] because trying to evaluate a word that is directly set to unset is an error, even when not passed as a function argument.
(0004445)
rebolek
16-Jun-2014 11:52

Comma is special character in Rebol that cannot be used as word! ( see here: http://www.rebol.net/cgi-bin/r3blog.r?view=0306 ), but using dot for this purpose makes sense. Given that there's limited number of available datatypes, I'm not sure if introducing new datatype that will serve just this one purpose makes sense. There's internal end! datatype that I guess may be used for this purpose (it also makes sense as end of expression), though I'm not sure if it won't introduce more problems than it would solve.
(0004446)
fork
16-Jun-2014 16:33

Carl is saying that comma should not be treated specially as some kind of grouping operator in the parser. This proposal is entirely different, and unrelated to the objection in that blog post. It is much more in line with how 10,20 is equivalent to 10.20...which he endorses.

There is really no difference between using comma and period for this. I just think comma looks better when used on the same line. And it would be nice to open up comma for the usage in symbols for those who have a purpose for it (much as you can use lowercase or uppercase letters if you want).

I don't know anything about end! or how it would relate.
(0004447)
rebolek
16-Jun-2014 16:53

The proposal is different, however, it has same problems as mentioned in the blog article. Let's take your example:

if all [1 < 2 , add 10 , 5 < 6] ...

Because whitespace is optional with separators (such as [, ], and - obviously - comma, as seen in Carl's blog), this can be rewritten as

if all [1 < 2,add 10,5 < 6] ...

and now you have same unclear code as described in the blog.

You can argue that whitespace should be required and not optional in this case, which is perfectly valid argument, but out of scope of this proposal (see #2094 for relevant discussion).

Just to be clear, I'm not against this proposal, I'm just reminding that comma is special beast in Rebol and should be treated very carefully.
(0004448)
fork
16-Jun-2014 17:02

I'm not suggesting it be any different than period. In the example there 10,5 would be 10.5 and 2,add would be illegal.

The arguments seem to be *against* comma being special; which is fine with me.
(0004458)
BrianH
22-Jun-2014 02:16

I'm not necessarily in favor of this, just working through the idea as if I were for the sake of argument.

We could make a comma an attribute of a position of a block/paren, similar to how a new-line is now. It wouldn't be a value, so it wouldn't affect the behavior of regular Rebol code in the slightest. As with the new-line attribute, you could make a dialect that checks for it like you can with NEW-LINE? now - a *really bad idea* generally, but doable. But for the most part, it would just be something that controls MOLD formatting. It *absolutely should not be a datatype*, nor should it be a value. Just a bit in a block value slot.

The main problem is the ambiguity in the syntax. For one thing, we wouldn't be able to have a comma be a delimiter like whitespace is (except possibly after a word, according to Carl here: #537). We would need to work through all of the possibilities. After loading though, when the blocks with the comma attributes are molded, the commas should be formatted with spaces around them, or a space and a new-line if the position has both comma and new-line bits set. We need to make sure these are visually separated, to make up for the low visibility of the comma character.

The biggest issue is the justifiable, righteous aversion that the majority of the Rebol community has to commas in Rebol syntax. But that's a different problem. Hopefully them having no value whatsoever, and not at all affecting argument evaluation in any built-in dialect, maybe that will cut down on some of the arguments.

Marked the ticket as a problem solely due to the suggestion that a comma have any semantic effect on Rebol expressions. Without any semantic effect, just being a syntax tweak, it is less of a problem.
(0004470)
fork
22-Jun-2014 22:02

I am in no way of favor of a syntax tweak. I am specifically suggesting that the comma is *really there*.

>> length? [a , b]
== 3

Any understanding that would not report 3 there is not in line with my suggestion. Also:

>> type? second [a , b]
== word!
(0004475)
abolka
24-Jun-2014 20:26

Carl blogged about this back in 2007 as well:
"Explicit Evaluation Terminator -- http://www.rebol.net/r3blogs/0086.html"
(Be sure to also check the comments.)

Quoting Carl: "I've been thinking about this for more than 8 years"

Two other things to note:
- Also using "." (period) and "," (comma)
- Also not just syntax: "The dot here is not really syntactical like that of the semicolon (;) found in other languages. It is actually part of the expression. It is a semantically-based terminator."
(0004616)
fork
29-Mar-2015 18:03

I've experimented with this and found that though I like the idea, I do not like dot (or by extension, comma) for it.

>> .: does [exit]

>> if all [1 + . 4] [print "Confusing."]
** Script error: + does not allow unset! for its value2 argument
** Where: all
** Near: all [1 + . 4] [print "Confusing."]

Too close to the baseline, too hard to see, too likely to get perceptually stuck to numbers. This seems a better use for vertical pipe than its current purpose:

>> |: does [exit]

>> if all [1 + | 4] [print "Better."]
** Script error: + does not allow unset! for its value2 argument
** Where: all
** Near: all [1 + | 4] [print "Better."]

It's not entirely contentious with the use of vertical pipe in PARSE, as it's trying to represent a kind of "barrier" there too.

It looks better as an interstitial than used for the purpose when you break lines. But that usage was really more a debugging crutch when you are trying to figure out where an arity failure is happening. You wouldn't leave your code like this:

do [print 1 | print 1 + 2 | print 3] |
print "Hi" |
x: add 10 |
probe x |

If you did that you'd probably want to do it like people do with parse today, cases like:

foo [
    do [print 1 | print 1 + 2 | print 3]
|
    print "Hi"
|
    x: add 10
|
    probe x
]

Again, that is--if you were to do it at all between lines.
(0004640)
fork
3-May-2015 21:29

Time, testing, and market research have shown that vertical bar has *some* of what it takes to be an expression barrier, at least in aesthetics and usage. But it has a few problems suggesting it is not the answer.

One glaring problem is that PARSE could also benefit from whatever this "expression barrier" (that is effectively an UNSET!) is, which would require a rewiring of parse to make these equivalent:

parse "aaaabbbcccc" [4 "a" some "b" any "c"] => parse "aaaabbbcccc" [4 "a" | some "b" | any "c"]

However... | is quite entrenched in PARSE for its current meaning. Moreover, even those people who feel decisions can be revisited and no questions are off the table push back saying that how | is used in PARSE today is "the right use" and notationally established. (The don't-rock-the-boat people consider it much too late to change such a "foundational" decision, but I expect that response from them...)

So although it is visually pleasing for the purpose, | is right out. This had already drifted enough from the original proposal, so an updated suggestion is in #2217 and this one is closed.

Date User Field Action Change
3-May-2015 21:30 Fork Status Modified problem => dismissed
3-May-2015 21:30 Fork Comment : 0004640 Modified -
3-May-2015 21:29 Fork Comment : 0004640 Added -
29-Mar-2015 18:04 fork Comment : 0004616 Modified -
29-Mar-2015 18:04 fork Comment : 0004616 Modified -
29-Mar-2015 18:03 fork Comment : 0004616 Added -
24-Jun-2014 20:26 abolka Comment : 0004475 Added -
22-Jun-2014 22:02 Fork Comment : 0004470 Modified -
22-Jun-2014 22:02 Fork Comment : 0004470 Added -
22-Jun-2014 02:20 BrianH Comment : 0004458 Modified -
22-Jun-2014 02:18 BrianH Description Modified -
22-Jun-2014 02:18 BrianH Type Modified Bug => Wish
22-Jun-2014 02:18 BrianH Status Modified submitted => problem
22-Jun-2014 02:18 BrianH Category Modified Unspecified => Syntax
22-Jun-2014 02:16 BrianH Comment : 0004458 Added -
16-Jun-2014 17:02 Fork Comment : 0004448 Added -
16-Jun-2014 16:53 rebolek Comment : 0004447 Added -
16-Jun-2014 16:34 Fork Comment : 0004446 Modified -
16-Jun-2014 16:34 Fork Comment : 0004446 Modified -
16-Jun-2014 16:33 Fork Comment : 0004446 Added -
16-Jun-2014 11:52 rebolek Comment : 0004445 Added -
16-Jun-2014 08:40 fork Comment : 0004444 Added -
16-Jun-2014 08:08 fork Comment : 0004442 Removed -
16-Jun-2014 08:08 fork Comment : 0004442 Modified -
16-Jun-2014 08:07 fork Comment : 0004442 Modified -
16-Jun-2014 08:07 fork Comment : 0004442 Added -
15-Jun-2014 23:37 giuliolunati Comment : 0004441 Added -
15-Jun-2014 22:09 fork Ticket Added -