AltME groups: search

Not a weird name, it is the closest equivalent to a logical and that 
you can get in a backtracking system. The only weird part is that 
it is prefix instead of infix. However, if you remember that *all* 
parse operations are prefix (except | ) then it won't seem so weird.

=> needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all:

- The a is matched first, and if it fails it backtracks and advances 
to the next alternate (aka, past the next | )
- If a succeeds then the next rule is processed.

- The next rule is =>, which matches its argument rule and then skips 
the next alternate, whether the rule succeeds or fails
- b is the argument rule of =>
- | c is what => skips

Because that is how you can check that the current value is a block! 
AND matches into rule.

re: => needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all ... I thought, that underlying C level can decide, if 
something can be prefix or infix = match a and look if next keyword 
is =>. But then it would mean, that we would slow down parse engine? 
Because then we would have to perform such check for each rule applied, 
to check if eventually => follows?

Because that is how you can check that the current value is a block! 
AND matches into rule.

 - remember that one for the docs. There will be many stupid users 
 like me, trying to understand, what the heck AND is doing and why 
 it is doing so = we want to have description theory why it is the 
 way it is :-)

The evaluation method requires that operations be prefix - it's a 
state machine. The only carried-over backtracking state is used to 
implement | alternates. It would double the complexity of PARSE to 
make another infix operation.

I've learned a lot about the implementation of PARSE this week. I'm 
almost to the point of being able to write it myself.

I was also inspired by one script, and now I dont remember which 
one, which used something like ---> in combination with some indentation, 
but maybe it was just a debug output ...

>> ? split
USAGE:
	SPLIT series dlm /into

DESCRIPTION:

 Split a series into pieces; fixed or variable size, fixed number, 
 or at delimiters

/into is a new refinement for most series. It makes it possible to 
store the result directly in a series without copying. I've been 
watching BrianH jump up and down over this feature a few months ago. 
:-)

the 'dlm can be either a char/string for variable size or an integer 
for fixed size.

Ah thanks. That's a very usefull addition.

it seems that it's bound for a rewrite. perhaps the priority should 
be bumped.

write parsing CSV like input, there was a proposal to solve it via 
external function or decode-csv aproach, which could internally use 
parse.

I have a small CSV parse and CSV generator library that we could 
start from.

SPLIT has too much useless options and use other mezzanines (COLLECT) 
in his code, it why it's not a good mezznine to my mind.

I have a proposal - I think that we all know, that View engine itself 
needs few enhancements, which would be nice to have for the official 
3.0 release. I would like to create wiki page similar to Parse proposal, 
to which we could contribute our requests. What do you think?

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

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.

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

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

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.

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.

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

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

First, it's easier to get a Core completed, so that those of us (and 
I include myself) can start using R3 for our servers and other such 
tasks.

But I think there's a bigger problem.

We need to find a way to unify various efforts related to REBOL. 
 For example...

We need people like Doc or Ashley helping to make, for example, a 
DB better integrated.

In one blog thread I pretty much outlined, what really is important 
for ppl. Features at least on pair with R2. Some of them more than 
others:


- CGI - not working under Windows (unicode problem with print -the 
header has to be in ASCII?)
- fixed 'call
- networking (BrianH plans to revamp Schemes)

- console (well, maybe we can live with the current one for a while)


- Some guys are screaming for first words of concurrency. E.g. Doc 
could start with port of Cheyenne - premium REBOL product. Not so 
with missing protocols an concurrency not in place ...

The victory would be in speed and the fact that your replacement 
code was missing a :here, but your suggestion is nicer I suppose.

The more basic problem is: we cannot do both. So, we must decide. 
 I kind of like Steeve's suggestion, because the old method is always 
a fallback for people who need more advanced methods.

Pekr, let me take each of these points, one at a time....

I plan to make the scheme dialect a little nicer to help with that.

2. "Networking/Schemes" - I spent a lot of time on the Scheme model, 
to purify and simplify it compared to R2.  So, I'm not sure what 
BrianH is proposing yet.

Just a tweak of the dialect. The implementation is good.

So: task! is a thread, undefined sharing model, undefined intertask 
comm model. That's what we have so far.

