AltME groups: search

Voilà... I renamed my script as parse-expression.r and it is on rebol.org 
... http://www.rebol.org/script-information.r?script-name=parse-expression.r

I just had to repace 5 'append into 'insert, so it fixing this big 
did not brak the "philosophy" of the implementation. Ouf :)

Example:
>> do parse-expression "-(-3+2)+3-2+3-sqrt((1+2)**2)-2**3+34"
== 28.0

i would rather use a separate word as a modifier then. makes things 
a lot simpler. maybe i would do a pre-processing 1st to break up 
these words into separate ones

first of all, your before after parse rule has nothing to do with 
the to/thru handling.


yes, this second rule shows an actual bug... "" and none rules are 
conceptually equivalent.

to/thru are not matching rules, they are skipping rules.  matching 
rules always return *past* the match. not *at* the match, like to 
will do.

well... to/thru are listed alongside  skip under "skipping input" 
in both r2 and r3 docs...  they cannot use sub rules, since they 
only do a find on the input.

to/thru do not match subrules... they only do a find.

to/thru do not match subrules

 - yes, that is a correct observation, although unrelated to the subject 
 of the discussion, and, actually, just a detail of the implementation, 
 that can easily change at any time, especially taking into account 
 the user preferences

Argh, I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?
:-)
Old def. of thru: advance input thru a value or datatype

New def. of thru: scan forward in input for matching rules, advance 
input to tail of the match


Then it can be argued, the tail of end (of a series) is still the 
end. Or it can be argued, that thru always advance some way further 
(as in all cases except at end). I understand, why [thru end] not 
failing is confusing.

(And stop saying, I should read the doc. I have read it ... in full 
this time.) ;-)

Interesting, so, you do not know where the cursor is after matching 
the [end] rule?

I assume, I know it, when it comes to parse in R2. I'm not sure with 
R3, as I don't have much experience with that.

Found a trick to parse integers in blocks. Let's say, I want to parse 
this block: [year 2011]

