AltME groups: search

to goes to the point and thru includes the point

because it matches digit and the cursor moves on

and correct syntax helps :)

he was looking for the number and the string though.

Yes and formating may need to be retained

I'm converting them to text and reformatting them to parse

So I can index for keywords and search and read only thse sections 
I need.

Photos and diagrams will also be stored.

The next version of TRETBASE which is in work is multi-user and supports 
indexing.

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.

Is there a difference between a "space" and a "tab"? Can you parse 
for tab and not sapce?

I would think you would have to parse/all .. and a space is #" " 
and a tab is #"^-"

A long time ago, I offered to try a lecture.  Don't feel worthy. 
 So I thought I'd throw out a few (mis)understandings and have them 
corrected to build up a level of comfort that I wouldn't be leading 
a group of high potential rebols down a garden path.


So; one of the critical mistakes in PARSE can be remembered as  "so 
many", or a butchery of some [ any [ , so many.

some asks for a truth among alternatives and any say's "yep, got 
zero of the thing I was looking for", but doesn't consume anything. 
 SOME says, great and then asks for a truth.  ANY say "yep, got zero 
of the thing I was looking for", and still doesn't move, ready to 
answer yes to every question SOME can ask.  An infinite PARSE loop.


Aside: to protect against infinite loops always start a fresh PARSE 
block with [()   the "immediate block" of the paren! will allow for 
a keyboard escape, and not the more drastic Ctrl-C.


So, I'd like to ask the audience; what other PARSE command sequences 
can cause infinite loops?


end?  and is it only  "end", "to end" but "thru end" will alleviate 
that one?  end end end end being true?

>> parse "" [some [() end end end]]
(escape)
>> parse "" [some [() thru end end end]]
== false
>> parse "" [some [() to end end end]]
(escape)
>> 


Ok, but thru end is false.  Is there an idiom to avoid looping on 
end, but still being true on the first hit?

Other trip ups?

forget it. I was confused for a second, but is there a way to parse 
that 'a correctly? The same goes for get-word! and set-word!.

I should clarify: I would like to parse a specific get-word!, lit-word! 
or set-word! as opposed to parsing on the type and then checking 
the value in some kind of action afterwards:


parse ['a 'b 'c] ['a 'b 'c] ;== true (I know this is the wrong parser 
block, but it's something to that effect I would like to see)

If I remember correctly, this was a problem of parse (and may still 
be)...

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.

Yes, this is an old bug.
It does not work, if " is next to your delimiter.
Insert a blank, and it works again.

This is a result of using parse-xml and some cleanup

[document
	[soapenv:Envelope
		[soapenv:Body
			[ns1:getSpellingSuggestionsResponse
				[getSpellingSuggestionsReturn
					[getSpellingSuggestionsReturn "Penicillin G"]
					[getSpellingSuggestionsReturn "Penicillin V"]
					[getSpellingSuggestionsReturn "Penicillamine"]
					[getSpellingSuggestionsReturn "Polycillin"]
				]
			]
		]
	]
]

It's not so bad Graham. And whether you can shorten things depends 
on how exact you need to be.

rule: [
	'getspellingsuggestionsreturn some drugs
	| url! into rule
]
parse a ['document into rule]

the output I presented looks so close to being a rebol object .. 
and then I can use paths to access the data

Sorry about the formatting ... can't cut and paste in AltME on a 
Mac without reformatting.

not parse and not pretty  but  you get the idea

So far we have been accepting proposals in these categories:
- Recognition: LIT, NOT, OF, TO and THRU extensions
- Modification: CHANGE, INSERT, REMOVE

- Structural and control flow: FAIL (may not be the final name), 
USE, CHECK (still debate here), REVERSE


There is still some debate even within these proposals (name of FAIL 
for example) and some of them might not make it. Some of the old 
PARSE REPs have been definitively rejected or changed, and some are 
still under debate and won't make it in without a lot more thought.

Lots of good suggestions. I've just re-read Gabriele's Parse REP 
and the ParseProject DocBase article.

Yup. We've been working on the Parse Project article a lot today. 
The last 2 things from the REP that might make it are the THROW and 
INTO-STRING proposals, though both will need some changes first. 
The rest are covered or rejected.

I like the RETURN proposal as this:

	RETURN rule


Match the rule and return a copy of the value from the PARSE function. 
Like COPY then BREAK, but without the temporary variable.

Clearly my proposal for START is based on my ignorance and inability 
to search the documents properly :-)

It wouldn't hurt as a form of slef-documenting code, though.

Actually, I think it would hurt (no offence). The word start is a 
common name for parse rules and every keyword we add can't be used 
as a parse rule name. Something to consider when making proposals.

Gabriele's DO command is interesting.

I wonder why it could not become more "functional" and be used after 
the SET command, eg:
	SET result DO integer!

Anton - but there is some point in time we should start to make rebol 
bigger by adding unnecessary things, or we will never reach 100MB 
executable size and outer world migt not consider us being a rellevant 
alternative :-)

do what Carl does ........... and use one letter variables

Didn't you get Carl's simplicity blog? It was posted on Reddit and 
PLNews :)

