AltME groups: search

Exactly, I hate to have information not centralized.  It should be 
intersting to see if we can bring all three of these (to start) together 
(meaning AltME, Email, QTask).  They each do something different. 
 but they should be compatible.  And in this context "Email" realliy 
refers to a relay Server.

why business policy? Do you think SafeWorlds wants to keep it under 
control? Well, bad service then? I don't believe they don't have 
at least two machines. Alme client could contain list of alternative 
look-up server - it would cover most outages imo ...

In some cases I've done that Graham, I've also made a special "startup" 
EXE for a script that runs, waits a bit, the DOes the script, to 
give things a chance to shut down. I've also done it where the app 
was simple and I could just DO a module to refresh it. That gets 
trickier if you have a more complex app that maintains state and 
such.

how do to find address ip from this stringu ?

not sure what you are trying to do, but the following is a better 
natural form once you get your string stuff INTO Rebol ... because 
REBOL will see it as its own datatypes, rather than as strings. [193.194.70.123 
1080 234.221.23.5 3380]

how do from this to read address ip ?

The main stat I use is 
do I like it?"" ... mine is "time to market".

which core versions allow you to do 'launch or 'call ?

Yeah - Carl should try to chime in sometime on some suggestions on 
how to do that.

Graham, right, I need to access the tape. The next problem is to 
handle things like: open-files, system state for Windows machines 
etc. IIRC Windows provides an API for backup-programs. If you want 
to do live backups of things like running DBs or Exchange etc. you 
need special APIs as well.

dialects are interpreters, which you can write in rebol. as interpreters, 
they can change everything. from rebol they inherit datatypes/syntax, 
which saves a lot work and makes things consistent. and the binding, 
which makes it easy to have variables in dialects and share them 
with rebol. the nice thing it, they keep their context. if you just 
pass strings and use regexp, you can do dialects in perl too, but 
the strings don't keep their context. which means sharing namespaces/locals 
with interpreters is less comfortable upto impossible.

Funny question: What's a good iconic metaphor for "Save file"? Okay, 
we're used to have a floppy-disk-icon to click on, but do all people 
now-a-days remember what floppy disks were? I can't imagine a working 
successor, though. An USB-stick pixeled on a 16x16 pixel grid?  Not 
too easily recognised, I assume ... Any suggestions?

Why do we have to save ?  "redo" action, you know ?  In real life, 
you don't save, you take one thing, you do something, and you stop. 
 When it can be the same in an app, it's better I think.  I have 
an app, where there is no save-button, this is very cool !

petr: how much do you save if you use bsdiff from 1.2.1 to 1.2.223?

you don't need bsdiff to do that :)

Robert: What do you understand under a sync interface. Easiest way 
and most compatible way would probably be to support syncML, as at 
least symbian supports it, but this would mean that IOS has to become 
a syncML server, that's not so easy - I think.

I have friends who run large cell phone shop here and they do both 
- export cell phone contacts, as well as backup all phone info, becase 
there are sometimes problems with new sw, which refuses to import 
setttings backed-up by older sw version and similar mess, and I talk 
about Nokias only ...

but those guys could know how to actually do it :-) The question 
is, if they would be willing to share experience ...

Anyone know how to do simple arithmetic operations on tuples such 
as ip addresses?

I'm curious about how try errors in tuple conversions - For example 
if I do a try [error? error:  to-tuple "abcd"] it doesn't evaluate 
correctly

So if you want if you want to increase a tuple but one, don't do 
the math in tuples. Do in integer space that is this line. (to-integer 
to-binary ip) + 1.

Hi, 


I would like to ask about how to implement best the auto-upgrade 
facility in rebol. Now the question is, how to aproach it best way. 
IIRC, Detective does something like that. Will you help me to answer 
some of my thoughts?


- typically the mechanism can be rather easy - just go and read some 
site, check for filesize, if differs, upgrade. But that might not 
be sufficient ..


- or you can store somewhere .txt (.cfg whatver file), containing 
rebol block or object, and do some more clever stuff. Basically following 
questions come to my mind:

- do just simple version check and upgrade to higher version?