The rule can't be ['year 2011], because 2011 in this case is a counter 
for number of next element (none here). So normally, I would do something 
like ['year set y integer! ( ... )] and checking the y variable and 
create a fail rule, in case it's not 2011. But this is the trick:

>> parse [year 2011] ['year 1 1 2011]
== true


Two numbers mean repeat the next pattern a number of times, and in 
this case, the pattern can be an integer itself.

I think that there is no direct equivalent in R3 to R2's TO/THRU 
inline block. R3's TO/THRU inline block treats the block as its sub-dialect 
for TO/THRU multi, and that doesn't allow complex values or more 
than one value in a single alternate. The direct R3 equivalent of 
what you are requesting would be this, but it doesn't work:

>> parse [a b c [d e f] g h i] [to [[d e f]] mark: (probe mark) to 
end]
** Script error: PARSE - invalid rule or usage of rule: [d e f]

Instead you have to do a trick with to block! in a loop and then 
match the block to quote [d e f] explicitly, keeping looking if it 
doesn't match. It's annoying.

I would be happy to use a function! version of PARSE since i never 
had to do time critical parsing.

I do not think it makes any sense to trigger an error.

That is not the error I was talking about. This is the error:
>> parse [a b] [set w ['a 'b]]
== true
>> ? w                      
W is a word of value: a


It is the attempt to set the value to a complex rule that is the 
error. It wouldn't be an error to do this: parse [a b] [set w 'a 
'b]

If we keep the current behavior, there needs to be a lot of strongly 
worded warnings about the potential gotcha in the PARSE SET docs.

It could be considered a useful feature, since the whole match needs 
to match before the SET is performed. However, the docs need to be 
*extremely* precise about this because the "set the value to a rule" 
interpretation is a common misconception among newbie PARSE writers. 
It would be good for the docs to give an example of the type of code 
this allows you to do, explaining the difference.

But we have COPY to do, what you want, if I understand:

>> address!: [string! tuple! issue!]           
== [string! tuple! issue!]
>> parse ["cat" 1.2.3 #4] [copy addr1 address!]
== true
>> addr1
== ["cat" 1.2.3 #4]

Ok, version 1.0.0 of BPARSE is found here:

http://www.fys.ku.dk/~niclasen/rebol/libs/bparse.r


It's a function version of PARSE, and can only parse blocks for now, 
not strings. It can do more or less all PARSE in R2 can do when parsing 
blocks. I've tried to trigger errors, R2 PARSE doesn't. The purpose 
is to play around with parsing to maybe make a better version than 
the native version and without bugs.

I've thought some more about [thru end], which return false in the 
R2 version, but return true in R3. My version return false as R2, 
but I better understand the R3 way, now I've programmed it. It can 
be seen as, how THRU should be understood (, as also Ladislav said 
something about)? Do we think of

[thru rule]
as
[to rule rule] or
[to rule skip]

? If the TO keyword can handle complex rules like:
parse [a b] [to ['a 'b] ['a 'b]]

then the first might make better sense, and [thru end] should return 
true. But we can't parse like that in R2, so maybe we think more 
of it as the second, and then [thru end] should return false. But 
if you look in my version, I have to catch this special case, where 
END follows THRU, so it takes more code, which isn't good.


In any case, Ladislav's suggestion to use [end skip] as a fail rule 
is much better. If you're not at the end, the first word (end) will 
give false, else the next will fail, as you can't skip past end.

BTW (looks a unlucky to me), do you know, that in REBOL the NONE 
rule can fail?

[any end]Êand [some end]

As we don't have warnings, I suggest these to produce errors. They 
can produce endless loops, and that should be pointed out in the 
docs, if they don't produce errors.
[opt end]

Yes, it's legit, but what's the point of this combination? At best, 
the programmer knows, what she does, and the combination will do 
nothing else than slowing the program down. At worst, the programmer 
misinterpret this combination, and since it doesn't produce an error 
or anything, it's a source of confusion. I suggest to make it produce 
an error.
[into end]
Produces an error today, so fine.
[set end ...] and [copy end ...]

I wasn't thinking of [set var end], but about setting a var named 
end to something, like [set end integer!]. Problem with this is, 
that now the var, end, can be used and looks exactly like the keyword, 
end, maybe leading to confusion. But after a second thought, maybe 
this being allowed is ok.
[thru end]

Making this produce an error will solve the problem with the confusion 
around, what this combination mean. And in the first place, it's 
a bad way to produce a 'fail' rule (in R2, in R3 it has the value 
true, and parsing continues). It's slow compared to e.g. [end skip].

If you're going to make a better parse, it might be good to take 
into account the efforts that have already started to improve it 
in R3. The R3 improvements need a little work in some cases, but 
the thought that went into the process is quite valuable.


[set end ...] or [copy end ...]: In R3, using any PARSE keyword (not 
just 'end) in a rule for other reasons triggers an error.
>> parse [a] [set end skip]
** Script error: PARSE - command cannot be used as variable: end

[any end] or [some end]: What Ladislav said.


[opt end]: The point of the combination is [opt [end (do something)]]. 
[opt anything] is no more useless than [opt end]. Don't exclude something 
that has no effect just for that reason. Remember, [none] has no 
effect as well, but it's still valuable for making rules more readable.

its because I do  A LOT more parsing on strings than on blocks.... 
one of the reasons is that Carl won't allow us to ignore commas in 
string data.  so the vast majority of data which could be read directly 
by rebol is incompatible.   


this is still one of my pet peeves in rebol.  trying to be pure, 
sometimes, just isn't usefull in real life.   PARSE is about managing 
external data, I hate the fact that PARSE isn't trying to be friendly 
with the vast majority of data out there.

Do you mean, you want to be able to parse like this?

>> parse [hello, world!] [2 word!]

Thanks Ladislav and Geomol.

Both your solutions work with my test data -- that's always a good 
sign :)


I'll do some timing tests with large entity lists ..... But I won't 
be able to do that for 24 hours.

Other approaches still welcome!

'The "skip-it" technique could also be applied to Ladislav's code.' 
- I do not think so

OK, so, do you think I should put the CASE proposal (mentioning your 
variant) to the article?

I want to keep the digits and remove all the rest,

t: "abc56xyz" parse/all t [some [digit (prin "d") | x: (prin "." 
remove x)]] print head t

this do the work but never finish. If I add a "skip" to the second 
part the result is "b56y".
How do I do?

Nice way, thank you. But still curios about how to do it with parse.

Doc: Thank you. I tried to do that way (advancing the series position) 
but couldn't. I may add some more things so I wish to do it by parse 
instead of other ways. And want to learn parse more :)
Thanks for all!

Here's the R2 version of TO-CSV and TO-ISO-DATE (Excel compatible):

to-iso-date: funct/with [
	"Convert a date to ISO format (Excel-compatible subset)"
	date [date!] /utc "Convert zoned time to UTC time"
] [

 if utc [date: date + date/zone date/zone: none] ; Excel doesn't support 
 the Z suffix
	either date/time [ajoin [

  p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2 " "  ; or T

  p0 date/hour 2 ":" p0 date/minute 2 ":" p0 date/second 2  ; or offsets
	]] [ajoin [
		p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2
	]]
] [
	p0: func [what len] [ ; Function to left-pad a value with 0
		head insert/dup what: form :what "0" len - length? what
	]
]

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	[catch]
	data [block!] "Block of values"
] [
	output: make block! 2 * length? data
	unless empty? data [append output format-field first+ data]

 foreach x data [append append output "," format-field get/any 'x]
	to-string output
] [
	format-field: func [x [any-type!]] [case [
		none? get/any 'x [""]

  any-string? get/any 'x [ajoin [{"} replace/all copy x {"} {""} {"}]]
		get/any 'x = #"^"" [{""""}]
		char? get/any 'x [ajoin [{"} x {"}]]
		scalar? get/any 'x [form x]
		date? get/any 'x [to-iso-date x]

  any [any-word? get/any 'x any-path? get/any 'x binary? get/any 'x] 
  [
			ajoin [{"} replace/all to-string :x {"} {""} {"}]
		]
		'else [throw-error 'script 'invalid-arg get/any 'x]
	]]
]


There is likely a faster way to do these. I have R3 variants of these 
too.

Here's a version that works in R3, tested against your example code:
>> a: deline read clipboard://
== {a,      b ,"c","d1
d2",a ""quote"",",",}

>> use [x] [collect [parse/all a [some [[{"} copy x [to {"} any [{""} 
to {"}]] {"} (keep replace/all x {""} {"}) | copy x [to "," | to 
end] (keep x)] ["," | end]]]]]
== ["a" "      b " "c" "d1^/d2" {a ""quote""} "," ""]


But it didn't work in R2, leading to an endless loop. So here's the 
version refactored for R2 that also works in R3

>> use [value x] [collect [value: [{"} copy x [to {"} any [{""} to 
{"}]] {"} (keep replace/all any [x ""] {""} {"}) | copy x [to "," 
| to end] (keep any [x ""])] parse/all a [value any ["," value]]]]
== ["a" "      b " "c" "d1^/d2" {a ""quote""} "," ""]


Note that if you get the b like "b" then it isn't CSV compatible, 
nor is it if you escape the {""} in values that aren't themselves 
escaped by quotes. However, you aren't supposed to allow newlines 
in values that aren't surrounded by quotes, so you can't do READ/lines 
and parse line by line, you have to parse the whole file.

I'm putting LOAD-CSV in the %rebol.r of my dbtools, treating it like 
a mezzanine. That's why I need R2 and R3 versions, because they use 
the same %rebol.r with mostly the same functions. My version is a 
little more forgiving than the RFC above, allowing quotes to appear 
in non-quoted values. I'm making sure that it is exactly as forgiving 
on load as Excel, Access and SQL Server, resulting in exactly the 
same data, spaces and all, because my REBOL scripts at work are drop-in 
replacements for office automation processes. If anything, I don't 
want the loader to do value conversion because those other tools 
have been a bit too presumptuous about that, converting things to 
numbers that weren't meant to be. It's better to do the conversion 
explicitly, based on what you know is supposed to go in that column.

It doesn't do conversion from string (or even from binary with LOAD-CSV/binary). 
This doesn't have a /part option but that is a good idea, especially 
since you can't just READ/lines a CSV file because it treats newlines 
differently depending on whether the value is in quotes or not. If 
you want to load incrementally (and can break up the lines yourself, 
for now) then LOAD-CSV supports the standard /into option.

can it be told to stop parsing after N lines instead? as far as I 
can tell from the source: (output: insert/only output line), it could 
do that.

Do you consider LOAD-CSV { " a " , " b " , " c " } yielding [[{ " 
a " } { " b " } { " c " }]] to be on spec? It says that spaces are 
part of a field's value, yet it states that fields may be enclosed 
in double quotes. I'd rather expected [[" a " " b " " c "]] as a 
result. The way it is, LOAD-CSV in such cases parses unescaped double 
quotes as part of the value, IMHO that's not conforming with the 
spec.

The values are only considered to be surrounded by quotes if those 
quotes are directly next to the commas; otherwise, the quotes are 
data. In the case you give above, according to the spec the quotes 
in the data should not be allowed - they are bad syntax. However, 
since the spec in the RFC doesn't define what to do in the case of 
data that doesn't match the spec, I decided to match the error fallback 
behavior of Excel, the most widely used CSV handler. Most of the 
other tools I've tried match the same behavior.

BrianH: one of my guys returned from some MS training, and he pointed 
me out to LogParser. It seems even some guys at MS are kind of dialecting 
:-) It looks like SQL, and you can query logs, and do some nice stuff 
around them ....

http://technet.microsoft.com/en-us/library/ee692659.aspx

dunno if it's faster but to left pad days and months, I add 100 to 
the value and then do a next, followed by a form ie. regarding you 
p0 function

I figure it might be worth it (for me at some point) to do some test 
exports in native format in order to reverse-engineer the format, 
then write some code to generate that format ourselves. I have to 
do a lot of work with SQL Server, so it seems inevitable that such 
a tool will be useful at some point, or at least the knowledge gained 
in the process of writing it.

Endo, I will try to find newest version and let you know. But do 
not expect it to translate every regular expession.

???
>>  my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> do my-code-a
== [x x]
>> a: []
== []
>> a
== []
>> head a
== []
>> do my-code-a
== [x x x]
>> a
== [x x x]


what is the logic behind this? How could a be empty after a: [] and 
be filled will three 'x after just one call to do my-code-a

It looks to me like everytime you call my-code-a, you assign the 
block defined in my-code-a to the variable a which is globally accessible. 
When you write a: [] outside my-code-a, you assigne another block 
to a... a is a pointer and you swith the adresse it is pointed to.

>> my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> a
== [x]
>> a: copy []
== []
>> append a 'y
== [y]
>> a
== [y]
>> do my-code-a
== [x x]
>> a
== [x x]

To explain it even futher, here is yet another example:

>> my-code-c: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'x
== [x]
>> my-code-c
== [a: [x]]

Ok, weird. I don't know if this is the case, but IMO the --cgi option 
should cause the output port to be in text mode and to convert ^/ 
to crlf, network standard. And then WRITE-IO should not do any conversions, 
and output in binary mode regardless of the text mode of the output 
port.

Perhaps something to do with the http-port-private: open/lines  part. 
If I could open/binary that would be better, no?

I am making a simple (I hope) worfkflow prototype and want to use 
REBOL objects which I can SAVE and LOAD.  A workflow object!  to 
have a node-map collection in it of simple nodes of the workflow 
graph.   Source ->A -> B -> SINK where the workflow knows about the 
next node and status. Externally there is UI to support the work 
part ... which is URL data on a given node.   Looks like it fits 
into Cheyenne RSP well - maybe zmq when I get a bit further along. 
  Save a flow in process as a .txt file using SAVE/ALL filename.txt 
work-flow-instance.   But no success with work-flow-instance: LOAD 
filename.txt        Do I have to BIND on LOAD to re-instantiate the 
object?

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

The chat interface uses numbers as a deliberate design choice because 
it is easier to memorize and refer to a number than it is to a path 
or message ID. You can even write a message number in #8008 form 
in another message and it can be followed like a hyperlink to the 
message of that number. You can also do the hyperlink trich to CureCode 
tickets using the bug#539 form, which will take you to http://issue.cc/r3/539
(that R3 bug I mentioned above).

I tested with R2...no problems here. Henrik, maybe it has something 
to do with the fact you are emulating the Windows under OSX?

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.

John, refinements that can't be translated to path use can be used 
for other reasons in other dialects. REBOL isn't just DO.

One of the tricks when refining the details is to realize that there 
is a real runtime difference between recommending that people not 
do something, and prohibiting something. Every time we prohibit something 
it has runtime overhead to enforce that prohibition. So every recommendation 
needs documenting and explaining, but every prohibition needs justifying. 
There are situational tradeoffs that recommendations can resolve 
easier than prohibitions. This is why we have to be extra careful 
about this.

If I in a function have a local variable, v, but I want the value 
of a variable v in the context outside the function, I can write:

get bind 'v bound? 'f


, where f is the name of the function. Is that the way to do it, 
or is there a better way? Full example:

>> v: 1
== 1
>> f: func [/local v] [v: 2 get bind 'v bound? 'f]      
>> f
== 1

Is that the way to do it
 - I guess not, there is a more efficient way

Tonight's Moment of REBOL Zen:

Check this Fibonacci function:

fib: func [
	n [integer!]
	(
		if not local [
			a: 0
			b: 1
		]
		prin [a b ""]
		loop n [
			prin [c: a + b ""]
			a: b
			b: c
		]
		print ""
	)
	/local a [integer!] b [integer!] c
][
	do bind third :fib 'a
]

>> fib 10
0 1 1 2 3 5 8 13 21 34 55 89 
== 89
>> fib/local 10 55 89 none
55 89 144 233 377 610 987 1597 2584 4181 6765 10946 
== 10946


If you only want to execute the paren in the function spec, put this 
in the body instead:

	do bind to block! third second load mold :fib 'a

Geomol, in R2 when you pass a word to a get-word parameter, the value 
assigned to that word is passed instead. There may have been a good 
reason for this initially, but in the long run it turned out to be 
a bad design choice, and was fixed in R3. It has nothing to do with 
the any-function! types.

There is a similar special case for when you pass a get-word value 
to a lit-word parameter, bot in R2 and R3. R2's APPLY function has 
code to undo these special cases, and R3's APPLY doesn't do the special 
evaluation; APPLY is used to break the evaluation rules, often for 
safety.

I want to download the page, and to do it from different ip

wow, i didn't know u can do that! where is it documented? i just 
remeber get-modes in relation to setting binary mode for the console 
or parity and speed setting for the serial port...

AFAIK, there is no way to do that using REBOL ports.

You can do more exact selections of what you want to copy in R3 using 
COPY/types.

From HELP MOD: "Compute a nonnegative remainder of A divided by B."
MOD can produce negative results as seen above.

From HELP MODULO: "Wrapper for MOD that handles errors like REMAINDER."

So REMAINDER must give wrong result in some cases. What does REMAINDER 
say:

From HELP REMAINDER: "Returns the remainder of first value divided 
by second."

That's what I expect a modulo operation to do. A modern definition 
is given by Knuth in "The Art of Computer Programming" using floored 
division, and this seems to be also the definition, Wolfram Alpha 
use. So I would say, REMAINDER give the correct answer in the second 
case, but not in the first.


As I see it, REBOL have 3 modulo functions, and none of them operate 
as expected, if Knuth's definition is used.

In essence, the MOD function is a "helper" for ROUND. It uses the 
Boute's definition, but assuming that the divisor is positive. If 
you do want to use a more comfortable variant, you can use the MODULO 
function, which does not make such an assumption.

would you prefer...

 - in this case, my preferences don't matter, as it looks, although 
 I think that I suggested what they are. Cf. also above " you have 
 to make a really complex comparator function" - I do not think this 
 is desirable.

Everything can be easily transformed to the zero case. The argument 
of "zero is meaningless" promoters was, that it helps the computers 
(people, at those times) to "track down the places where their calculations 
do not make sense"

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

Regarding the "comparison is meaningless", or "SORT doesn't have 
that luxury though, because it is designed to not fail" philosophical 
arguments. They, in fact, are not valid at all. The facts are different.


* For large lists which are frequently searched it *is* useful to 
have them sorted. 

** The reason is, that it is much easier to perform searches in a 
sorted list, than in an unsorted list.

** The "meaning" of the sort order is to facilitate searches, no 
other meaning is needed. (it is like the zero case, the meaning of 
zero is to facilitate the positional representations of numbers, 
no other "meaning" is needed)

* The whole "sorted list business" needs comparison functions (for 
searching, etc.)


The above "meaning" is one meaning comparisons do have. It suffices 
to prove, that comparisons are not "meaningless". (for that it would 
be absolutely necessary, that we can find no meaning at all)

for example, it is quite common to do something like:

a: make object! [name: 'a]

no,  AFAICT the unary minus is applied exactly like all operator 
precedence (from left to right).


negate and  "-"  do not have the same precedence, as you noted, so 
its normal for:
    >> negate 2 + - 2    
and
    >> - 2 + - 2
to give different results.

Ladislav, do you mean "fixed parity"?


And yes, there seem to be just one minus '-' in R2. If you redefine 
- with something like:
	set '- ...
, then you don't have unary minus any longer.

'Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 

 - 'argument [any-type!]' - interesting, why do you think so, taking 
 into account, that the meaning of "an argument that is declared as 
 a lit-word" is pretty much standard in many contexts (programming 
 languages), not just in REBOL

The current state: 


- MOLD is used to display the result of REBOL expression to the console.
- I prefer MOLD/ALL to be used, since it would be less confusing
- do you mean, that you would prefer FORM?

I'll rephrase:


What I have a problem with, is that there are apparently degrees 
of serialization:


One that we call MOLD, but doesn't really work on all REBOL data. 
I very rarely use this alone.

One that we call MOLD/ALL, and works on nearly all REBOL data. I 
use this very often.


Then we have FORM, which should work on human readable output. The 
problem with FORM is that it isn't flexible enough. For example it 
should have been capable of reformatting numbers, such as 2E-3 to 
".002". It doesn't do that.

I maybe understand the reason to have things like #[none], #[true] 
and #[false] to specify those values, if someone choose to redefine 
none, true and false.

 - as far as I am concerned, you are missing the point, Geomol. My 
 thoughts:


1) there is a Data exchange dialect in REBOL, which is the main REBOL 
dialect (considering the fact, other REBOL dialects are derived from 
it).


A sidenote: the "Data exchange dialect" name may not be ideal. (this 
name is used in the http://en.wikipedia.org/wiki/REBOLarticle). 
Maybe, following the same "naming procedure" as for other dialects 
we could name it the "Load dialect"?


2) In the Data exchange dialect (or Load dialect, whichever you prefer), 
the

    none


expression is a word, and you do not have any means how to express 
the #[none] value, except for this specially escaped format, the 
same holds for #[true], #[false], #[unset!], etc.

Considering the fact, that any REBOL code is loaded first (in the 
computer, but your brain should follow a similar procedure when reading 
it), i.e. handled as the "Data exchange dialect"/"Load dialect" (pick 
the one you prefer) before being (eventually, but not necessarily) 
submitted to any other interpreting function (like DO, etc.), the 
specially escaped format is useful, since it increases the expressivity 
of the "Data exchange dialect"/"Load dialect" (pick your preferred 
one).

I do not need any parens to write:

>> true: #[true] false: #[false] mold/all true: not false: true
== "#[false]"

The Data exchange dialect (or the Load dialect) is incoplete in the 
following sense:


- natives etc. do have specially escaped representations (MOLD/ALL 
creates them), but such representations are not loadable

- MOLD/ALL creates loadable representations of REBOL objects and 
functions, but they are not guaranteed to preserve the properties 
of the orignal values

It's kinda interesting, how complexity sneak into a language like 
REBOL. I have never used constructs. I save REBOL data and code to 
disk all the time. I even created a file system/database, that is 
all about saving and loading data and code. I get along using a combination 
of simple REBOL functions like SAVE, LOAD, REDUCE and DO.

I understand, it can be argued, it's more simple to just use
	save/all ....
	load ...

than something like
	save ...
	do load ... or maybe ... reduce load ...


but trying to make this simple result in a much more complex language. 
(as I see it)

So, to constrain this, constructs are useful for values, you don't 
wanna do (because of security reason, if e.g. the data came over 
the network). Therefore there is no need to make constructs for natives, 
operators and functions?

What I usually use to differentiate these is that there are literal 
values which do not have to be interpreted (only parsed), and logical 
values which have no real meaning without this interpretation.

Serialization

 in the REBOL sense, hence the quotes,  is used to give the second 
 form of data a way to be described in the first, *where its possible* 
  which it isn't at all in the case of some types (native,etc) and 
 only partially in others (objects!, functions!, etc.)   


even with these distinctions there is still a sizeable amount of 
REBOL *data* (interpreter values, not human visible source code) 
which cannot be serialized (in the real sense) in any way because 
either:  

-the notation has simply not been defined for it (cyclic series/objects, 
which is serializable in other languages)

-it implicitely depends on its interpretation (a VID dialect block 
(you cannot save the vid from the faces)), custom types (in the future))

so the way I see it is that: 
-MOLD is the counterpart to DO
-MOLD/ALL is the counterpart to LOAD.

which leads to saying that:

only MOLD/DO can effectively represent all data,  (with the caveat 
that it is extremely insecure)

only MOLD/ALL can effectively represent literal data without interpretation 
(with the caveat that it is not complete)

BOTH , are highly complex to use effectively in non-trivial cases. 
  


IMHO, if it's notation where completed, the second form could actually 
be built to represent all data, since it could be built to include 
binding hints, series reference graphing and more.  It doesn't have 
to be pretty, it just has to be symmetric.

I think, that the point here is the Geomol's question:


I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.


The answer is quite simple, it is as with any data the Load dialect 
can represent:


- many data representable by the Load dialect aren't "really necessary"

-- other languages can usually represent less data types than the 
Load dialect can

-- the Load dialect did not have the escaped format from the start, 
and could do without it


- without the escaped format, the Load dialect cannot express values 
of the logic! type


- it is useful to be able to express values of the logic! type in 
the Load dialect
-- some languages have the advantage of being able to do that

-- it is confusing to use a word like true in the Load dialect, when 
meaning the logic value, since in the Load dialect true is a word, 
not a logic value (notice the example, where Geomol confused words 
and their values)

-- the expressibility of the logic! datatype in the Load dialect 
enhances the expressivity of the dialect, which is why it is useful 
to have it, similarly as for any other datatype expressible

-- the expressibility of the logic! datatype enhances the reflexivity 
of REBOL, since 

--- this way, the Load dialect can express values that would be otherwise 
inexpressible in it, while being used in the Do dialect

--- that means, that the Load dialect would not be usable to "speak 
about" logic values in a direct way

The only problem right now, is that the serialized form of the language 
is just not complete.

 - I would say, that "the Load dialect is not complete relative to 
 the Do dialect", being unable to express some values of the Do dialect.


Nevertheless, the question arises, whether the relative completeness 
is necessary. For example, you demonstrated how cyclic blocks could 
eventually be handled, but, I am not sure you do suggest your solution 
to be used, or just demonstrate the possibility.

Moreover, when I look at it, I have to say, that it actually would 
not be acceptable, since when you do want to mold e.g. your block 
3, you should obtain a representation of one block

I have a COPY/DEEP question:


When doing a COPY/DEEP, the first level requires that the argument 
must be a series!, port! or bitset! But when doing a /DEEP, I imagine 
that COPY traverses a series for elements and uses a different process 
than for the first level to determine whether the element can be 
copied. If it can't, it silently passes the value through.

Why can't we do that on the first level as well?

I do dislike having to do:

either series? var [copy/deep var][var]


thing. Generally the programming needed for absolutely deep copy 
a value is too elaborate.

I try to think of situations, where I would need to do that. I also 
don't think, I do it often. But it's an interesting idea. I try to 
come up with some situations, where I need to copy a value, that 
can sometimes be a series, sometimes not. Hmm...

English is probably too lenient. to say for sure :)
If you do a websearch for....
  "next back" button

....You'll see next and back are a common choice of names for navigating.

It looks like a side-efffect of the implementation, I do not think 
that this behavior was planned as a feature. I guess some recursive 
algorithms could benefit from it, but I fear it can quickly lead 
to code that is hard to maintain.

Yeah, I have a reasonable understanding of what a function and a 
closure is, and if I remember correctly, R2 functions are neither 
... or are a combination.


Back to the self-modifying code when making objects. Look at this:

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> o: make object! b
ok
>> ? b
B is a block of value: [print 'ok a: 1]


Since making the object doesn't change the block, do you still think, 
the above bug isn't a bug in REBOL?

Oh shame on me! I forgot to GET the values.. Thank you.

One more question, I use COPY on objects to be able to use same series! 
values in different objects, is that right?
I mean pointing to the same series inside different objects.

In R2 I do like that:
>> o: context [a: ""]
>> p: context [b: get in o 'a]
>> append p/b "*"
>> o/a
== "*"

I do have a situation where I need to safely and deeply copy an object, 
namely in the undo system, I am building for a program.

Now, before you suggest a fourth type of equal test, maybe you should 
reconsider your statement, that this is a simple part of the language?

 - Ah, so now you are saying that the problem is that REBOL's MOLD 
 function does not *show* the binding of words?


This has nothing to do with simplicity, rather, it has to do with 
being intuitive. make object! changing the binding of words inside 
your B block is not intuitive, i agree. Intuition is not very useful 
when programming; still, there are many programming languages that 
try to be intuitive. I think REBOL is the *least* intuitive, especially 
if you have learned something about programming already.

How do you know, it was intended?

 - because not copying the block passed to make object! is an intentional 
 "optimization". If you don't believe us, ask Carl. If it turns out 
 we are wrong, Carl will add the copy and you will be happy. :-)

Gabriele, if we continue with design flaws related to binding, the 
following is to me in that category:

>> blk: [x]
== [x]
>> x: 1
== 1
>> context [x: 2 append blk 'x]		; 1st alternative x

>> use [x] [x: 3 append blk 'x]		; 2nd alternative x just to show 
different ways to do this
== [x x x]
>> blk
== [x x x]
>> reduce blk
== [1 2 3]


I came to think of this from your comment on scope. To me, REBOL 
does have scope, it's just different from most languages. In REBOL, 
every word belong somewhere, and three times the same word in a block 
can belong to three different places. That's the scoping rules. Now 
I want to save and load that block:


>> save/all %/tmp/ex1.r blk	; using /all , even if it makes no difference 
here, but this questions /all, doesn't it?
>> blk: load %/tmp/ex1.r
== [x x x
]
>> reduce blk
== [1 1 1]


So doing that changes everything. This design flaw (you may call 
it a "design feature") can be the cause of so much confusion and 
program failures, that I might even call it a "bug". ;)

Aha, so you do not want to suggest any LOAD/MOLD changes, you want 
to have C

In your last example here, blk is created outside the context block. 
What I suggest is, that when you append x to blk, it doesn't matter, 
where you do that. The block defines the binding. So reducing blk 
in your example should give [1 1], and reduce load mold blk should 
also give [1 1]. Appending words to a block should mean that: appending 
words.

BIND modifying the block is a useful feature at times. For example, 
the copy that has been added "for security reasons" in many places 
makes a number of "tricks" harder to do.

Gabriele, it hard to have a conversation, when you go to extremes 
like in the following:


I don't understand where the complication is. Should writing a: [...] 
also do a copy? Should everything do a copy? You're arguing that 
sometimes REBOL should copy things, sometimes not. *That* is a list 
of complicated rules.


Do REBOL copy things sometimes today? Like in function definitions:

make function! spec body


Maybe REBOL should copy in the example, we discuss, maybe it's a 
bad idea. The complication (for me and most likely others) in the 
above example is, when I read it, I would expect some output from 
my intuition. The actual output is different, and it's really hard 
to see, why that output is intentional.

It works for now with sql/direct (which I normally use anyway). I 
noticed error when I needed to do this:
SQL [ "select datetime("now", ?)" "-3 hour" ]

I haven't tried [ "-3:00:00 ]