I was thinking that you not even have the parens at all, and just 
have RETURN rule.

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.

Carl was kinda weirded out by the modifying operations, but I pointed 
out that people do this anyway and get it wrong a lot.

They're going in. If we were just doing what Carl wants, he wouldn't 
need to ask for suggestions and ask me to compile them.

Everything in that Parse Proposals page has already been discussed 
with Carl and could go in, barring insurmountable problems with implementation. 
I stopped putting stuff in when he stopped working for the day. There 
will likely be a couple going in tonight, but Carl is actively involved 
in this process.

It was freeing when Carl said that we could use modifier keywords 
like ONLY for CHANGE and INSERT. I look forward to seeing how that 
would affect the INTO-STRING proposal :)

And the beginning is the end :)

If you turn a string into a block and there's something present which 
is an illegal rebol value ... you get an error.

Is there a way such values can be turned into a legal type ....and 
not get an error?

Just don't try to parse illegal REBOL syntax as if it were legal 
and you'll be fine. You have string parse for non-REBOL strings.

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.

Not up to me. I think that the decision was that relaxing REBOL syntax 
was a slippery slope that would lead to uncatchable syntax errors. 
The syntax error mechanism is one of the most valuable debugging 
tools we have. You might need to consider the possibility that if 
what your users are entering isn't legal REBOL syntax, it isn't REBOL 
syntax and needs a different parser.

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.

Graham, my 'import (and 'as) function is kindof addresses this.  
I've also been working on loading non-rebol data (in some cases numbers 
that use , -- 1,000 or us-style dates mm/dd/yyyy).  This'll be even 
better with some transformational chops in parse...

I agree that things should be easier to parse - and that includes 
preparing data to be parsed.

comma and space  seem to be others

hmm, continuous parse ... there was my request for it long time ago, 
and IIRC even Carl said, that it might be usefull. Imagine for e.g. 
encoders ... You read stream from file in chunks, and you evaluate. 
The problem is, when you need to backtrack, you would need to cache 
the stream. Dunno, if something like that is possible at all ...

I don't like the result of none if parsing strings.


parse/all ",,," [(block: copy [] ) any [thru "," copy a to "," (append 
block a)] to end ]
should give  
>> block
== ["" ""]
and not
== [none none]

My suggested improvement to parse would be a trace (or debug) refinement:
    trace-output-word: copy [] 
    parse/trace string rules trace-output-word 

I'm not entirely sure how it would work. That would depend in part 
on how parse works internally, and so what trace points are possible. 
But, as a minimum, I'd expect it to show me each rule that triggers 
a match, and the current position of the string being parsed.
 parse would  append trace info to the trace-output word


Otherwise, parse is too big a black box for any one other than very 
patient experts.

Streamed parsing with backtracking : sure, it's possible, I'm doing 
that in postgresql driver since 2001 and more recently in the experimental 
async mysql driver release last year. (It's not done in a easily 
reusable way, thought).

Tracing support would be good to add, but start it and stop it with 
the TRACE native.

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