- imagine an app, developing rather fast, producing xy version in 
the beginning = update often - the list can get long to load - but 
- you have to maintain it, as some ppl can be on vacation and still 
running old version - so - split it into separate, per-version file? 
I mean - making reverse aproach - provide updating config file for 
each version available. example - you have version 1.0, there were 
two other releases, 1.1 and 1.2 - you check 1.0 upgrade cfg and it 
tells you, you can go directly to 1.2 version ... or not, and you 
go to 1.1 first, then to 1.2 .... the reason is, that some version 
might require to rebuild data structures etc etc., so it is not always 
only about switching .exe

Or am I complicating it in unnecessary way? any ideas?

I hope you can place .exe itself in such a directory. It is imo necessary, 
that in such a case, update-date.r is being run by new .exe already. 
Imagine you want to rebuild database, and that there is View 1.4, 
which uses RIF, rebcode. You can't do it using old .exe, which uses 
older kernel incarnation ...

hallo, alls... I am not sure where to post this, so I figured I'd 
do it here...  I am trying to replace the default icon's for an encapped 
app using Resource Hacker... but if I replace the icons, the app 
crashes with an Out of Memory error... here's the actual output:** 
Script Error: Not enough memory
** Near: script: decapsulate
if none? script
** Press enter to quit...

Let me state - few weeks ago (actually two months), I started to 
write one document in make-doc format, but did not finish it. It 
was kind of brainstorming about current situation:

- simply put - what to do to promote Rebol?


I started with the fact, that e.g. OSNews.com reports every little 
bit of new version of xy-language related product, while my news 
item about View 1.3 did not get it to their news. New info is, that 
I contacted Tom Holwerda and he told me OSNews does not have any 
problem with Rebol news, and that it is upon us to submit the news. 
I thought that at least for main product releases as View 1.3.x we 
could do it. Of course it would REALLY help, if RT would be a bit 
more sharing about the schedule, because simply sometimes a bit of 
hype does not hurt, so we could attract ppl to new Rebcode, to hopefully 
coming rich-text, faster blitting etc., not to mention Rebservices 
as a separate article. But although rebservices were released, I 
sadly feel about it much worse than I feel about old Rugby! It just 
feels like RT would drop the ball to the community and nothing is 
happening in this field anymore. So actually, what is RT working 
on right now? There should be some communication channel, so that 
us - rebollers would be informed enough to participate in chats following 
the news articles. We have QA channel here, but most often news are 
- "we plan", "soon", and that is not simply acceptable to feel informed. 
So it is from devcon's time, that we "soon" will know, what is the 
plan for VID, not to menthion real implementation schedule - that 
does not work!

Now - I know our point of views can vary, but that is simply how 
I feel about it. As I said in the beginning - we have nice info about 
REBOL already, I am just not sure, that beginner is able to easily 
find all good sources. Rebol sites ring? Dunno. Any suggestions about 
what to do about it?

oh, and I forgot one aspect - View based apps! Two weeks ago I suggeste 
rebol word browser plus Roam to be put into Docs section of ViewTop 
section. Too good apps to be missed by those looking for good source 
of info. Look at rebol word browser - nice apps, superior to web. 
Now imagine it running as a plug-in somewhere on RT's site. That 
is how live docs look, it would allow for examples to be executed 
and you could even allow area with script source, so users could 
do small changes and see how they are reflected in the result. Just 
not sure about security :-)

The Gripe:


Go here www.Rebol.org, then go here: http://www.ruby-lang.org/en/, 
then here: http://java.sun.com/, hell even go here, http://msdn.microsoft.com/vbasic/, 
now go back to www.Rebol.com


Even if you don't know what the language is or does, do you want 
to go to Rebol.org?  The main page looks like the last page in the 
basement of a website.  Almost like an "error page"

O There is no single location for all Rebol information.

O Rebol.net, Rebol.com, and Rebol.org are spread out and run by RT. 
O There is no pizzas!
O I don't "feel" community when I visit these sites.


I know I'm not talking to my audience when I say; "think of this 
like a night club" but this is what this is all about.  People want 
to "be where the fun is happening."  Even programmers.

My Suggestion:

O We need a site controlled by the developers.

O We need a forum where people can bitch and meet each other, and 
feel welcome.

O The site needs to have a consistent dynamic attractive template.

O The site needs to be a clearing house for all other sites.  Teach 
and directing people to all the resources.

O The site needs to paint a picture as opposed to describe everything 
with a thousand words.

What is entailed:


O Start a new site, I would propose "RebolCentral.com"  I'm willing 
to pay for it, but I don't want to be in charge of it, I suggest 
we make it a committee.


O The main page should cover every topic and reason anyone would 
come to the site.  This means we support every country and other 
site.  The idea here is a clearing house of centralized information. 


O News: The site needs to gather news worthy information and post 
that at the top.  The site is not alive unless people have a way 
to post their information.  This means that there needs to be at 
least one editor, if not several that share the task.  Every time 
a product is updated, the new features are mentioned.  When Carl 
updates his blog, it gets a single sentence directing people there, 
unless it is news of a release of something.  Etc.


O Product Reviews:   This is key.  Products need to be rated, reviewed, 
categorized, voted on.

O Video Archive: All the videos of all the talks ever given   


O Tutorials:  there are a lot of tutorials out there, but which are 
best?  We need to review the tutorials, rate them by Beginner, Intermediate, 
Advanced.  


O Forum: Start with major topics, and then break it down.  The forum 
needs to direct people to other countries, or support the other countries 
right in the forum.  Great simple forum: http://discussion.treocentral.com/index.php?styleid=1


O Respect the real estate.  The #1 mistake people make is treating 
their websites like just pages.  This is just like real estate, location 
location location.  We need to place the content based on where people 
are going.  So you build the basic site, watch it for a couple of 
weeks, then shift things around based on where people are actually 
going. 


O More art, more photos, more community.   It needs to feel inviting: 
http://msdn.microsoft.com/events/pdc/

Stone soup:


I will pay for, host, and supply a fast linux system (w/archive). 
 

I will help design the templates, and provide (and buy if needed) 
great art for the site.

I will not run the site, nor control the content, but I expect there 
to be in place all the items outlined above, set up in a manner that 
it a) runs itself, b) puts the power in the hands of the developers.

I don't know what they can do better, my only point is, don't let 
our inability to find a Rebol solution to a problem stop us from 
finding a solution to the problem.

IOS is great as long as it is an "Open" IOS servers.  Meaning EVERYONE 
is welcome.  I want to see an end to any form of elitism in the Rebol 
community.  It hurts everyone.

Yes, I'm clear on what Rebol.org is, still looks like it was designed 
by the Incarceration committee for the Federal government.


Other languages, SURE.  That only drives traffic.  Although it would 
probably end up being just in the forums.

I see IOS more like a quick meeting-place. Want to do something, 
set up new server. Together with web-publishing. Say we have a few 
licenses for some projects.

They may have lot more to do with the fact that hackers don't target 
OSX.

Is it not true though that you are limited in what you can do with 
rebol.org ?  I.e.  there are some restrictions whereas if you had 
your own box, the library team could do more?  If this is the case, 
why not let the library team take over the new box and migrate the 
content from rebol.org to there?

A CHAT WITH NAUGHTY DOG ABOUT NEXT-GEN!


We chatted with Stephen White, co-president and programming manager 
of Santa Monica, CA-based videogame developer Naughty Dog about creating 
games for the next-generation consoles … and he offered some suggestions 
for dealing with next-gen hurdles.


Q. Naughty Dog is known for the “Crash Bandicoot” and “Jak and Daxter” 
franchises which have sold over 35 million units combined. What have 
been the fundamental keys to the success of your titles and how do 
you plan to apply those to your next-generation game development?


A. One of the biggest factors in the making of a successful game 
is hiring very talented people who are motivated and can get the 
job done without the need for extensive management and finely detailed 
schedules.

Carl: "I would really like to have a DB built-into REBOL 3.0


The trick is, it cannot just be any DB... it has to align perfectly 
with REBOL. Specifically, we want the DB to be able to store all 
REBOL datatypes efficiently. But, we also want the DB code to be 
very small. I will not allow REBOL to bloat for it. And, finally, 
the code must be free, like SQLite is (at least, I think).


Note that the DB does not need to have every feature in the book. 
 I'm not asking for SQL (that is, we will use REBOL or a dialect 
to access the DB, no need for another language).


I would really like to get the help of the community in this effort, 
but I do not have time to even organize a decent search.  If someone 
else wants to head it up, it would very much improve R3.0. If not, 
then we will do RIF, which gets us a lot of DB, and is super efficient 
compared to any other DB. But, it is only an index system, not a 
RDB."

