World: r3wp

While rebuilding the cloud server that runs this world, somehow the 
old Core group file became corrupted. I have no idea how it happened. 
The tar backup showed the correct datestamp, but the extracted file 
was shorter than it should be.


Anyway... Using a copy of the file from my client, I fixed most of 
it.... but there are quite a few message in that group, so I've renamed 
it, and created this new one to take its place.

Some of you might see a long delay while AltME attempts to resync 
that older group (which is a few MB in size.) But, hopefully, it 
will return to normal after a few minutes.

BTW, I think a couple days of Core msgs were lost.  If someone wants 
to repost them, you can put them here.

How do you get:
newob: make object! [
    catalog: make object! [
	book: [make object! [
	         author: make object! [
	          value?: "Gambardella, Matthew"
	         ]
	       ]
	]
    ]
]

from:

ob: make object! [
    catalog: make object! [
        book: [make object! [
                author: make object! [
                    value?: "Gambardella, Matthew"
                ]
               ]
        ]
     ]
     extra: {don't want}
]


What I really need is the set-word "Catalog:" to be present and not 
just a make object! [book...] which is what I get if I do something 
like newob: ob/catalog. 
Thanks in advance.

Is this what you want?  (newob/catalog and ob/catalog now reference 
the same object, so changes would update both..)

newob: make object! [catalog: ob/catalog]


For them to be entirely independent, it's a bit more difficult (or 
just a long line/multiple lines of "make xxx") - I can't think of 
a simple way to do it.

Thanks Izkata. How simple. And yes, that's fine.

James, here is another way, if you know the words you want to remove, 
rather than the words you want to keep.

remove-words: func [

    "Returns a copy of the object with the specified words removed."
    object [object!]
    words  [word! block!] "The word, or words, to remove"
    /local spec
][
    spec: third object
    foreach word compose [(words)] [
        remove/part find/skip spec to set-word! word 2 2
    ]
    make object! spec
]

o: context [a: 1 b: 2 c: 3 d: 4 e: 5]
probe remove-words o 'c
probe remove-words o [a e]

Thanks Greg. This project is just one of those troublesome projects 
that just when you think you got it, something isn't quite right.

and did you have to manage namespaces yet  ;-)

I added a comment to

http://curecode.org/rebol3/ticket.rsp?id=1194&cursor=1


describing a syntax variant that looks like being available in REBOL 
for heredoc strings. Does it look acceptable to you?

I have nothing to say against it.

Looks ok to me.

I think we need to consider what the MOLD output looks like, though 
I'm not sure about Oldes's suggestion of a /heredoc refinement. And 
while I like Ladislav's serialized rebol syntax, I wonder if there 
are other possibilities. Could we leverage the << heredoc standard, 
and would that be better or more confusing with the tag! type as 
a close relative. It also makes me think more generally about where 
it fits in the rebol lexicon. Is it still just a string!, or are 
there wider implications? What do we call it? Is its main purpose 
to make dealing with curly-brace languages easier, and is that just 
a vague "nicer thing" or are there specific cases we have in mind 
(e.g., test cases :-) ? If rebol is still at its heart a messaging 
language, how would we leverage this type of "payload"?

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

Could we leverage the << heredoc standard - actually not, <<is already 
taken, it is a word in REBOL

so, that would not be backwards compatible with REBOL syntax

I updated the comment to mention the advantages of the proposed syntax 
as I see them.

 Is it still just a string!, or are there wider implications?
 - of course, this is yet another string syntax

Adding it, we will actually obtain three types of string syntax

Note to the {...} syntax. It actually is a heredoc-type syntax. The 
only trouble with it is, that it does not have the variable part.

...so it has to use escaping for #"{" and #"}"

, which is a problem, since the use of escaping defies the whole 
purpose of it

What do we call it?
 - I propose "the heredoc syntax"

Is its main purpose to make dealing with curly-brace languages easier

 - not, I would use it to transform the core test suite to REBOL (which 
 it actually isn't now)

(that is exactly what you proposed in the Testing and Tools group, 
every test could be)

#[[test
; this is my test
test]]

