AltME groups: search

I find myself often needing to sort in a file system on date, when 
the file name contains a date, but I have to manually build a new 
date string, where the month is a zero padded number.


Does it not make sense to have a file-system and sort friendly date 
stamp?

HHH still mapping to two digits of course, just a format convention 
used elsewhere that I emulate in my FORMAT func.

it should be simple to do as a mezz

I would still like to see a general FORMAT func, though mine hasn't 
generated any excitement in the past.

don't know if it works in R3 though....

	;------------------------------------------------------------
	;- DATE STUFF
	;------------------------------------------------------------
	; use this to prevent having to supply a spec all the time.
    ; the /default option of date-time sets this.
	default-date-time-spec: "YYYY/MM/DD-hh:mm:ss"
	                             
	
	;--------------------
	;-    date-time()
	;--------------------
	date-time: func [
		""
		/with spec ; specify

  /using thedate [string! date! time!] ; specify an explicit date instead 
  of now()
		/default
		/local str date-rules thetime
	][
		vin/tags ["date-time()"] [date-time]
		
		str: copy ""
		
		
		either spec [
			if default [
				default-date-time-spec: spec
			]
		][
			spec: default-date-time-spec
		]
		
		unless thedate [
			thedate: now/precise
		]
		
		
		if thedate/time [
			thetime: thedate/time
		]
		
		filler: complement charset "YMDHhmspP"
		;spec: "YYYY/MM/DD-H^^hmmP"
		;error: spec
		itime: true
		
		unless parse/case spec [
			some [
				here:
				(error: here)
				["YYYY" (append str thedate/year)] | 

    ["YY" (append str copy/part at to-string thedate/year 3 2)] | 
				["MM" (append str zfill thedate/month 2)] |
				["DD" (append str zfill thedate/day 2)] |
				["M" (append str thedate/month)] |
				["D" (append str thedate/day)] |

				["hh" (append str zfill thetime/hour 2)] |
				["mm" (append str zfill thetime/minute 2)] |
				["ss" (append str zfill to-integer thetime/second 2)] |

    ["rrrr" (append str fill/with/right/truncate (remainder thetime/second 
    1 4) "0" )] |
				
				["P" (append str "#@#@#@#")] | 
				["p" (append str "[--:--]@[--:--]")] | 
				["H" (
					itime: remainder thetime/hour 12
					if 0 = itime [ itime: 12]
					append str itime
					itime: either thetime/hour >= 12 ["PM"]["AM"]
					)
				] |
				["h" (append str thetime/hour)] |
				["m" (append str thetime/minute)] |
				["s" (append str to-integer thetime/second)] |
				["r" (append str remainder thetime/second 1)] |
				["^^" copy val skip (append str val)] |
				
				[copy val some filler (append str val)]
				
			]
			(replace str "#@#@#@#" any [to-string itime ""])
			(replace str "[--:--]@[--:--]" lowercase any [to-string itime ""])
		][
			print ["date-time() DATE FORMAT ERROR: " spec]
			print ["  starting at: "  error ]
			print ["  valid so far: " str ]
		]
		vout/tags [date-time]
		str
	]

Regarding lit-words compared to other datatypes:

>> w: first ['a/b]
== 'a/b
>> type? w
== lit-path!		; this returns path! in R2
>> type? :w
== lit-path!

>> w: first ['a]
== 'a
>> type? w
== word!		; Why?
>> type? :w
== lit-word!


There is this double evaluation of words holding lit-words. Why is 
that? As far I can see, only words holding lit-words and functions 
(incl. natives ...) have this difference in behaviour, when refering 
to them as words or get-words. I understand why with functions, but 
why also with lit-words?

>> x: [16#ffffff] 
== [#6#ffffff]

how can i specify an integer! in hex format?

debase/base "ffffff" 16  returns a binary! which i mostly can smear 
on my hair, since most operators just doesn't play nicely w it...

same problem again... i tried to use rebol for byte level processing 
and it's just not suitable for it.. :/

imean not logical neither easy to remember.

would it really be a pain to support the usual 0xff format?... it 
doesn't really clash w anything i think. only numbers can start w 
zero anyway...

just use a binary string.

the issues is sort of a syntax sugar, the binary string is the actual 
value in ram.   so you can do things like:

a: #{0f0f0f0f}
b: 3520188881     
>> a and b
== #{01010101}

but you can't with issues:

>> b: #d1d1d1d1
== #d1d1d1d1
>> a and b

** Script error: and does not allow issue! for its value2 argument

the only  real thing to be aware of is that to-binary of an integer 
will give you a 64 bit binary!

>> to-binary 22
== #{0000000000000016}

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

Question: how many REBOL users prefer:

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == a/b

versus

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == "OK"

?

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!

versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

The latters seems ok to me. But what if w is a word holding 'b or 
'a/b, as I was testing, in relation to the object a? This is what 
I get:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script Error: Invalid path value: b	; To me, that error is wrong 
worded, it should show 'b.
>> in a :w
== 'b		; Confused, as a doesn't hold any 'b
>> do in a :w
== 'b		; Why?
>> type? do in a :w
== lit-word!

Same in R3:
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script error: cannot access :w in path a/:w		; Not sure about 
this error. Could be better, I think.
>> in a :w
== 'b			; ?
>> do in a :w
== b			; ??
>> type? do in a :w
== word!

And now the 'a/b:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== "OK"
>> do :w
== 'a/b

In R3:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== 'a/b
>> do :w
== 'a/b

wrt:

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!
versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

============================

the first should be supported via the 'GET word, so I'd say the later 
is better, otherwise, there is no point with 'GET. 

basically, this was perfect in R2, why did it change in R3?

seems like a bug

It changed because functions were getting executed when you were 
doing a word referring to a function, rather than doing the function 
itself.

Ladislav, that ticket was related because it explained that lit-words 
were active values and that the behavior was intentional. This can 
be changed if we decide differently, but it isn't currently a bug, 
it's intentional.

And no wonder they do. If a user calls the DO function, then it is 
expectable that functions, etc. get evaluated.

Yes. But that is doing the *function*, not doing a word that refers 
to the function.

It's the difference between a: :print and a: 'print.

As said, all the respondents above prefer the function to be evaluated 
when doing a word that refers to the function. The only way how you 
can influence it would be if you said you preferred the current behaviour 
as implemented in R3. Do you?

Regarding the example evaluating words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatypeRegarding the example evaluating 
words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype lit-path: first ['a/b]
    do [lype? lit-path]

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

I prefer lit-path!. The same for lit-words:

	lit-word: first ['a]
	do [type? lit-word]


I prefer that to return lit-word!. It's only, if the word being looked 
up (lit-word in this example) is a function (or native, op, action, 
...) that further computation should occur, I think.

Actually I ran into problems related to this, when programming the 
bparse function. At one point, I need to test, if a token variable 
is equal to the word END. To specify the word END, I write it as 
a lit-word, because lit-words are changed to words on the run. I 
need to use == to compare, because I want the type to be the same 
too. So I would expect, this is the correct test:

	token == 'end

Let's test:

>> token: first [end]
== end
>> token == 'end
== true

Seems to work, but then the surprise, if token is a lit-word:

>> token: first ['end]
== 'end
>> token == 'end      
== true

Also true? Hmm, so I have to write:

>> :token == 'end
== false

In #1881 you are proposing to take what in R3 is currently an active 
value and render it inactive, which will make it mildly safer to 
handle - lit-word/lit-path conversion to word/path is a trivial thing. 
In #1882 you are proposing to make the word! type into an active 
value, where you would have to treat every word value as carefully 
as you treat the function it is assigned. Except it's worse, because 
in R2 it has the effect of doing *blocks* as well, if those blocks 
are assigned to a word - even DO of an inline word isn't that unsafe. 
It is really bad.

I noticed when you did the poll, you used a safe function that you 
knew the source of. Do the poll again with a function that deletes 
your hard drive, or even a block of code for some other dialect that 
will coincidentally do damage when interpreted by the DO dialect 
(since R2 does this with blocks and parens as well). Or even a function 
that takes an unknown number of parameters, and put the call in the 
middle of code that might be affected by evaluation order or get-word 
hacking.

Most of you might not remember this, but parens used to be treated 
as active values in R2. If you had a paren assigned to a word, putting 
that word inline in a DO dialect block would cause the paren to be 
executed. I used to use this as a way of having quick thunks (functions 
that take no parameters) without calling DO explicitly. However, 
this made it difficult to work with paren values, and was eventually 
removed for security reasons because it made screening for potentially 
dangerous values more difficult than a simple ANY-FUNCTION? call. 
It would be bad to make word! and path! values just as difficult 
to work with.

Btw, this comment in #1882: "and since you've requested that lit-word! 
and lit-path! be returned to their R2-style inconsistency" may not 
be an accurate representation of your proposal (here earlier in conversation). 
You might be proposing that R3 do a better job at being inconsistent 
than R2 is doing (as demonstrated in #1434). If so, cool.

>> o: make object! [f: does [42]]

>> do in o 'f		; This is a problem, as nothing seems to be happening!
>> o/f
== 42

I'm not sure, I understand the security concern.

Pretending that security doesn't matter is a worse policy. Here is 
what would resolve the security issue:

- Putting warnings in the docs for DO, in the same section where 
they talk about the special treatment of functions and blocks.

- Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

- Make sute that we don't try to make set-words and set-paths do 
assignment when you DO them. Treat them like get-words and get-paths.


Together, those restrictions would make DO of word and path values 
no more insecure than DO of block and paren values. For functions, 
we have APPLY.

DO of block and paren values is something that we can say is secure 
enough already, assuming that variables and such are protected and 
secured, so that is a good set of restrictions to follow for words 
and paths. Calling functions through inline words is secure enough 
if you can control the binding and writeablility of those words. 
DO of function values has the argument problem, but it's known and 
has built-in workarounds (APPLY, putting function calls in parens), 
and we already have simple ways to screen for them.

DO is seductive, because sometimes I want to create (easily) a "dialect 
environment" and just use DO to evaluate my dialect., safely and 
securely. 


Is there a security page in the docs (I don't see one in the R3 docs 
right now)? If not, that would be good to have. If we have a list 
of functions and operations you shouldn't use on untrusted data, 
and what the risks are, that's a good start.

There isn't much of a security page right now, though it would be 
a good idea to make one if only to document the stuff that doesn't 
currently work (like SECURE in the last 4 versions). I don't know 
if anyone else has made a concerted effort to attack REBOL and then 
fix the security problems found.

I would love it if we as a community were to really think through 
the (UN)PROTECT model, because the current model is incomplete (even 
for the stuff that works) and the proposed model is starting to look 
a bit awkward to use. Keep in mind that PROTECT may also be used 
to make series sharable among tasks, but that this isn't implemented 
and there is likely a better way to do this. I would love it if there 
was a good security model that can integrate well with REBOL semantics.

Won't work within a process, only on a process boundary.

It's inherent in the semantics of REBOL, a side effect of the code-vs-data 
thing.

(I am trying to write a long *starting* message here and have to 
put it in the clipboard to answer these questions, sorry.)

Some factors to consider about the REBOL semantic limitations:


- There is no such thing as trusted-vs-untrusted code in a REBOL 
process, nor can there be, really. Levels of trust need to be on 
a process boundary. You can't (even hypothetically) do LOAD/secure 
level or DO/secure level, but you can do LAUNCH/secure level.


- If you want to make something readable or writeable to only certain 
code within a process, binding visibility tricks are the only way 
to do it. The only way to ensure that your code has access to something 
and other code doesn't is to make sure that other code can't even 
see yours. This is why BODY-OF function returns an unbound copy of 
the body in R3, not the original.


- We need a way to make protection stick so you can't unprotect things 
that are protected, or protect things that need to stay unprotected, 
but still allow changes to the protection status of other stuff. 
The currently proposed model does this through a chain of PROTECT 
and UNPROTECT calls, then a PROTECT/lock, not allowing unlocking 
if there is a SECURE 'protect. However, the proposed model seems 
too difficult to use, and as the pre-110 module system demonstrated, 
people won't use something that is too complex to use, or will use 
it badly. We need a better way of specifying this stuff.

Trying to hammer every hole shut with SECURE and PROTECT is the classic 
method of sticking all your fingers in the dike. When you run out 
of fingers for all the holes, the water comes gushing in. Capabilities 
are about making it impossible to get through the next dike. It's 
a different way of compartmentalising

Now, for your questions, Kaj.


Mezzanines execute arbitrary code with DO. You can't even know if 
something is code or not until you pass it to a dialect interpreter 
like DO or PARSE - code is data. Blocks don't have bindings, only 
their any-word contents do, so the code blocks of functions are not 
bound to functions, only their contents are. The same goes for functions 
in modules or objects - they aren't bound to their objects or modules, 
only referenced by them.


(making this up on the fly) It could be possible to make the binding 
visibility of words be defined as a set of capability tokens as part 
of the object spec (in the SPEC-OF sense), and have the function 
spec dialect be extended to contain such tokens. This would have 
to be checked with every word access, and we would have to be careful 
to make the model in such a way to avoid unauthorized privilege escalation. 
Then changes in capabilities would happen on the function call stack, 
which is task-specific.


The problem with this is making sure code can't make functions with 
more capabilities than the code making them currently possesses. 
Though R3 doesn't really have a user model, it does have a task model 
and we could make the capability level task-specific. Code could 
constrain capabilities for code it calls, but we don't want privilege 
escalation at function creation time. It would be possible to have 
privilege escalation at function call time if the function called 
was created by something with the necessary capabilities.

Drawbacks:

- If we do this for binding visibility, this means a capabilities 
check would go into every word access. Word access would be SLOW.

- This doesn't add anything to the PROTECT/hide model, which handles 
binding visibility without the slowdown.


Capabilities would be like the SECURE model, but more flexible, so 
that's something to consider there. What SECURE protects is heavy 
enough that a capabilities check wouldn't add much to the overhead.

Of the 3, SECURE seems like the most likely to be enhanceable with 
capabilities. Functions could be enhanced by capabilities specs, 
where the function code could only create other functions of equal 
to or lesser capabilities than are currently available in the call 
stack. Once a function is created, it could run code with the capabilities 
that it was created with (with the exception of that function creation 
limitation earlier). There could be a function like DO that reduces 
capabilities and then does a block of code, and maybe MAKE module! 
could be made to use that function based on capabilities in the module 
spec.

Since MAKE object! isn't a hybrid function like MAKE module! (which 
calls sys/make-module*), we probably don't want to reduce capabilities 
on a per-object basis.

It seems to me that you are still talking in terms of plugging all 
the holes in the myriad of capability that would supposedly be around. 
This is not how true capabilities work. They implement POLA: there 
is no capability unless it is needed, and in that case, it needs 
to be handed down as a token by the assigner of the work. If the 
boss doesn't have the token, the employee will by definition not 
be able to do the work

REBOL is a virtual machine with strong typing (as long as extensions 
are protected well enough). You have complete control over the world 
the code executes in, so the potential is there to make the process/thread 
separation irrelevant for security

Which can all be done in a capabilities model

If you use capability tokens to protect binding visibility, then 
every word access would need to check against a capability token.

OK, let's work this through for only PROTECT/hide to see how the 
concept would affect things. PROTECT/hide works by making it so you 
can't make new bindings to a word - that way words that are already 
bound can be accessed without extra overhead. Adding capabilities 
to this means that you could create new bindings to the word if you 
had the token, but not if you didn't. However, with PROTECT/hide 
(currently) the already bound words don't get unbound when they are 
hidden, just new bindings to that word, and if you have access to 
such a prebound word value then you can make new words with that 
binding using TO, which effectively makes prebound words into their 
own capability tokens. So PROTECT/hide *as it is now* could be the 
basis of a capability system.

The problem that a capability system has of making sure capability 
tokens don't leak is pretty comparable to the problem with leaking 
bindings that we already have to take into account with the PROTECT/hide 
model, so switching to a capability system for that model gains us 
nothing that we don't have already. And we've already solved many 
leaking binding problems by doing things like having BODY-OF function 
returning an unbound copy of its code block rather than the original. 
The PROTECT/hide model works pretty well for that, so it's just a 
matter of closing any remaining holes and making sure things are 
stable.

The fundamental gain is that you switch to a POLA model from the 
current model where all code in a REBOL process has all capabilities 
unless you manage to stop some of them

No, but all code created after the word is hidden doesn't get access, 
and only code created before the hiding has access to a token (bound 
word) that will let it create new code with access. You get the same 
sharp separation between code with access and code without.

A POLA model is where you start out with no access. If you have to 
PROTECT/HIDE afterwards, that's the reverse of POLA

Yes, the reverse of POLA. Capabilities is about building a POLA system

Again, did you study true capabilities, especially in the E language, 
but also in Genode and the ground-breaking KeyKos and EROS systems? 
If you didn't, I can understand why we don't understand each other. 
By the way, POLA is not a capabilities term, but a generic security 
term

I got the overview, but there are some limitations when talking about 
a language like REBOL.

OK, the problem with that model *in this case* (PROTECT/hide) is 
that we are talking about object fields here, bindings of word values. 
REBOL objects bind their code blocks before executing them. If there 
is going to be any blocking of bindings, at least the object's own 
code needs to be bound first. This means that if you are going to 
make word bindings hidden, you need to do so after the object itself 
has been made, or at least after its code block has been bound. You 
can do this binding with PROTECT/hide, or with some setting in an 
object header, it doesn't matter. Since words are values and their 
bindings are static, being able to create a new word with the same 
binding means that you need access to a word with that binding, with 
*exactly* the same visibility issues as token access. The difference 
in this case between POLA and PROTECT/hide is whether object fields 
are hidden by default or not, not a matter of when they are hidden.

It's a VM, so you still have control over them

For E, these capabilities can basically be resolved statically in 
a lot of cases by the compiler. For REBOL, every capabilities check 
would need to happen at runtime.

Certainly. It's been a favourite topic of mine for a decade :-)

Once the capability to reference an object or send a message has 
been granted, no further run-time check is required.

I hadn't checked E for a long time, but they are now implementing 
capabilities in JavaScript for Google, so we're going to hear from 
it whether we want or not:

I guess this is another one of those things where REBOL has the choice 
between being ahead or staying behind a lost opportunity

Pretending that security doesn't matter is a worse policy.

 - for me, security does matter, but this just pretends to be security

Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

 - this is exactly a complicated way how to pretend something is more 
 secure than it actually is. The only real effect is obtaining a less 
 comfortable and more annoying system

As for the

    a: quote (1 + 2)
    a ; == (1+ 2)


, that is not a "security measure". It is just a more comfortable 
behaviour.

On the other hand, I would never propose

    do a


to yield anything other than 3, pretending it might be perceived 
as "more secure".

Regarding APPLY- I was the one who implemented the first APPLY in 
REBOL, and I was the first who used it to obtain a more secure evaluation 
than using DO

Agreed about this from your example above:
>> a: quote (1 + 2)  do a
== 3
But what I was proposing above was this:
>> do 'a
== (1 + 2)
Would that be acceptable to you?

pretend something is more secure than it actually is

 - the biggest security concern of R3 is making sure that outside 
 code can't modify the code of functions.


There are various tricks that can be done in order to make sure that 
doesn't happen (putting calls to function values in parens, APPLY, 
SECURE 'debug). DO of blocks and parens don't need the APPLY or DO 
in a paren tricks in order to make sure they can't modify the calling 
code because they can't take parameters, so you can DO blocks and 
parens without changes to your source code - SECURE 'debug doesn't 
require changes to source code. This means that less effort is needed 
to make DO of blocks or parens more secure than DO of functions that 
can take parameters. The same goes for DO of any non-function type.


If you constrain DO of paths or words with functions assigned to 
them to not be able to take parameters, then they would be exactly 
as secure as DO of blocks or parens, and can be called with the same 
code - no additional code wrappers or screening would be needed. 
This would make DO of words or paths a drop in substitute for DO 
of blocks or parens.

Well, it looks, that

    do 'a ; == (1 + 2)

may be more convenient

It is interesting, that for the case:

    lit-word: first ['a]
    do [type? lit-word]

we have only two opinions

I'm more concerned with people trying to sneak functions into data, 
which could then use parameters to get access to the original code 
of another function. This can be used for code injection, or for 
getting access to bound words that have since been hidden, or to 
internal contexts. Given that words are often valid data, having 
a special case where they can execute functions by sneaking in a 
bound word is a real concern. However, if that function can't take 
parameters, there is no hacking potential and function code can be 
secure. The workaround if you don't want any functions executed (beyond 
the hacking) could be to unbind words retrieved from data, bind them 
to a known context, or just avoid using DO word or path altogether.

As for #1434 (and your most recent code example), I would prefer 
to have lit-words and lit-paths be consistently active values (the 
way lit-words are in R3 now) for the same reasons you proposed #1881 
and #1882. This means having them convert to word and path when they 
are evaluated instead of just gotten. But if you would prefer them 
to be a special case like parens (the way lit-paths are in R3 now), 
that would work for me too as long as that is the case for both lit-words 
and lit-paths - it would make them a little easier to work with.

If lit-words are turned into a special case, being otherwise inactive 
(like lit-paths are now), that would work for me. Though normally 
we would want lit-words to be converted to words, if the #1882 change 
to word evaluation goes through, that would mean that lit-words could 
change to words which could execute functions. If that kind of thing 
could happen, I would rather it happen through explicit conversions 
so you can see it in the code.

I just asked whether a note about "incosistency" contained in there 
was appropriate

I guess I had trouble parsing this sentence:

I do *not* propose the result of 

do quote 'a 

to be a lit-word, 
since the word really looks reasonable to me.


That seemed to be a preference for lit-words converting to words 
in that case, though I may have misinterpreted that.

in my opinion, the behaviour of

    do quote 'a

expression is something else than the behaviour of the

    lit-word: first ['a]
    do [type? lit-word]

example

Whether or not there is going to be a difference between inline evaluation 
of lit-words and evaluation of lit-word values, evaluation of lit-word 
values needs to be consistent whether you do so by referring to them 
with an inline word, or through explicit DO. R2's behavior is a bug.

I intendedly coined the terms

active value

 to refer to a value that when encountered inline in a block does 
 not evaluate to itself
word-active value
 to refer to how a word is evaluated when referring to a value

OK. There is stuff like functions, and these are called "active values" 
- they behave consistently for inline, regular or explicit evaluation. 
There is stuff like parens, which behave one way for inline, and 
a different way for regular or explicit evaluation - what term would 
you like to use to refer to this pattern with? Because those are 
the only two choices that would make sense with lit-words and lit-paths.

Then please say so in a comment to #1434, so we can have a consensus 
recorded :)

The proposed model is something like this:
>> 'a/1 
== a/1 ; inline evaluation of lit-path converts to path 
>> b: quote 'a/1 
== 'a/1 
>> b 

== 'a/1 ; regular evaluation of lit-path value does not convert to 
path 
>> do :b 

== 'a/1 ; explicit evaluation of lit-path value does not convert 
to path


So it's not exactly like parens, but it's what Maxim, Geomol and 
I would prefer.

Your terminology:

inline evaluation
regular evaluation
and
explicit evaluation


is acceptable for me (although I am not sure about the "regular evaluation", 
isn't there a chance to find a better notion?)

(there is a level of idirection, since an evaluated word refers to 
a value)

Sure. The reason I called it "regular" is because a word! has no 
markings, either in terms of characters added to the syntax, or qualifiers 
added to the type name. This implies that word! evaluation is the 
default, or the regular style, while the others are exceptional.

:a evaluation is inline too, so "inline indirect evaluation" could 
apply to that.

Are you OK with this, Ladislav?
>> 'a/1 
== a/1 
>> b: quote 'a/1  b 
== 'a/1 
>> do quote 'a/1 
== 'a/1

Or do you require this?
>> do quote 'a/1 
== a/1

OK, nevermind. I prefer

    do quote 'a/1

to yield

    == a/1

to be honest

, i.e. I see a greater difference between direct and indirect evaluation, 
than between inline and explicit evaluation.

Then you can put your preferred behavior model (with that i.e. justification) 
in your comment, and we can get a consensus there through people 
agreeing with you. This would be the code:

>> 'a
== a
>> b: quote 'a  b
== 'a 
>> do quote 'a
== a
>> 'a/1
== a/1 
>> b: quote 'a/1  b
== 'a/1 
>> do quote 'a/1
== a/1

one more question (I guess, that a kind of glossary may be of use). 
How about replacing the "explicit evaluation" by "immediate evaluation" 
to contrast it more with the "inline evaluation"?

I like the current behavior of set-words:
>> a: 1 do quote a: 2 a
** Script error: invalid argument: a:
But the behavior of set-paths leaves a bit to be desired:
>> a: [1] do quote a/1: 2 a
== [1]  ; no error triggered, just a noop.

I'll write up a bug ticket about that.

I figured out a new way to express the equivalence that can safely 
be used for word! (http://issue.cc/r3/1882), path! (http://issue.cc/r3/1881), 
lit-word! and lit-path! (http://issue.cc/r3/1434), set-word! and 
set-path! (http://issue.cc/r3/1883), and get-word! and get-path! 
(current behavior), that matches the behavior of paren!. This code 
should work in all cases.

use [a b] [
    a: func [] ["blah"]

    foreach t compose [(paren!) (to-block any-word!) (to-block any-path!)] 
    [

        assert [any [all [error? try reduce [to t 'a] error? try [do to t 
        'a]] same? do reduce [to t 'a] do to t 'a]]
        assert [b: to t 'a strict-equal? to t 'a b]
    ]
]


Basically, the equivalence of an individual type would be this (using 
word! as an example):
    same? do [a] do 'a
    b: 'a same? 'a b


The important part of the equivalence would be that DO value would 
be equivalent to DO reduce [:value], that it be equivalent to evaluating 
that value inline *in a block all by itself*. That would deal with 
the parameter problem, with making sure that set-words and set-paths 
trigger errors properly, it even would work with refinements and 
issues.

The only thing that it isn't equivalent for is unset words of the 
word! type or as the first element of a path! - inline evaluation 
triggers an error, explicit DO just returns unset.

No, I just didn't include them in that list. It's a special case.