I have also suspicion, that some of you guys, e.g. Gabriele (I mean 
it in a friendly non complaining mode :-), don't mind having everything 
in one .exe. Neither do I in fact, View is still small in today's 
terms - but - if we talk small devices - it is not. Go and try to 
download it via GPRS I use with my cell phone - it does not look 
like a small app to upgrade in any way :-)

An SQL type database is one where the basic unit of storage is an 
atomic data item, though packaged into rows / tuples.   Getting rid 
of 1NF data (recurring groups) is the first thing you are taught 
to do.

In a list type database the basic unit of storage is a list (think 
REBOL block). That's far from being 1NF, especially as a list can 
contain other lists.

well the hard thing to do with parse is longest match.

Parse has this problem in particular for its temporary variables 
- they aren't very recursion safe. You can do some hacks to make 
up for missing parse keywords using code blocks, but usually those 
need some temporaries.

Paul, do a search & replace upfront. Much simpler than to create 
complex parse rules.

I often use this pattern. Do some basic action on the parse input, 
parse the first round, again do some other processing than using 
parse again. Much simpler and faster to get where you want to go.

Your example still doesn't seem to jive with the documentation.  
Reading the docs, I would expected two strings in the output block. 
 "my string" and the rest, in braces.  It has something to do with 
a double quote starting a parse sequence.   {"abc"def} parses as 
["abc" "def"]  { "abc"def"} parses as a single string as expected 
[{ "abc"def}]

Wow, I never realized how incredibly extensive RTF is.


The ONLY thing I need is to identify the character position and length 
of Regular, Italic, Bold, Underline, or Strikeout and the text, so 
in my above example, maybe the parser could return this:  Note: birsu 
stands for Bold, Italic, Regular, Strikeout, Underline.
Line	Pos	Len	birsu	Text
1	1	24	..r..	"Default Arial font 10 * " 
1	25	(n)	..r..	"Regular Courier New font 11 * "
1	(..)	(..)	.i...	"Italic * "		

1	(..)	(..)	b....	"Bold"(newline)			<-- note \i0 turns off itialic

2	1	14	bi...	"Bold Italic * "			<-- note \b is still in effect from 
a previous setting

2	15	(..)	..r.u	"Regular Underline * "		<-- note \i\b is turned off.
2	(..)	(..)	..rs.	"Regular Strikeout"(newline)
3	1	(..)	..rsu	"Regular Underline Strikeout"(newline)
4	1	(..)	bi.su	"Bold Italic Underline Strikeout"(newline)

Ideas on how to do this as a start?

Hey Gregg -- That is just what I've been doing.  I have identified 
the following:

1. That all printable \ { and } will show up in RTF as backslash 
along with the special character like \\   \{  or \}  any remaining 
\, {, or } will be RTF commands.

2.  {  }  and ; identify groupings with the open brace and terminating 
the group with close brace within the RTF.  The semicolon is used 
to terminate sub parameters for a particular command.

3.  \xxx  will always identify a particular command with an optional 
number appended to it.  Example: \b  means bold while \b0 meand bold 
off.


What I am toying with is to define simple rules to break apart a 
string of the RTF commands and embedded text into two parts, the 
command part and a parameter part.  (some parameters may be a block 
of multiple values).


I'm studying the Parse command to see what I can do simply and progress 
from there.

That rings a bell --- I vaguely remember having to do stuff like 
replacing 
   " or }
with
    to-char 0
before doing some parses, and then changing back afterwards.
That works if you have no to-char 0 in your strings

Or, instead of parse, do -- select decode-cgi find/tail string "?" 
to-set-word 'area

If you require that the argument value that is not url-encoded be 
the last, you can just do a to end or whatever the string terminator 
is.

I'm not really sure. First I do a general 6502 assembler and emulator, 
but I only have an emulator of the BBC homecomputer to test up against, 
so I probably have to deal with some Operating System stuff too. 
I operate with a 64k address space, and on the BBC writing to some 
certain addresses made something special for that platform happen. 
But let's see, what we can do.

I'm a little stuck here with a simple problem:

a: func [v] [

  parse v [
 
    any [
      'a (prin "a")

      | 'b (prin "b")
      | 'c (prin "c")

      (prin "-")

    ]
 
  ]

]

>> 

a [a b c c a]
abc-c-a


I want to print the dash after every letter. Do I have to include 
it after each word?

Now that I think of it, I would not even use a parse to do that. 
 But what could I do if I wanted only a subset of characters to show 
up without defining them all

You have to remember to structure your rules using LL style. Do you 
notice that I checked for one word first, then looped over the subsequent 
words? That was to avoid putting the "-" after the last word as well. 
Parse uses right recursion - not like yacc, which uses left recursion.

I see I can do a reduce on the blk when passed to parse and get it 
true but not sure that is safe for my situation.

well, how do you want it to automatically recognize the input as 
datatypes? the only other way around it is to keep them as words 
and make a datatype rule to detect words that look like a datatype.

Yes, I understand that but it defeats Carl's famous philosophy which 
is that simple things should be simple to do.

Currently, I do something similiar to this:

user passes dynamic data captures in a block:
data: ["fname" string! "age" integer!]

Then I do the following:
        data: next data

        forskip data 2 [poke data 1 load mold/all attempt [to-datatype data/1]]

well, if that's all you do, you don't even have to convert it to 
a datatype, IMHO. it's enough to collect a list of rebol's datatypes 
as words, so they be used to trigger on the input word which looks 
like a datatype. I can see you are going for correctness, i.e. wanting 
the input to be a real datatype, but if you only use that input as 
a trigger to do something, you don't need to convert it to a real 
datatype. just operate using words.

So setting types to all of those is not very efficient.  At this 
point using parse to do this is as Gregg said not "simple..

So setting types to all of those is not very efficient.

 -- Do you mean in the parsing, or in the time it takes to set up 
 the rule(s)?

This assumes that you aren't taking advantage of REBOL's type system 
to do SQLite-style manifest typing.

If you are doing type specifications to validate records, the fastest 
way to do it is to generate static validation rules based on the 
specification, then just apply the generated per row. Static validation 
rules would be faster than dynamic.

I think my parse rules use lots of temporary variables.. How do you 
prefer to hide these?

1: Hide them from whom, and why?

In general, if you want to hide something about your parse rules, 
you need to hide the parse rules altogether. That is not to say that 
it is a good idea; I've found that in most cases that someone wants 
to hide some code or variables in REBOL, they really want to do something 
else and the something else depends on the circumstances. What do 
you hope to accomplish?

2: You have to be careful with temporary variables.

REBOL parse rules are often recursive, and the temporary variables 
used with them are not. You have to be extra careful to not recurse 
to another trip through the same parse rule before you are done with 
the temporary variables in the first round, or put off setting the 
temps until just before they are used. It's not as hard as it sounds.

I've got rules to find each: (some digit "." some space) etc. and 
it works. I've been able to copy the text following with (copy text 
thru end) but how do I copy the section number?