Moreover, you can easily embed just about any text in REBOL, not 
just the source of curly-braced languages, but even REBOL code examples, 
or any general text that comes to mind without worrying about escaping

REBOL is not just a language allowing computers to communicate (if 
it were, escaping would be enough for every string), but also a language 
allowing humans and computers to communicate. And, I do not find 
escaped strings to be easily writable/readable for me, that is why 
I prefer to have the heredoc syntax available.

So, in general, the usage of the heredoc syntax shall make REBOL 
more readable/writable/handleable for humans, which is a good thing 
(tm), if it weren't there would be no reason to not use the machine 
language still.

#[[Graham

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

Graham]] - I do not understand how would such a proposal work. Can 
you be more specific, showing an example?

Generally spoken, I do know what the advantages of the heredoc syntax 
are, and I hope I succeeded to communicate that to you. The syntax 
is used in other programming languages, making them more comfortable 
for humans. Not having the syntax in REBOL is not good, especially 
taking into account, that REBOL, as opposed to the above mentioned 
languages, is not just a programming language, meaning, that in REBOL 
you can write more than just programs.

#[[Carl

Although it can be used for programming, writing functions, and performing 
processes, its greatest strength is the ability to easily create 
domain-specific languages or dialects.
Carl]]

@Ladislav ... the { } only have special significance because the 
interpreter is so written ...  so why not make it user definable 
?

Maybe it's not possible without an extensive modification to the 
parser .. I don't know

OK, Graham, show me, how would you handle this string:

#[[example
'^{<+-*/%([#&$a0:;=\|,.}>)]
example]]

not to mention, that I could have put in all 127 ASCII characters

You would define another character(s) instead of { } to be used .. 
normally most languages have them, so if you switch to that language, 
you would use that character

I would do nothing, I am interested in knowing what would you do.

I presume the idea of this is to easily generate javascript and the 
like

You as in the generic person and not you as in Ladislav

Do not forget, that the string contains more characters that need 
to be escaped, than just the #"{" or #"}"

actually, you as Carl as the rebol language implementor

#[[Graham

I presume the idea of this is to easily generate javascript and the 
like¨
Graham]] - I presume, that I wrote above, that this is not true

I was on the fence about the heredoc proposal, but now that Ladislav 
has come up with a syntax that makes sense (this was missing from 
the previous proposal) I am now all for it. One caveat though: It 
would be best if, like other string syntaxes, the syntax details 
are thrown away after loading. By this I mean that
a
{a}
#[[blah
a
blah]]

should all generate the same string. Once it is loaded, there should 
be no way to determine that it was specified as a heredoc. Heredoc 
should be syntax only, not in any way affect semantics.

I can see many uses for heredoc syntax, not just generating Javascript. 
But it would be good for that too.

Oh, and not just ASCII; full Unicode.

I don't think we can throw away the meta info about it being a heredoc 
string, unless we want to use Oldes's idea of adding a refinement 
to MOLD. And then you have to choose when to use it. While we can 
say that it's easy for MOLD to add escapes to curly braces, that 
doesn't mean it will be easier for humans to read generated strings 
that contain them.


I can't say I've ever needed it personally. The { } syntax works 
well, and is as much support as TCL has for heredoc strings it seems 
(we even have TRIM/AUTO to help with indenting issues).  


I want to like the idea a lot, but I only like it a little so far. 
Mainly I wonder if it's worth adding for the sake of just the curly-brace 
chars. I understand the usefulness for the curly-language and test 
dialect scenarios, I'm just not sure of the cost/benefit ratio.

No refinement to MOLD needed. MOLD should know nothing about heredocs. 
Use a separate formatter function, like this:
mold-heredoc: func [value tag [string!]] [ 

 ajoin ["#[[" tag "^/" either string? :value [value] [mold :value] 
 "^/" tag "]]"] 
]

And once it is loaded, it is a string. There is no escaping in memory.

We *really* don't want to add another string type, since that would 
lead to conversion overhead. Another syntax for the existing, unchanged 
string! type is fine though.

Yes, my point is exactly the same, even without any new datatype, 
etc., having just a new syntax to specify strings will be of advantage.