Well, when PARSE enters a block it saves the position at the start 
of that block. If you have to backtrack that is as far back as you 
would need to cache. PARSE could optimize this by not saving backtracking 
info unless there is an alternate later on in the block. You could 
then minimize caching in some cases by rearranging your rules to 
use as little backtracking as possible, and none at the top level.

DISPENSE: Parse command to mark points in the data which don't need 
backtracking past. Parse can use

  this information to dispense with older buffer data no longer needed. 
  Otherwise it holds and accumulates the data.

  This would be used for very large or unbound length data streams. 
  eg. internet radio.

And also set-words..

and Anton's DISPENSE when you know you ain't goin' backwards from 
here.

And crashing PARSE if you DISPENSE something that you need to go 
back to. That might be better done with incremental parsing.

Yes, I was just thinking what would happen if you var:, DISPENSE, 
then :var afterwards.

Should DISPENSE update the index of var (and any other vars) when 
the internal parse index shortens ?

Oh, set-words and get-words would not work the same with R3 ports. 
You wouldn't be able to use them the same way in the code blocks 
for instance. This is because for R3 ports the position is a property 
of the port rather than the port reference, so those set-words would 
be setting the word to the numeric index of the current position 
of that port, and the get-word would correspond to seeking to that 
index. In the code blocks the words would only contain integer! values 
- you would need a separate reference to the port for them to make 
sense.

The new port model would make PARSE on ports completely different. 
You would only be able to parse seekable ports if you want to use 
set-words and get-words, and you might just be able to rely on the 
internal port caching. This might be easier than we thought.

By "something like block parsing", I mean ports that return other 
REBOL values than bytes or characters can be parsed as if the values 
were contained in a block and being parsed there. Any buffering of 
these values would be handled by the port scheme code. Only whole 
REBOL values would be returned by such ports, so any inner blocks 
returned would be parsed by INTO as actual blocks.

Actually, there are no [ and ] in REBOL blocks once they are loaded. 
Block parse works on data structures.

There are three operations that can cause you to change your position 
from the standard foward-on-recognition: get-words (:a), alternation 
( | ) and REVERSE. You can check for alternation because it will 
always be within the current rule block. Get-words and REVERSE may 
be in inner blocks that may change.

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
]

I could probably save that p position word using FAIL and backtracking 
:)

Here's an revised version with more of the PARSE proposals:

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

                (ds: d) ; This maintains a recursive directory stack
                [ ; Save the position through alternation

                    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
					fail ; Backtrack to the saved position
					|
					into block! r ; Now recurse into the new block
				]
                (d: ds) ; Pop the directory stack
            ; Otherwise backtrack and skip
                | skip
            ] ; end any
        ] ; end use
    ] ; end parse
    res ; This is the expanded directory block
]

Show an example string that requires that hack and maybe we can help.

comes from data using seperators instead of terminators ... I use 
'|  and have  a command line "tailpipe" script to fix data

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.

hum (i have to be a little bit rude), i just read your response on 
rebol.net about the opportunity to turn or not return into a more 
genralized EMIT functions (as i proposedl).

I will not discuss about the difficulty to implement that idea (i 
don't have the sources). But what i can say, is that a COLLECT behaviour 
will be more usefull than all return break/return stuffs u posted.

Have you inspected scripts in Rebol.org recently ? If u had done, 
you would see that many coders use parsing  to collect data.

The problem Graham, is that  when i read your arguments, i have the 
unpleasant impression that your are alone to decide if an idea is 
bad or good.  

The narrow minded sentence " Incorporating COLLECT and KEEP into 
PARSE is both unnecessary and doesn't help at all for building hierarchical 
structures" suggest that you had not  widely used parse in your code. 
 I don't think you are the best  people here to made these choices. 
Many script contributors on Rebol.org have made some masterfull piece 
using parse (not you).

So when you reject an idea you should be more sensitive with this 
simple fact: many poeple  here  have an equal or better  experience 
whit  parsing than you.

uhmm, well, Steeve, as for me, if my proposal is going to be implemented, 
I don't care if I am credited or not. Because - parser REPs are floating 
here or there for some 8 years maybe :-) As for BrianH and his judgements 
- he might not be better in parse than others, but I would not try 
to upset him - BrianH is our guru here. Along with Gabriele, Cyphre, 
and after loss of Ladislav, he is one of the most skilled rebollers. 
I think that his intention is to help REBOL being better. He might 
be also the one, who will bring JIT or compiler in the future, and 
he understand consequences of what he suggests ...