Oldes, thanks for your suggestion. It works when I do a simple one 
line rule as you suggested but when I try to use multiple rules it 
fails.

Example of what I'm trying to do:
Example of the text document:

This will give me a hit on any section or sub or sub sub?


I may want to do something different depending on each. does this 
allow me to ?

Josh, if you do a load/markup on the whole string, you get a block 
with tags and strings. You can then pick the string from the block, 
maybe doing TRIM on them to sort out newlines and spaces. Like:

blk: load/markup your-data
foreach f blk [if all [string? f "" <> trim f] [print f]]

If you wanna use PARSE, you can do something like:


parse your-data [some ["<" thru ">" | copy y to "<" (if "" <> trim 
y [print y])]]

I've been toying with this to obtain a very parsable "dialect" -- 
my goal being to scrape live game updates from a certain sports web 
site (for personal use, natch).  It's reliant on 'parse-xml though, 
so ymmv....

do http://www.ross-gill.com/r/scrape.r
probe load-xml some-xml

Best thing to do is try it out as it really takes very little time 
to setup and try and you will know probably if it is suitable for 
you in about 10 minutes.

It's usually a bad idea to use lit-words as keywords - they make 
better values. If you are comparing to a particular lit-word value, 
that is using it as a keyword. If any lit-word value would do and 
their meaning is semantic rather than syntactic, that works. In general, 
PARSE is better for determining syntactic stuff - use the DO dialect 
code in the parens for semantic stuff.

rules: [some [set  ww  word! set ss string! (do reduce [to-set-word 
ww ss]) ]]