The host level can provide a more direct mechanism for inter-task 
sync and comm.

Carl, about parse, is that a pain (in the ass)  to have access (read-only) 
to the rule stack  while parsing ?

I'm not a fan of locking, but sometimes it's necessary. Otherwise, 
mods can be "cloned" for multi-task uniqueness.

I figured out how to do PARSE on seekable ports, so that might handle 
a lot of the problems.

We need a way to make the "todo list" accessible and we need users 
to help us maintain it.

Carl, you mentioned a while ago that you urged us to work on the 
docs. Does this mean we can fill out the function reference with 
examples without them being overwritten?

In R3 chat, plls a referenced web address.

Pekr, for some things, I need more of a todo list rather than message 
thread.

Carl - R3 Chat is not nowhere, no? It was created to be a developer's 
tool too. But - we can make projects-plan.html a wiki page, so we 
can edit it and fill it with detail?

It's a secret :)

Carl - because you said you need more than particular thread posted. 
So I replied, that R3 Chat was supposed to be a streamlined and isolated 
Dev comm channel for us, and as such is not "nowhere", but now I 
can see I mixed two your replies, so forget it ...

Steeve: Well, then perhaps it's time for a blog to make afinal decision.

(I will attempt to do so today -- a busy day.)

That was one of the original parse proposals, Steeve, from 5 years 
ago. If those functions could take arguments and have local vars, 
almost all of the parse operations could be replaced with such functions. 
There was even a suggested rule! function type.

i don't think it needs a special function type.

Pekr, I am not sure how the "community" can edit the project plan... 
It is better to simply mention what edits are needed, and we can 
updated it quite rapidly (it's built by a REBOL script.)

it's a function ? parse execute it and use her result as a rule

If you use the docs wiki, a trusted subset of the community (read: 
no spammers) can edit it.

I was thinking just a "Note" column. We can use it for whatever.

WRT editing the function reference, I suggest we simply go through 
them, one at a time alphabetically, which is what I'm doing now. 
I already found a few bits that needed change.

I suspect community involvement in R3 will increase once there's 
a modern communication channel.  Asking people to participate in 
some shell based chat is really retro.

The other issue is that for many things .. R2 is good enough .. a 
bit like XP users not wanting to upgrade to Windows 7 :)

Just edited the parse proposals, based on recent discussions. Added 
a STAY proposal, renamed EITHER 2 to THEN, added the controversy 
to the priorities section.

by naming => to 'then, we also probably lost the advantage to combine 
it with numerical value allowing us to choose a "branch"?

It will look silly with the numeric branch, but the functionality 
will still be there. Plus, it will look better with a rule1 that 
includes IF.

It's simple: Either the license will be acceptible to me, or I'll 
switch languages or make a clone. No problem :)

Only blind can't see the advancement R3 took in last 1/2 a year. 
Hundred of tickets addressed per month ....

It won't be a pure erlang-style shared-nothing approach, but the 
message-passing will be there. We can optimize accordingly.

In alpha 83 we had a (broken) implementation of the REMOVE 2 proposal. 
In alpha 84 we will have REMOVE 1 instead (Steeve recreated this 
proposal). Let the best proposal win - I'm hoping for REMOVE 1, since 
it's nicer (if less powerful).

It's a really high priority.

Then let's have REMOVE 1, to make Steeve happy :-) He is right that 
index aproach still can work in terms of storing a position into 
variable and doing REBOL level remove in parens ...

Look in the port model docs - they talk a lot about devices. The 
only thing added will be the ability to write your own.

BrianH and I work together well, but the two of us alone are not 
enough!

.... It's about 10  years the rebol ommunity tells you can't do all 
alone and you need to open the source code... this doesn't means 
the final integration word is not yours... This doesn"t mean that 
you will have 100% ready to go additions. This doesn't  mean that 
rebol VM  will be stabilised to less than 1Mo ... More you have embeded 
feature hard written in the VM bigger it is that's why the "extension" 
approache is good.

Then the VM can be seen a minimal execution environement able to 
run any ind of things ... that the way most of the "regular" script 
languages works.