I have to ask - what ppl are you referring to, regarding rebol.org? 
Why they are not here, or posting to blog? BrianH might be quick 
in his decision, because Carl selected him to collect the ideas, 
so let's forgive him a little bit of guru behaviour :-) And in the 
end, it is Carl who decides, if REP is going to be implemented or 
not. If you have another pov on some REP, why not to talk about it 
here, where more ppl can judge?

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.

However, most of my contributions to REBOL.org were lost during one 
of their reorgs years ago and I have been mostly contributing in 
other ways lately. Like helping people out here and writing REBOL's 
mezzanine functions. I barely go to REBOL.org anymore except to search 
the code there for mezzanine usage so that I know what is safe to 
change. Outside of work that goes into REBOL community projects, 
most of my scripts have been either one-offs or under NDA lately. 
Sorry.

Oh, that was your suggestion? I thought it was Henrik. It's on the 
list, and thanks for the link :)

I forget sometimes that the REBOL community has been around long 
enough that many of the people from the early days aren't here anymore. 
I guess a lot of people don't remember me from the latter part of 
the REBOL 1 days and think I am a newbie. Sorry :(

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 :(

Pekr, Gabriele, Tomc, yourself and I are probably the longest Rebolers 
here these days

Strangely enough I wasn't talking about code I had posted that you 
might have used. In the early days before REBOL.org, I tended to 
post code to the mailing list. The code that you would have used 
would have been in REBOL itself - I used to give very detailed messages 
to feedback about mezzanine bugs, usually with rewrites. Many of 
those rewrites made it into REBOL, especially in the 2.5 version. 
Some natives too (to-local-file and to-rebol-file were based on REBOL 
code I wrote and posted).

Right now the driving force is building better dialects - Carl needs 
it for the new GUI dialects. The data parsing improvements have just 
accumulated over the years and now seems like as good a time as any, 
especially because of the R3 compatibility break.

I can't shut down that website - my account was canceled more than 
6 years ago and I can't access it. If you look elsewhere on the site 
you will find the only site on the internet with the Oberon Compiler 
for DOS - the developer disappeared without a trace.

I should just say that I really appreciate the enormous amount of 
energy that BrianH has put into this project (and generally). I can 
see there's a lot of work to manage all the proposals.

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 ...)

I just want to be able to better parse XML namespaces and all.

and my english is to poor to dealing with experts

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 :)

Almost all of the proposals in the Parse Proposals page are derived 
from Gabriele's parse REPs page. Most of the subsequent requests 
were covered by one or more of those REPs. We had a pretty exhaustive 
discussion about the subject years ago and PARSE hasn't changed since, 
so its problems and limitations have been mostly the same.

I am not being pretentious - I really did come up with those proposals 
on my own before the first comment was made to the blog or here. 
I have been asking for more proposals but so far there haven't been 
that many that weren't already covered. And it is not a problem for 
me to reject proposals - it is my job. I've already pushed through 
more proposals than Carl is comfortable with, but I have hope that 
they will be accepted. Please give more suggestions, but consider 
that they will be debated before they will be accepted. Only the 
best would even be considered by Carl (he's got more stringent standards 
than mine).

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.

However, every proposal in the wiki through REVERSE has been reviewed 
and discussed by Carl and were only added after he liked them. The 
latter ones were added the next day, based on my own ideas and those 
of Peter Wood.

I have run out of ideas, and am asking for more. Through discussions 
with Carl I have a pretty good idea about what would be rejected, 
and what has already been rejected. If you want to make more suggestions, 
please review the proposals that have been made already in the Parse 
Proposals wiki and Gabriele's REPs. If your suggestion is covered 
by something suggested in one of those places you can be sure that 
they have already been debated to death. If not, I'd love to hear 
it :)

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

The INTO and CHANGE proposals were made after I checked with Carl 
that keyword modifiers were workable.

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).

Maybe that and a few other restrictions could be enabled when a /safer 
refinement is used.