Graham - what xml REBOL tool do you use? I might need to parse XML 
stuff soon. In the past I used one tool (don't remember the author), 
which made object from parsed data automatically ...

That DO proposal was the first one to be rejected. It will take some 
serious problems with dialecting to get it included.

That way you could do this to return the first HTML tag from data:
	[to "<" return thru ">"]

What would you do when you need to process the data a bit first ?

eg. You return tags from different places in a rule, and to distinguish 
them you need to also return something extra, by prepending a code 
to the beginning, for example.

You might be able to do b) like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a] | remove ["abcd" 
 a: "ef123" :a] to end]]
or like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a | "abcd" a: 
 "ef123" :a] to end]]

Now that is interesting. LOAD and TO-BLOCK do that. It would be interesting 
to write a set of rules in PARSE that read REBOL syntax and generate 
REBOL data or warnings instead of errors. For your purposes you might 
consider LOAD/NEXT in a loop inside of TRY blocks.

You can't do that. TO-BLOCK is a wrapper for TO BLOCK! val and TO 
is an action! with a fixed arity. What you want is a parser for user 
data that isn't in REBOL syntax. That we can do.

BrianH: how do you know how much to store in cache and whent o flush 
it?

Block parsing ? How are you going to do that when you can't even 
see the final ']'  in the buffer yet ?

Here's an example of what you could do with the PARSE proposals:

use [r d f] [ ; External words from standard USE statement
    parse f: read d: %./ r: [
        use [d1 f p] [ ; These words override the outer words
            any [
            ; Check for directory filename

                (d1: d) ; This maintains a recursive directory stack
                p: ; Save the position

                change [ ; This rule must be matched before the change happens

                    ; Set f to the filename if it is a directory else fail
                    set f into file! [to end reverse "/" to end]
                    ; f is a directory filename, so process it
                    (

                        d: join d f ; Add the directory name to the current path

                        f: read d   ; Read the directory into a block
                    )
                    ; f is now a block of filenames.
                ] f ; The file is now the block read above
                :p  ; Go back to the saved position
                into block! r ; Now recurse into the new block
                (d: d1) ; Pop the directory stack
            ; Otherwise backtrack and skip
                | skip
            ] ; end any
        ] ; end use
    ] ; end parse
    f ; This is the expanded directory block
]

Don't know why, but most of the time when parsing CSV structure I 
have to do something like:

parse/all append item ";" ";" 


Simply put, to get all columns, I need to add the last semicolon 
to the input string ...

Aside from a bugfix in the last example I gave (forgot the only) 
I would say yes for now. There will be more changes when Carl gets 
back to this so that we can discuss his proposals. Everyone else's 
proposals seem to have been covered except THROW (which also need 
Carl feedback). Incorporating COLLECT and KEEP into PARSE is both 
unnecessary and doesn't help at all for building hierarchical structures. 
PARSE doesn't have anything to do with parsing REBOL's syntax, so 
Graham's problems are out-of-scope. If you have more ideas this or 
the same group in the alpha world are the places to bring them up.

yes it talk to BrianH, what do u mean ?

I am the editor of the PARSE proposals.


It was decided that I perform this role because Carl is focused on 
the GUI work right now and someone qualified had to do it. With Carl 
busy and Ladislav not here, I am the one left who has the most background 
in parsing and the most understanding of what can be done efficiently 
and what can't. When the PARSE REPs of old were discussed, I was 
right there in the conversation and the originator of about half 
of them, mostly based on my experience with other parsers and parser 
generators. Because of this I am well aware of the original motivation 
behind them, and have had many years to think them through. It's 
just head start, really.


I am also the author of the current implementation of COLLECT and 
KEEP, based on Gabriele's original idea, which was a really great 
idea. It is also really limited. Collecting information and building 
data structures out of it is the basic function that programming 
languages do, and something that REBOL is really good at. I am not 
in any way denigrating the importance of building data structures. 
I certainly did not mean to imply that your appreciation of that 
important task was in any way less important.


