r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

BrianH
13-Oct-2009
[4476]
Well, a89 isn't out yet (when last I checked). Beyond that, it depends 
on how Carl reacts to the recent blog on the parse plans.
Pekr
13-Oct-2009
[4477]
So according to his doc, we should get BREAK/RETURN and DO?
BrianH
13-Oct-2009
[4478]
We don't need BREAK/return anymore, but he can reuse the code he 
used to implement the RETURN paren operation. I hope we get DO, but 
Carl was iffy since few were puushing for it. Gabriele's been silent, 
which is weird since it was his idea.
Pekr
13-Oct-2009
[4479x2]
Carl should not judge upon his own usage of some features ...
But generally - the level of feedback is lower and lower. We need 
to get R3 into beta with requested features in few months, as we 
are starting to loose ppl being interested ...
BrianH
13-Oct-2009
[4481x2]
Um, yeah, but he should about OF (as ALL). What he wanted to do with 
OF was important.
The level of feedback? It's been a discussion. When it comes to PARSE, 
the discussion has pretty-much resolved itself.,
Pekr
13-Oct-2009
[4483]
Yes, that one might be missed. Dunno why he wants to remove it. Also 
LIMIT would be nice to have ...
BrianH
13-Oct-2009
[4484]
He is wary of adding it because he knows how difficult it would be 
to implement it. LIMIT too :(
Pekr
13-Oct-2009
[4485x2]
well, otoh we lived without OF for so long. I think it can be done 
in a conventional (recent) way :-) I think that Carl should dedicate 
few more days to finish parse and move on to Extensions :-)
... because that is the way to release host code ...
BrianH
13-Oct-2009
[4487x4]
The conventional way has exponential overhead.
All PARSE needs is a few final decisions. I expect that it won't 
be too difficult to do the rest, at least the rest that won't be 
put off.
The DO operation was proposed 5 years ago, before R3's change in 
the behavior of DO/next. The new DO/next is much better suited to 
the parse workarounds than the old DO/next was. We can thus do without 
the DO operation if need be.
The BREAK/return proposal was proposed before Carl added the RETURN 
paren option, which makes BREAK/return unnecessary.
Pekr
13-Oct-2009
[4491]
OK, so we are almost done with parse, right?  (As I don't expect 
Carl changing his mind about the deferred proposals, at least not 
for 3.0)
BrianH
13-Oct-2009
[4492]
The only still-missing proposals that aren't easy or efficient to 
work around are OF and REVERSE. They will be missed if not included. 
Unfortunately, the same reasons why they will be hard to work arond 
if missing, are the reasons why they would be difficult to implement 
:(
Pekr
13-Oct-2009
[4493]
btw - what is the outcome of so called - complementing? Will we get 
it enhanced, so that we can use it even with Unicode? I noticed Carl 
said that complements could be enhanced ....
BrianH
13-Oct-2009
[4494x2]
I expect that PARSE release features will be done in a89 - the rest 
will be bug fixes.
One of the bitset! bugs was fixed in a88, but complementing is yet 
to come. It will probably be the using a bit for a flag method.
Pekr
13-Oct-2009
[4496]
Shouldn't be such enhancement part of the proposal doc? (just in 
order to have it documented :-)
BrianH
13-Oct-2009
[4497]
Yes, it should. Care to add it?
Pekr
13-Oct-2009
[4498]
I can add it, just not sure I would describe it precisely :-)
Pekr
14-Oct-2009
[4499]
Carl asks about the usability of Until proposal - if not answered/defined, 
it will not be part of 3.0 -  http://www.rebol.net/r3blogs/0271.html
BrianH
14-Oct-2009
[4500]
Did an initial answer, but Ladislav really needs to expand on it.
Pekr
14-Oct-2009
[4501x3]
hmmm ....http://www.rebol.net/r3blogs/0272.html
Interesting how Carl asks for naming convention opinion, there was 
no single vote for 'loop, yet such word was chosen ;-) http://www.rebol.net/r3blogs/0273.html
We have one hour to decide, if we want 'loop being renamed to 'while 
....
Graham
14-Oct-2009
[4504]
Tim Berners-Lee is quoted today to say that he can't think of a good 
reason to keep the // in http://, and that if he did it again, he 
would have done without them.  I wonder if he spoke to people who 
write parsers ....
Gabriele
15-Oct-2009
[4505x2]
the reason for the // is to allow relative paths like: //www.rebol.com/ 
  where the scheme is the same as the base url. Nobody has ever used 
this; also, it could have been achieved by using :www.rebol.com/ 
instead... so, yeah, it was not really a good idea. I also don't 
think ftp:file.txt (meaning, change scheme, but keep host and path) 
has ever been used and not sure it's supported by software. so in 
practice http:www.rebol.com/ would have worked.
it has to be said, that the www subdomain is also a silly habit.
Pekr
15-Oct-2009
[4507]
As for parse docs - why is 'then not being among the keywords? Isn't 
it a keyword?
BrianH
15-Oct-2009
[4508]
It's an operator, like |, and mentioned in that section near the 
top.
Pekr
15-Oct-2009
[4509]
isn't AND operator too for e.g.?
Chris
17-Oct-2009
[4510]
First pass at converting my AltXML to R3: http://www.ross-gill.com/r/r3xml.r
-- almost a literal translation, doesn't yet utilise new  parse features...
Pekr
17-Oct-2009
[4511x2]
The DO keyword was added to A91 - Gabriele should be happy now :-) 
http://www.rebol.net/r3blogs/0276.html
http://www.rebol.net/r3blogs/0277.html- Trouble renaming BREAK to 
ACCEPT in following case:

some [break | "b"]


.... where it returns FALSE. Carl seems to suggest, that unless that 
case is solved, it can't be renamed ...
Maxim
17-Oct-2009
[4513]
gave my two cents on the blog... hehehe
Pekr
17-Oct-2009
[4514]
Max - we are close to finish parse. It is clear Carl will move to 
other priorities. Sorry to hunt you here or there, but any chance 
you get your Extensions short doc done? No doc = no callback probably 
:-)
Maxim
17-Oct-2009
[4515]
I really want to do it... but I'm so deep into parsing right now 
I don't want to loose the few GB of information in my brain's cache. 
 I'm writing self-modifying parse rules and its pretty nightmarish. 
 although it works.
Gabriele
17-Oct-2009
[4516]
Ah, 6 years of wait finally over. Now, if we could get those changes 
ported to R2...
Maxim
17-Oct-2009
[4517]
hehehe you finally got your DO  ;-)
Henrik
17-Oct-2009
[4518]
Do we have a list of PARSE changes that are no longer compatible 
with R2? I think that would be important in porting parse scripts 
from R2 to R3.
Pekr
17-Oct-2009
[4519x3]
Gabriele - wrong perception :-) The correct claim should be - "An 
now nothing prevents me from fully switching to R3 ..." :-)
An=And
So - we don't need complementing to be enhanced? Because we talked 
about it, but it is not defined in proposal, it is not part of Carl's 
feature table, and I also got no reaction on R3 Chat ....
BrianH
17-Oct-2009
[4522x2]
Gabriele, these changes can be backported to R2 in the form of a 
rule compiler that generates (unreadable) R2 parse rules.
Pekr, we still need complementing to be enhanced. Even Carl has said 
so.
Maxim
17-Oct-2009
[4524x2]
but wouldn't work with remark  ;-)
one situation which complemet can't handle very well (ram wise):

union charset "a" complement charset "b"