World: r3wp

Docs in the main screen are part of the app, though if they're too 
complex they can slow down the usage of the app. But my work has 
mostly been business apps. I often will make an app suite rather 
than a single complex app, just to make them easier to use. Every 
hour spent making the app easier to use saves you hundreds of hours 
of training. It's worse for consumer apps with competitors, because 
being too hard to use will lose customers.

Native or mezz implementation is irrelevant in R3, agreed, whichever 
is more efficient. But the rationale of SPLIT's dialect seems confusing, 
particularly as it relates to negative numbers. Any reason keywords 
weren't used instead?

I understand the reasoning, and agree completely. I do app suites 
as well, but the main app is then usually a "control center" with 
built in docs.

The original design used negative numbers to skip backwards. I don't 
think I changed the design, but I understand the reasoning behind 
how they work now. Keywords were probably not used as it would have 
complicated the dialect. Well, it would have made it a dialect which 
is really isn't today.

Carl may have done that. He likes that sort of thing.

This brings up a good point though. Do we consider a function dialected 
if the behavior is controlled by datatypes? SPLIT does have the case 
of a block of integers having more fine-grained control, so there 
is a dialect option there that could easily be expanded.

I have to run, an will be offline for a week. I would LOVE to see 
alternate implementations and designs for comparison. We can talk 
a lot, but if we can compare two options side by side, it often makes 
it easier to say which one you like better, rather than discussing 
costs and benefits in the abstract.

Great chat Brian. Stimulating as always. Thanks!

The non-dialected behaviors seem simple enough (for the purposes 
of discussion I've read the docs). The problem is in the dialect, 
especially these:

- "Negative values can be used to skip in the series without returning 
that part:"  Why not use a 'skip keyword for that?

- "Note that for greater control, you can use simple parse rules:" 
 Which ones?

It really is a dialect, but the language is not confusing (first 
case) and not well defined (second case). Using keywords would make 
the dialect easier to understand (and thus use), and potentially 
more efficient to implement using command dispatch.

is not confusing -> is confusing

There is a conceptual conflict between the treatment of splitting 
into parts by length and splitting by delimiter, that has the effect 
of limiting both sets of behavior. It would be better to put the 
delimiter splitting into a separate function called DELIMIT. This 
would allow the dialected variants of SPLIT and DELIMIT to develop 
separately without conflict, and make the SPLIT dialect easier to 
understand. Then you would have two relatively simple functions with 
a clear distinction between them.

So, You want to split split

Yup. I'll try to mock something up later this week.

BTW doesn't the current  SPLIT have a bug?

>> split "1,2,333,4444,5555" #","
== ["1" "2" "333" "4444" "5555" ""]

Note the last empty string in the result.

Yeah, that's annoying. I vaguely remember finding out that it was 
designed this way

Carl asks whether anyone has looked at the WAIT problem under Linux?

And if anyone has a clue where the problem could come from.

That seems like a message from a different planet :-) It's been quite 
long time, since someone worked with R3 imo. Is there any related 
ticket?

A message about WAITing is quite appropriate ;-)

delightfully ironic that its Carl asking us about waiting  :-D

It's been quite long time, since someone worked with R3
 - certainly true, if you replace "someone" by "I, Pekr"

I suspect Pekr is referring to the R3 core development vs R3GUI ...

Ladislav: it really does not matter, how accurate is my message or 
your reply. If we want to be 100% correct, than you are of course 
right :-) My message was a general claim meaning, that even in the 
time of active R3 development, there were not many ppl using R3, 
and there was even less ppl using R3 actively under linux imo (which 
is quite logical, as for a long time R3 was primarily developed for 
Windows only). 

Is there any related ticket

 was important part of the message re possible WAIT problem underl 
 Linux. The only possibly related is http://curecode.org/rebol3/ticket.rsp?id=1861&cursor=2


So - before I download R3 for Linux, drop it to my linux server, 
and spend my time experimenting, my question could translate as - 
what should be the mentioned problem with WAIT under Linux all about?

The fix seems to be under way by Carl himself.

Good to hear that. Could someone please remind me, what was/is the 
status of hostkit repositories? IIRC, there was some experimental 
version from Carl, then IIRC some ppl established their own repos. 
Which one's the official one?

Pekr, the official hostkit sources are the one available for download 
from rebol.com (http://www.rebol.com/r3/changes.html).

The WAIT-related ticket is cc#913: http://issue.cc/r3/913

ah,I saw the ticket, but that's OSX related, no? Carl was asking 
about the Linux,but maybe those two OSes share the same WAIT symptoms, 
as can be seen in the comments ...

That ticket is for Linux as well: every platform without an event 
device is experiencing that issue. That is every platform but Win32, 
at the moment. I would have changed the ticket title already, if 
I could.

Hmm, so chances are, that Core might finally get some event/timer 
mechanism, even if used without the GUI? :-)

R3/Core for Win32 already has the foundations for such a mechanism 
(the aptly named event device).

Apropos serilization and constructs, we discussed in the "Core" group. 
Is this expected behaviour?

>> make string! #[true]       
== "true"

*serialization*

would you expect something else? each little type conversion has 
its own idiom.

IMHO converting to string usually is meant to be used more like FORM 
than anything else.

there are some details which make the datatype conversions different 
than other forms... such as block to string.

Cyphre, my fix for the SPLIT bug is above in this thread, which prompted 
the long discussion on it.

Brian, DELIMIT means something very different to me. My DELIMIT func 
inserts delimiters.


I don't have a problem with using a 'skip keyword. As I said, the 
current behavior wasn't the original design and may be Carl's doing. 
Check with him on that.


There is a conceptual conflict between the treatment of splitting 
into parts by length and splitting by delimiter...

 -- I don't see that, but I'm biased. I'm always happy to see alternative 
 designs.

I checked a half-dozen online dictionaries to get that definition 
of DELIMIT. Perhaps you're checking different dictionaries.
The conceptual conflict:

- Dialected splitting has incompatible dialects, which makes both 
more limited than they should be.

- Splitting a block based on a delimiter of one of the types used 
by length-based splitting isn't allowed.

I think that the word for inserting delimiters the way your old DELIMIT 
function did is "intersperse", but we can do better than that.

DELIMIT sounds OK to me for inserting delimiters, with TOKENIZE probably 
its reverse

what about SIFT ?

That sounds identical to FILTER

It will me (me at least) to make things concrete. Put together your 
versions and we can all compare and discuss A versus B.

http://en.wikipedia.org/wiki/Delimiter


I'm open to better words, but INTERSPERSE implies an element of randomness.

It will me
 == "it will help me"

(I need help)

Oy. You get what I mean...I hope. Time to sleep.

wouldn't DELIMIT/ENLIMIT make sense? We have already en/decloak, 
de/encode, de/enbase, en/deline ....

Hm, good suggestion

delimit:  set, mark, or draw the boundaries of something 

ENLIMIT doesn't make sense to me.