The role of an editor is not just to collect proposals, but to make 
sure they fit with the overall goal of the project. This sometimes 
means rejecting proposals, or reshaping them. This is not a role 
that I am sorry about - someone has to do it to make our tool better. 
We are not Perl, this is not anything goes, we actually try to make 
the best decisions here. I hate to seem the bad guy sometimes, but 
someone has to do it :(


PARSE is a portion of REBOL that is dedicated to a particular role. 
It recognizes patterns in data, extracts some of the data, and then 
calls out to the DO dialect to do something with the data. It doesn't 
really do anything to the data itself - everything happens in the 
DO dialect code in the parens. It is fairly simple really, and from 
carefully designed simplicity it gets a heck of a lot of power and 
speed. That is its strength.


The thing that a lot of people don't remember when making improvements 
to a dialect like PARSE is that PARSE is only one part of REBOL. 
If something doesn't go into PARSE, it can go into another part of 
REBOL. We have to consider the language as a whole when we are doing 
things like this.

Here is the overall rationale for the PARSE dialect proposals:

- All new features need to be simple to explain and use, and fast 
at runtime.
- A good feature would be one of these:

  - An extremely powerful enhancement of PARSE's language recognition.

  - A fix to a design flaw in an existing feature, or a compatibility 
  fix.

  - A serious improvement to a sufficiently common use case, or common 
  error.


The reason I didn't want to put COLLECT and KEEP into PARSE is because 
it is a small part of a much bigger problem that really needs a lot 
of flexibility. Different structure collection and building situations 
require different behavior. It just so happens that the DO dialect 
is much better suited to solving this particular problem than the 
PARSE dialect is. Remember, PARSE is a native dialect, and as such 
is rather fixed.


There are some PARSE proposals that make parse actually do something 
with the data itself: CHANGE, INSERT and REMOVE. We were very careful 
when we designed those proposals. In particular, we wanted to provide 
the bare minimum that would be necessary to handle some very common 
idioms that are usually done wrong, even by the best PARSE programmers. 
Sometimes we add stuff into REBOL that is just there to solve a commonly 
messed up problem, so that a well debugged solution would be there 
for people to choose instead of trying to solve it again themselves, 
badly. (This is why the MOVE function got added to R3 and 2.7.6, 
btw.) Even with that justification those features might not make 
it into PARSE because they change the role of PARSE from recognition 
to modification. I have high hopes, though.


Another proposal that might not make it into PARSE is RETURN. RETURN 
is another ease-of-use addition. In particular, the thing it makes 
easy is stopping the parse in the middle to return some recognized 
information. However, it changes the return characteristics of PARSE 
in ways that may have unpredictable results, and may not have enough 
benefit. The proposal that has a better chance of making it is BREAK/return, 
though I'd like to see both (we can hope, right?).


Most of the REPs from Gabriele's doc have been covered. Most of them 
have been changed because we have had time in the last several years 
to give them some thought; the only unchanged ones are NOT and FAIL, 
so far. Some have been rejected because they just weren't going to 
work at all (8 and 12). THROW and DO are still under discussion - 
the proposals won't work as is, but the ideas behind them have merit. 
The rest have been debated and changed into good proposals. Note 
that the DO proposal would be rejected outright for R2, but R3's 
changes to word binding make it possible to make it safe (as figured 
out during a conversation with Anton this evening).


There are other features that are not really changes to the PARSE 
dialect, and so are out of scope for these proposals. That doesn't 
mean that they won't be implemented, just that they are a separate 
subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, 
Henrik), REBOL language syntax (sorry, Graham), and port parsing 
(sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, 
while discussing the subject with Anton here I figured out a way 
to do port parsing with the R3 port model (it wouldn't work with 
the R2 port model). I will bring these all up with Carl when it comes 
to that.


I hope that this makes the situation and my position on the subject 
clearer. I'm sorry for any misunderstandings that arose during this 
process.

Note that I am quite familiar with collecting data from hierarchical 
and other structures and putting that data into hierarchical and 
other data structures. I have done this with PARSE, with DO dialect 
code, and with a combination of the two. I have found that PARSE 
is good for recognition, but DO dialect code is best for the construction. 
A mix of both is usually the best strategy. You can use the existing 
COLLECT and KEEP with PARSE quite well. PARSE is not a standalone 
dialect - it is meant to be integrated with other dialects, particularly 
the DO dialect that gets executed in the parens.

I am sorry if it seemed like I was taking credit for various PARSE 
proposals. It is not anyone's fault that I have been using PARSE 
long enough that 7 or more years ago I came up with almost every 
one of those proposals, or their original inspirations. That's where 
the conversations that led to the REPs came from. There weren't as 
many REBOL users back before the Official Guide and REBOL for Dummies 
:)


