World: r3wp

My preferences:

- Get it done
- Make it easy to use

- Use R3's existing timer system for long delays, and then multimedia 
timers for the last precise bit

- Get smart graphics people to help with the little details, but 
smart systems people for the overall design

- Make it so easy to use that I, as a non-graphics-person, can write 
GUI apps

Also, don't neglect R3's event system in favor of hooking in some 
external one. If there are problems with R3's system, fix them first.

- Hookable system dialects (draw effect text)
So that we can add our own commands or hook some existing ones.

brianH yeah ... i always said new VID have to be as easy to write 
as previous vid for non specialist and  it serves even a greater 
purpose the GUI designers area. With easy made gob or panels (windows 
where you arange the gob to be displayed on screen ... ) the the 
designer output source produced with those tools remains easy to 
read.

visual gui editing with row columns is pretty easy to build.

i was trying the new parse commands...

I came with something existing, and said: Now, how can i do this 
more rebolish...

parse/case opcode [
	any [
		start: 
		| "nn" end: (change/part start get-byte end)
		| "+d" end: (change/part start get-d end)
		| "e" end: (change/part start get-e end)
		| skip
	]
]

Because change still doesn't work , the best i can do is that:

parse/case opcode [
    any [
          "nn" remove -2 (new: get-word) insert new
        | #"n" remove -1 (new: form get-byte) insert new
        | "+d" remove -2 (new: get-d) insert new
        | #"e" remove -1 (new: get-e) insert new
        | skip
    ]
]

What the gain ? nothing...

Forget CHANGE for the moment. Even with INSERT and REMOVE commands, 
i see things i don't like.

What i should able to write is that:

parse/case opcode [
    any [
          remove "nn" insert get-word
        | remove #"n" insert get-byte
        | remove "+d" insert get-d
        | remove #"e" insert get-e 
        | skip
    ]
]

Wich means:

- Remove "nn" if  "nn" is matched and insert the result of the function 
get-word.
or  Remove "n" ..
or  remove "+d" ...
or remove "e" ..

- Remove should use any rule as argument and not an obfuscated relative 
counter, because we don't have to calculate that. 

We know what matching rule must be deleted, we don't have to calculate 
is length more over.


- Insert should accept calculated values, it's obvious. If not it's 
useless.

When Change will work, I expect to be able to write:

parse/case opcode [
    any [
          change "nn" get-word
        | change #"n" get-byte
        | change "+d" get-d
        | change #"e" get-e 
        | skip
    ]
]

nothing more, nothing less

First of all, Steeve, what you are suggesting is the original INSERT, 
CHANGE and REMOVE proposals. Which Carl said were infeasible to implement, 
which is why we have the new ones. Besides that, your example code 
is still too awkward. Try this:

parse/case opcode [
    any [ start:
          "nn" remove start insert (get-word)
        | #"n" remove start insert (form get-byte)
        | "+d" remove start insert (get-d)
        | #"e" remove start insert (get-e)
        | skip
    ]
]


If you are worried about change not working yet, don't be. It is 
still planned.

The change version of the above would be this:

parse/case opcode [
    any [ start:
          "nn" change start (get-word)
        | #"n" change start (form get-byte)
        | "+d" change start (get-d)
        | #"e" change start (get-e)
        | skip
    ]
]

If the paren value form hasn't made it into alpha 83, it will make 
it into a new alpha soon.

Brian, Currentlty 'insert doen't accept parens as argument.

ah ok, you said that...

Was a83 released last night?

The planned treatment of the value argument for insert and change 
is to be the same as that of quote.

a83 released last night

Oh, cool, I'll take a look :)

but it's weird...

Work in process, but how so?

I don't understant, the following parsings should be equal but it's 
not, why ???

parse a: "abcdef" [
    any [
          "b" remove -1
        | "cd" remove -2
        | skip
    ]
]
print a
parse a: "abcdef" [
    any [start: 
          "b" remove start 
        | "cd" remove start
        | skip
    ]
]
print a

Example of work in progress: The ? is likely to be renamed to =>, 
since that is the mathematical symbol for then (not greater-than, 
which is >=). However, => is not a valid word in R3 yet - the syntax 
parser needs to have that sequence of characters added as an exception, 
like <=. This was too mch work for the a83 release.

Answer to your question, Steeve: It's a bug.

Actually, my "awkward" example is the only one to work currently. 
;-)

If I get a chance today (I'm volunteering at a horror film festival), 
I'll write up CureCode tickets for all bad behavior.

As a "creature" ?

As a booth babe.

:)

BrianH: how do you know => is going to be added? Any new info from 
Carl? Because I noticed his reply stating => is problematic, and 
no indication that ? might be changed to =>

As for insert/remove stuff, I noticed Carl proposed new easier way 
of implementing it, but does it really mean we can't revert back 
to first meaning, if it makes sense? We should aim high = implement 
what is best, not what is easier to be implemented ...

It was problematic for a83, but Carl doesn't like ? for the same 
reason we don't, so he'll change it eventually (perfectionism).

And as for the insert/remove changes, I was saying that the originally 
proposed way was infeasible because of private discussions Carl and 
I had about the subject. Carl's version is more powerful anyways, 
if you include the integer version.

Carl said it was infeasibble.

Brian - if => would still be problematic because of REBOL parser, 
then I would still prefer at least >  ....

and if we free ?, will we use it for if/check?

> means greater-than in math. => means then.

If we free ? we probably won't use it in PARSE at all. CHECK will 
probably continue to be called IF.

Carl asks about the change of insert/remove/change semantics, upon 
Steeve's comments - http://www.rebol.net/cgi-bin/r3blog.r?view=0254#comments

It would be a loss of functionality, slower, and more memory-hungry, 
but I would be OK with it either way.

3:1 for current index based method to 'remove ...

re GUI - I proposed to set-up wiki page similar to Parse proposal. 
We have few request for View kernel itself, as well for VID.

I think, that everybody is waiting for your go. I think that most 
ppl here prefer you working on Core. Most of devs here will prefer 
complete Core, along with parse, extensions, host code released, 
networking protocols, cgi, console and especially some FIRST words 
on concurrency ...

it is easy to state - we are in beta, while missing on some features. 
As for BrianH, I think he wants to move to Scheme dialect revision, 
once parse is done.

Actually - ppl still think, that before the host code is released 
(and hence host using Extension api (I think)), we are still dependant 
on you doing all the work ....

The question is, if it makes sense to jump to GUI anytime soon, without 
Core stuff not being finished to beta status ...

I think there are a few ways to slice the pie.  Here are my main 
motivations:

Before you move on though, check CureCode - there's 4 new parse bugs 
:(