and i think parse is already a big enhancement compared to regular 
expression ( i give a try to it past week writing a software in ruby 
... that's horrible ... I mean i'm complaining about parse but regular 
expression is so much a bore and stupid to write + they don't allow 
any action they are just made for match  only way to have regular 
expresion doing something is in ruby using them with an action mathod 
of the string class..... And that the kind of stupid things most 
of  coders in the world today found fantastic ??? HOOOO  really ???)


So when we come from mystring.match( "/\d\w***.*" ) kind of things 
of course going to the match action parse way is complicated... but 
complicated maybe not the way it's supposed to be.

Parse works better on "tags" words matching more than cabalistic 
formulas like regular exapressions. This doeasnt means it can't be 
doing that too..

what i have real difficulties to figure out in parse is the index 
system... I have a problem to see where i'm  and what my actions 
is doing.  do i "store index match then action" or do i  "match store 
then action" ? And if you add to that the sub rules i'm like completly 
lost. Cause in some cases sub rules can trigger their own particular 
special only for them actions ...

In the past Carl seemed to skip building the "big" alpha releases 
for OSX and Linux until the Windows has been tested. I would guess 
that we'll see a84 or a 85 for OSX.

The OSX version of Rebol3 is missing things that are in the Windows 
version (extensions) and has a number of bugs such as no internal 
event handling so that wait consumes 100% of the CPU, server ports 
don't work (probably related to no internal event handling) and call 
doesn't work properly.

'k, will be patient.  I've a small project set aside...

R3 will run as a CGI under OSX though, it doesn't yet do so on Windows.

about chat ... i always said it was hard to have a precise location 
of interresting exchanges ... but that's the same in altme...  in 
fact any discussion here or in chat when it pops out interresting 
ideas should then be resume into a temporary task list  but ... that's 
normal most of the time discussion here are mixed we don't only propose 
enhancements we try to figure out how things works then  we try to 
give how things could or should be working in order to make our lifes 
easier... It's a difficult task to keep tracks on every good idea 
passed throught altme or Chat  system...

i don't understand the "it will work as cgi ..." does it means outside 
an apache server and through a html page rebol won't work ? then 
rebol would be something like a custom php ?

There's barely a client. Web server support was originally intended 
to be built in, but we'll see whether the work gets done. Openning 
the source doesn't magically provide more people to do the work. 
We need help.

Why does this take over a minute to complete?
    dt [
        parse [1] [some []]
        ]

(There is a similar time issue with R2)

A SOME or ANY rule that does not advance is an endless loop. [some 
[]] is equivalent to [some [none]].

can this not be fixed? I can't see why one would want such a rule.

and I imagine a lot of beginners getting stuck in this.

It's a documentation problem, not a dialect problem. Parsing is only 
a beginner task to a limited extent.

I disagree on unfixing this. It's hostile towards the beginner to 
allow hanging the parser and I ran into this quite a few times, before 
finding out what went wrong.

Parsing is not a beginner task. There are many ways you can shoot 
yourself in the foot with PARSE, and we just added more. Live with 
the fact that some concepts require some explanation :)

some [remove "a"]

oh, I find the new stuff makes much of the engine much less exponentially 
guru level.  its like... in R2, parsing a number in a string is easy... 
extracting a chain of them requires some thought, beyond that... 
people bleed from their eyes   ;-)

if a rule constitutes the part in the block and the block is empty, 
I don't see how that is useful.

as steeve says... forever [] isn't usefull either.  at some point 
you have to understand a bit of what you are doing.


the only thing that really happens to me is hitting the end, and 
not realizing that something in my some or any is preventing the 
rule to go "past" the end.

It's irrelevant. Empty rules are easy to debug, so that won't be 
a problem for beginners. It's when complex rules don't advance that 
is the problem.

Ladislav: I don't know? It seems like a good idea and it's a bad 
way to pause a script. Rather use WAIT. But it's unrelated to empty 
rules as they are a side effect of PARSE.

and there is a more common error which cause endless loop in parse
some [... | ....| .... | ]   <- nothing after the last |

precisely what ?
you can't establish a list of all the bad coding practices

Steeve, there is an empty rule. (it seems that we can't agree what 
a rule actually is)

(become none or are suddenly filled with a condition which enables 
an exit)