If other people who have had the same ideas since would like to add 
their names to the appropriate proposals I would be more than happy 
to help - consider them to be votes. I would be happier still if 
someone came up with a better way to do THROW or DO, because I am 
at a loss to figure out a way that isn't dumb :(

I've wanted to change the licensing on that script to BSD for years. 
It can do more than the native version - they simplified it.

2, 3 tips 
I know that Brian is great contributor but I think sometimes 
it tends to reject a bit too easily ideas of others. 
Why I am saying this, is that I am not always convinced by his 
arguments but he acts as if the issue was resolved in advance. 
(I may have a problem with that) 

About who is credited with what, I think that this is not 

important too, however it was a bit of supris seeing the name of 
Brian on 
most of the ideas, then as I said previously, this makes 

many years that these Improvements have been suggested by different 
people. 

Obviously this is not an important step, but Brian, you puting your 
name 

everywhere pretexting you collect ideas is a little ... how to say 
that ?
pretentious. 

Personally, I am a large user of parsing. 
I think this is the most important function in Rebol. 
You can do practically everything with it.
Design dialects, interfaces, and many others things. 

Parse can build programs by clearly showing the data structures your 
are dealing with. 
Thus our scripts win in readability. 


During all these years, I was very frustrated seeing some limitations. 

I thought, oh my God, if only we could do this simply, REBOL would 
be so powerful. 

My view is that parse should be extended (as far as possible) to 
gain in expressiveness.

One thing I don't like with parse, is the cumbersome process to pass 
parameters to functions. 

I give an example. 
usually we do: [copy parm my-rule (my-func parm)] 

If parse knew recognize when to call a function we could write: 
	[Myfunc my-rule] 

This would be much more compact and expressive. 

More, we could use return value of myfunc to guess if the parsing 
should continue or not. 

This development would discard most of proposals that were made because 
we could add many new commands very easily. 
(IF NOT ALL RETURN etc ...)

Off topic ... but one of my first chat programs used SOAP to do automatic 
translations

Steeve, your latest suggestion is very similar to the RULE! type 
REP (11). Unfortunately, Graham is right that this would basically 
require rewriting PARSE from scratch as a function type. This is 
something I have wanted to do for years, and will get the chance 
to do so once R3's user-defined datatypes are available. I like the 
way you think :)

The final decisions are made by Carl. He's the language director 
and he'll be implementing this stuff. If he say it can't happen, 
it can't happen. If I say that it can happen later when another feature 
is added, you can be sure that I have already figured out how to 
do so - I wouldn't say otherwise.

and will we be able to do things like  [ copy obj/var to something 
]

but if you  do that you must limit the behaviour of INTO.
currently INTO enter in paren! path! and block!.
if think it's to versatile

It occured to me (as I'm sure that it has occured to others) that 
it is possible for parse rules to do one bad thing even if you exclude 
all of the modification statements, word setting statements, and 
parens: ANY and SOME can go into infinite loops if they don't advance 
the position. I would like to propose that there be some form of 
warning or error if SOME or ANY loop again on the same position they 
did last time. This condition should be screened for with a PARSE 
refinement. If the refinement is set then when the point is reached 
where ANY or SOME would repeat at the same position, the rule would 
fail (and possibly backtrack to the next alternate).

it's the responsability of sub-rules to do some skip to avoid such 
cases

Anton, trying creating a word string! and a datatype! string! value 
and insert into a block.  [string! string!]  and then do your testing. 
 I remember discussing this with BrianH when I ran into the issue. 
 I don't have REBOL on the computer I'm currently working from right 
now so I can't present any test at the moment and I'm turning this 
laptop back in to the company soon.

It was the fact that we didn't want to do the reduce on the third 
one.  Not a big deal Anton.  I'm the only one that wanted that functionality. 
 In fact I think I changed my storage medium to workaround the issue.

i take an example:

to simulate AND we do [here: rule :here] but it can't be used in 
a recursive manner.

If we had PUSH and POP to save and restore the current Index depending 
the level of the recursion (in fact they are stack operations)
So, we could write: AND: [push rule pop]

Gabriele, that would be one way to do AND (though Peta's workaround 
is probably the most efficient).

Well, Peta's additions and changes have been integrated and cleaned 
up. There are more clear guidelines for the project now. Still haven't 
added Gabriele's DO operation yet, though I now know how to do so. 
Anything else?