AltME: REBOL3

Messages

Gregg
On paths with leading parens, they could be useful. I, myself, might even have missed having them a time or two, but not often enough to consider proposing the change you suggest. So, I don't agree that it's too useful to just ignore and, since we've never had it, I also can't say if it will be a common expression syntax. Meaning, just, that I don't place the same weight on its potential value that you do right now, but I agree it could be useful. And it would be small work to make it easy to use. e.g.:
    pathify (now + 150) weekday
My gut feeling is to say +1 to paren paths, but I would love to hear others weigh in with any issues they think might arise because of it.
Ladislav
I did not write #2094 to just pick paren paths and ignore Rebol syntax design. For example, if we do not take it seriously that space is significant not just when preceding some alpha character or a digit, we lose many opportunities to add new syntax to Rebol after going out of alpha stage. For example, we will not be able to introduce syntax like
my-heredoc{}my-heredoc
later, because somebody will state he wants to be able to omit space at his whim meaning
    my-heredoc {} my-heredoc
, i.e., wanting to get two words and an "old-fashioned" string when writing
    my-heredoc{}my-heredoc
That certainly is legitimate. If you really want that, please be so kind and say so now at least as an information for me to be able to take that into account
Also, I do not need, e.g. ()/() to be supported immediately, I just wanted what #2094 stated, i.e., make sure that ()/() shall be treated as a different syntax than () / ().
What is the meaning of the syntax can be decided later, now it is necessary to make sure there may be some "later"
I see this as an opportunity to amend Rebol syntax with the future in mind, that is why I wrote the ticket
Ladislav
also, regarding cases like:
    f: my-func [spec block contents] [body block contents]
I am pretty sure that nobody wants to deny that
    f: func my-spec my-body
needs space between MY-SPEC and MY-BODY since they are two distinct arguments of FUNC. Also, space preceding the [ charater is significant as can be proven comparing
    #[]
and
    # []
, which actually differ only in space preceding the [ character. There are much more serious changes already in R3 than the change proposed in #2094
Gregg
{i.e., wanting to get two words and an "old-fashioned" string when writing
    my-heredoc{}my-heredoc
That certainly is legitimate. If you really want that, please be so kind and say so now}
I thought I did say so. Yes, that is what I want.
Ladislav
For example, #2094 may be used to find a very reasonable syntax for matrices, arrays,and some values that may be needed int the future
Also, there already is a demand for the
    my-heredoc{}my-heredoc
syntax as you might have noticed
Do you really want to flush all these opportunities down the sink?
Gregg
Right now, yes. You haven't convinced me that the changes proposed in #2094 will make REBOL a better language.
Ladislav
Notice that there is no "right now". Once out of alpha it will not be possible any more.
Gregg
When I say "right now", I mean "based on my curreny body of knowledge". Mine is only one vote.
Ladislav
Yes, I understand what it means. I did try actually quite hard writing a lot in the ticket, discussing the things here and presenting many useful case already like:
* path syntax amendments
* convenient heredoc syntax
* conveninent syntax for vectors, matrices, whatnot
For me these reasons are convincing. I do not think I can be much more persuasive than this.
I, of course, mentioned, that virtually every case ignoring space significance is provably a bug in either MOLD or LOAD. I mentioned correctness, reflexivity, expressivity, consistence. I think that I am done with convincing.
Gregg
I appreciate your efforts. As I said above, path improvements: YES  auto-gluing blocks and strings together: NO.
Ladislav
Well, I demonstrated above that space preceding the [ character is significant. I do not need more.
I mean that the siginficance of the space preceding the [ character is not my invention. I just work with it in a way that it deserves.
Ladislav
I also must say, that it is the other way around. There is no auto-gluing proposed in #2094. What I proposed is no auto-separation.
That is, I am the one who does specify how it looks. If I write it glued, then I mean glued. If I write it separated, then I mean separated. It is actually you forbidding me to do that.

Last message posted 164 weeks ago.