AltME groups: search

Still, if assocs are drastically faster it would be worth it. I could 
use blocks or lists and assoc indexes if I need them.

Assoc indexes to lists would be useful, as useful as I've found hash 
indexes to lists to be. I'd use hashes and lists more often if block 
parsing worked on them.

drastically faster

 - I think, that REMOVE and INSERT can be made faster by not "shuffling" 
 data as often

for remove, dont use it, clear the values instead. and have some 
way to recycle them.

if i loose the block-functionality i even prefer such hacks. and 
i never needed that remove-tuning, only figured it out for some benchmark. 
Where it paid of only with large data. And with large data, maybe 
i want the hash on disk anyway?

Jamie, that was referring to using a hash as a table rather than 
as an index. If you use a hash rather than a block for your table, 
all of your searches would be faster without needing any seperate 
indexes. The only way to have the speed of searching a block be comparable 
would be to keep it sorted and use a binary search (what RebDB does 
I think), but that doesn't help much with multiple keys that require 
different sorting orders.


On the other hand, I've been sold on the idea that when you use a 
hash as an index (rather than the table), you are basically using 
it like an assoc, so using a structure optimized for that behavior 
would probably be best.

As for the hash (or assoc) index and list data combo, it has some 
advantages. When you are inserting and removing data a lot lists 
have a known speed benefit but the real advantage as far as indexes 
are concerned is in how lists handle series offsets (I'm using the 
word offset here because I'm using the word index to refer to the 
external hash/assoc index).


Blocks encode their offsets as a number offset from the beginning 
of the series:

>> a: [a b c]
== [a b c]
>> b: skip a 2
== [c]
>> index? b
== 3
>> insert next a 'd
== [b c]
>> b
== [b c]
>> index? b
== 3

List offsets are pointers to the associated list element.

>> a: make list! [a b c]
== make list! [a b c]
>> b: skip a 2
== make list! [c]
>> index? b
== 3
>> insert next a 'd
== make list! [b c]
>> b
== make list! [c]
>> index? b
== 4


If you are indexing your data and your data in in a block, you need 
to update your index with almost every insertion and removal because 
the references to latter positions of the block in the index will 
be invalid. With list insertion and removal, external references 
are likely to still be valid unless the referenced elements themselves 
are deleted. If you are sure to delete the reference from the index 
(or replace it with nones) the rest of the index should be OK. New 
index references can just be tacked on the end, or put into the first 
empty entry. This makes live indexes a lot more practical.


On the down side, if you are using lists and they are long enough 
to make linear searches impractical, you really do need an external 
index for them to be useful. Also you need to balance the overhead 
and complexity of keeping the indexes updated against their benefit. 
This technique is not for the faint of heart unless you can get some 
guru to do algorithms for you.

You might want to wait for some more information about modules to 
be revealed before asking that question yet. As it is now, components 
are compile-time features of REBOL 2 that can be included or excluded, 
enabled or disabled, in one chunk when building a version of REBOL. 
Only RT and SDK licensees have any control over that.


Plugins and modules are features of REBOL 3 that haven't been documented 
yet (maybe not finalized either). It is unknown whether REBOL 3 will 
even have components at all, or whether they will be replaced by 
modules or plugins.

You're always at least three steps ahead of me, but my head hurts 
just thinking about it (a return from different instances of the 
recursion). :-)  


What about generators, like in Icon, that step through alternatives? 
I've never used Icon for real, just tinkered a bit, and that powerful 
feature seems to lead away from readability. I also don't have an 
example of how it might be done in REBOL, or if it applies to your 
question. 

I'm a big help, aren't I? :-)

Ladislav, I don't have time to think it all to the end, but an advise: 
Keep it simple!


I know, it's a very hard goal to reach, because we don't want to 
cut off possibilities. If it's possible for someone new to the language 
to use a feature like "function-local return" right away with expected 
result, and still the advanced programmer can use the feature in 
a way maybe not obvious at first, but that makes good sense, then 
it might be perfect.


But don't make the advanced programmer happy, if it'll make things 
difficult for the newbie.


recursive usage of the function that may request a return from different 
instances of the recursion

 sounds complicated at first. I think, you're right. We probably don't 
 need such a feature. If the code (C source) become simpler by including 
 the feature in recursion, then you might consider it though.

it seems to be the other way around - adding this feature may complicate 
and slow down the interpreter as it looks. Otherwise my observations 
are, that Carl is taking care to keep REBOL simple. (beginners don't 
need to use functions with local return at all)

Contexts are a good point. Spagetti: oi agree. Hard to see there 
is a hidden return when looking in 'f. But maybe 'catch could use 
contexts, or would that be overkill? Or, catch, explicit 'equal? 
and rethrow otherwise? (or was it 'same? have to look on the ML ;)

Ladislav: could you give an example of a controlfunction where it 
would be useful ? Now I know what it means, but don't have an example 
in mind, when/how I would use it. Nevertheless, I'm always for having 
concepts in the language which make things possible, which otherwise 
would be hard to achieve (or just by doing some tricks with other 
language constructs - note! doesn't necessarily mean the catch example 
- can't judge this). If a normal user won't be affected and it's 
ok with Carl and the implementation - why not having it?

Guessing: in recursion one typically goes into a function, guess 
a few ifs deep, does some work and returns. 
 either n > 0 [do-work exit][recurse n - 1]

If that is long, one ants to split that in multiple functions, indirect 
recursion
  f: func[n][  some-checks-or-return  g-checks n]
  g: func[n][either n > 0 [do-work exit/from f][f n - 1]
And that is not possible, one can only exit 'g itself.

'g-checks and 'g are the same, typo.

I understand control-function as  'forall and friends.

so the question or discussion is mainly about these two distinct 
types of return and not something else .... because to me it looks 
(outside of this use), also quite disturbing or weird if people start 
to leave a nested functions suddenly to somewhere maybe not immediately 
visible

MAybe some hinting in the control-func? How about a 'catch which 
knows its function-name? and throw/to res 'func-name? Would still 
be short. Although if he have
 a -> b -> c 
and c return to a, 'b must call in that way too.

Well. Lisp has only maybe two control mechanisms, one is tail-recursion, 
and the second call-with-current-cotinuation (kind of goto but with 
the context stack maitain). You can build any other control mechanisme 
from loops to preemptive-threading with this two constructs.

I've been wondering about an extension to EXTRACT as I haven't been 
able to find this particular functionality anywhere else. If it exists, 
then I'm wrong and you can ignore this.


I would like to propose adding a /size refinement to set the number 
of values extracted at each point. This would make it very easy to 
split a string in equal-sized chunks. It could also be used to retrieve 
equal sized parts of a set of database records. Combining this with 
/index, I think this could be very useful.

Here's how I would like it to work:

>> block: [1 2 3 4 5 6 7 8 9]
>> extract block 2
== [1 3 5 7 9]
>> extract block 4
== [1 5 9]
>> extract/index block 2 2
== [2 4 6 8 none]

The refinement at work:

>> extract/size block 4 2
== [[1 2] [5 6] [9 none]]
>> num: to-string 123456789
== "123456789"
>> extract num 3
== [#"1" #"4" #"7"]
>> extract/size num 3 1
== ["1" "4" "7"]
>> extract/size num 3 2
== ["12" "45" "78"]
>> extract/size num 3 3
== ["123" "456" "789"]
>> extract/size num 3 5
== ["12345" "45678" "789"]
>> extract/size/index num 3 5 2
== ["23456" "56789" "89"]
>> extract/size num 3 12
== ["123456789"]

/size would always return a block of series.

I also have a note that maybe /into should be the default behavior 
and /size or /part should be the refinement. It's an old func, and 
I don't use it too much myself. It can be handy at times though.

I need the opposite too, and call them 'enblock and 'deblock.

mainly incombination with 'union and friends.

Altme/REBOL3 is a poor place to keep useful functions: they have 
close to a  0% chance of being found by anyone looking via a search 
engine (only most recemt 300 messsages are visible, remember).....Though 
REBOL2 and the originla REBOL world are even tougher for anyone new 
to mine data from.
(Altme/REBOL3 is a great place to _develop_ useful functions)
***

The ML is slightly better. At least it is visible, though not very 
structured -- it can be hard to tell if you are looking at the latest&greatest 
version of a function, or just one of many interim revisions.
***

You are thinking of http://www.bigbold.com/snippets/tag/REBOL-- 
a code snippets library that Gregg has contributed to.

%index.r could then contain real code and play animations, without 
taking over.

Maybe add a little message-exchange, and konfabulatorisdone.

I think of Acrobat and MSAgent with regard to this--one instance 
of an exe that bridges all the instances.

I'd bet a lot of us have thought of that one. I haven't pushed for 
it, because it seems like the places I think I'd use it most would 
have exceptions in the other direction. That is, I want to reduce 
*almost* everything, but there are exceptions. I also thought about 
a version that let you specify the words you wanted reduced (reduce-only 
series words), and would do a deep reduce, then RT added /only, which 
works backwards from that, so I thought my idea would be confusing.

And if that fails somebody has that port open. (or some firewall 
goes angry or whatever, but that is another problem).

And use cgi only as proxy.

Should comparing chars be case-insensitive? Its the default everywhere 
else, i was surprised it is not. And '== is still there for exact 
match.

We put in our 2 cents here and there, and pretty soon it adds up 
to real money, so to speak.

Alright, off to Rambo then. (I recall discussions all about equality 
and strict-equal a long time ago.)

it is a pity, I would like to form a bigger picture - how all those 
things will be organised - library interface, plug-in interface, 
View - will it be just a component? What is /platform, etc.? So, 
patience and wait mode? :-)

Gabriele - are there any changes planned for port model, networking/files? 
And will R3 be properly async?

well, it depends. the Detective would have been *much* easier to 
write and debug with tasks instead of async-mode and callbacks everywhere.

hehe, at digg.com I read reaction of one user, who read about REBOL 
and seemed to be excited - his equation is:


Rebol = ((Perl + AJAX + [SETI-:-Home]) - (Bloat + Crap)) * (Extacy + 
Speed ^3)

How do you best support other languages from REBOL (if you want to)?

- Directly parsing other languages with their syntax from REBOL is 
a way to make old programs written in those languages run. You need 
to parse strings for this to work, and that may not be very fast.

- Making new dialects based on those languages, but with the minimal 
REBOL syntax may be good for new programs, written in those languages. 
One thing, that irritates me in other languages (also C) is their 
syntax. You have to write so much unnecessarily, and it's easy to 
make a mistake (e.g. put a ';' in a wrong place), and your program 
then doesn't work as inteded. All the extra also makes it less easy 
to read programs, written in those languages.


It's possible to make cross-compilers, that'll read old programs 
and produce a new format.

With REBOL, I feel, I can concentrate on the problem and not the 
technology, implementation, syntax or other things.

REBOL has saved me from doom quite a few times. Last time was yesterday 
when I lost a database of people signed up to a town party race (a 
system written in REBOL), when the power cord to all the PCs was 
pulled. The database was partially wrecked, but (believe it or not) 
by creating a LIST-VIEW and querying the database, it was possible 
to view and print out the contents. REBOL is so damn wonderful, it's 
almost hard to believe.

I don't use rebol for making money, but saving me a time by doing 
very small utils, which save time .... and so maybe money? :-)

Uhhh, parallel vector processing! If you get that working and can 
use the hardware to do the actual calculations, then you'll get lots 
of speed!

interesting discussion regarding modules starts, and some points 
are raised, mainly because of security.

Something to consider for REBOL 3: The current implementation strategy 
for symbols in REBOL has significant limits to the possible number 
of symbols available at one time. It might be a good idea to try 
a red-black tree for symbols instead - newLISP uses that strategy 
and can handle millions of unique symbols efficiently.

I'm just putting the idea out there - I'm not familiar enough with 
red-black trees to know whether they would be possible to use in 
this case, just that another language with similar implementation 
size uses them and it works for that language.

Just wondering if it would be possible for richtext command sequences 
to also fit into a word!, so symbols can have their own colour and 
font when molded into a richtext field. eg:
	word: to-word "/bPhrase"
Now when I mold word I see it rendered with bold text.

My concern is just to make sure that all the command sequences (like 
/b in the example) are allowed in a word!, and possibly also still 
allow  loading as a word! directly. eg:
	type? load "&bPhrase" ;== word!
(assuming the richtext escape character is & )

This could mean an editor could render symbols with their formatting, 
for instance. (I'm also thinking of implementing an interpreter within 
rebol).

but that is not the point. I just first could not follow, how they 
work with widgets, and then I found out - they have separated code 
and widget definitions. At first it looks strange .... it is like 
having 'feel(s) , event maintanance, app logic, without seeing what 
actually you are working with. But I do understand, why they keep 
widget defs outside in external file, which is kind of simple (as 
VID is), with static positioning - it is very easy to import to visual 
GUI builder ....

so just for the sake of inspiration, to think about - can you imagine 
having screen painter, taking your layout block, and enabling you 
to change the postions/size etc. params for our widgets, without 
actually being dependant upon running the app with live data?

just dunno what they do, if the want some kind of comuted values? 
Maybe they import just what is defined, you change layout, and after 
the widget is drawn, they can adjust, dunno .... just an idea, we 
imo need visual screen editor in future ...

I believe this is how Cocoa works and have seen the technique referrd 
to as "freeze-dried widgets".

widgets and their functionality are defined in .nib files for a cocoa 
program. this is because much of the binding between the widgets 
and the code is created during runtime. this is also why Interface 
Builder is able to create much of the initial functionality for a 
Cocoa GUI, just by defining attributes to widgets and let you test 
the interface to a fairly high level without compiling any code.

BrianH, do you know what structure rebol currently uses for holding 
symbols ? Red/Black trees are complex, so it will take a fair effort 
to implement and debug.

The difference between binary search trees and red-black trees is, 
that the latter only have O(h) if the height of the tree is small. 
Red-Black tries are balanced and hence can guarantee O(lg n) times. 
But there exists many other search-tree schemes that hold too.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/197938
-- looks like the Ruby approach to Unicode will be to use UTF-8/16 
as the internal string representation and convert from legacy encodings 
on read(/write?).

http://plib.sourceforge.net/

lgpl, uses in flightgear and torcs. Dont know about size, but all 
my  crashes where steering-related :)

Takiing into account the first made estimate (alpha in April IIRC?) 
and the time lag we now have, I think we won't see R3 final before 
September-2008. Other bets?

Yes, I know, nevertheless doing it "mostly" alone limits the pace 
we can move... it's still the same problem. Within production optimization 
I would say: We have a capacity, lot size (the different tasks) and 
setup time problem to solve.

RT is not the only company around that has delays in shipping a product.


One of the reason, why it feels painful, is because of the tight 
community and the up-close-and-personal feeling with Carl.

Well, yes, he takes his ball and goes to france!!

I strongly doubt that RT would be wasting time. It's just that there 
is so much to do and R3 is one component in a large amount of software. 
Had this been some single-purpose program (like LIST-VIEW), we would 
see more rapid fire releases. :-)

rebservices needs patches and patches need mre readable source.

Better to patch and continue and then tell RT what the bugs are and 
possible solutions.

Well, if community is a bit tight, then I would expect a more tighter 
relationship ... the thing is, that even blogging slowed down, and 
sometimes we can see blog posts, just buying Carl a bit more time 
imo :-)

one thing I don't understand fully is, that many blog articles open 
some questions, ppl are invited to discuss, yet I miss some decisions 
being made. Hmm, they surely are made, but without single statement, 
so we just can guess, how e.g. Unicode (and other things) will, or 
will not, be supported ...

And for me not shipping isn't a major problem ...

As Pekr has said, there are questions raised on the blogs, people 
answer, and that's that. Just a big black hole where everything disappears 
seemingly forever.

RebServices, RebCode, they are released as a preview, people are 
asked to use them and tell about problems they find. And then what?

and then they'lll probably get fixed at some point

if gurus are silent, not blogging, then we have to help ourselves 
somehow - this one is from ML, someone communicated with Carl :-)


Just a thought, but I sent an email to Carl asking if REBOL 3.0 would
have an embeddable component to it. His reply was:



 Thank you for your message...

Yes. We call that embedded REBOL, 
 and that method will be supported by
our REBOL 3.0 product.

-REBOL 
 Support

the latest sdk already has a rebol.dll (undocumented), and that's 
supposed to happen for 3.0 too (i.e. to allow the browser plugin). 
so no news actually. :)

anyway - let's say it will be 2006 .... 2007 is gonna be the year 
of R3, and IIRC 10nth anniversary of Rebol. Devcon 2007 is going 
to be great I think :-)

the repeat version, as this is what I would expect and call intuitive 
... the word 'i gets bound to the block and is always being reset 
- so an infinite loop 


so 'for seams to not care or at least keeps the state of 'i for it's 
own purposes - how should a user know this, even though some assignment 
like this might flag in most cases a programming error (and in the 
other case in a for loop one can't manipulate the state of 'i explicitely)

and will there be? :-)

I would like to know the difference between action! and native!. 
Thanks!

In Carl's REBOL 3 Blog Article #0039, he says that the ordinal functions 
(first, second, ...) are of the action! type in REBOL 2, and will 
be of native! type in REBOL 3.

and series.insert(value) will not be true in the native instead of 
action type?

ladislav, I think that's OK. interestingly, you can skip with decimal! 
values to make a smaller step than 1. I noticed two funny things 
though:

>> repeat i 3 [probe i i: i - 0.5]
1
0.5
1.11022302462516E-16
-0.5
-1.0
-1.5
-2.0
-2.5


One is that 0 isn't exactly zero and the other thing is that it counts 
to the absolute value of 'i

In my opinion Rebol should prevent the programmer  from shooting 
himself in the foot.  Also there are other forms such as FOR and 
WHILE that can be used for loops with variable steps. Maybe CFOR 
should be added to the core language.  


The problem with [ repeat i 3 [probe i i: i - 0.5]] is that it obscures 
the intention of the programmer. Does he wants to iterate 3 times, 
or more? This is not clear with such code.

It also seems that in the first case "all [true () ]" is not escaped 
after the first valid predicate and the parens are still evaluated 
which sort of explaings the error because unset! is returned. Maybe 
we need too allow do [()] should return none instead of unset!.

Maybe unset! should be expelled from the  ALL and ANY natives. After 
all there is not much that you can do with unset!, but expelling 
it is going to be hard. Lad, I am curious about your opinion.

I think I'm happy with ALL and ANY as is.

Of that repeat example:   repeat i 3 [probe i i: "a"]

I think that repeat must be checking the datatype and breaking when 
it is wrong (ie. false = integer? "a"). This can be seen as protecting 
the user from infinite loops caused by such user mistakes. Jaime 
is right that this behaviour has not been written into the function 
description, though.

I like REJOIN and never had problem to understand what it means and 
I don't like longer name for it, I write it too often

I had a few problems with 'join and 'rejoin in the beginning because 
I somehow expected them to be a bit like form and reform, using the 
same arguments as input. That's of course not logical, but I think 
that the 'word and 're-word naming of functions, doesn't entirely 
fit and actually limits the naming scheme, making it a disadvantage 
rather than an advantage.


Does 'recycle have anything to do with 'reduce? Or 'remove? No. One 
might think up a 'move function that does 'reduce. That would clash 
with 'remove, but 're- has two different meanings.


Words in rebol usually have sensible naming, something you can pick 
out of the dictionary and it'll make sense, except for those with 
're- in front of them. If you take them out of context and try to 
explain them, you have to know about 'reduce, but the dictionary 
meaning of the 're- words is something different. I don't have any 
suggestions on how to change this though, other than add a dash: 
re-form, re-join, re-mold...:-)

Which brings me to another topic: dash.


This can be a little painful in text editors, because a dash usually 
always has arithmetic meaning, no matter where you write it in other 
languages. But in REBOL, dashes not prefixed and postfixed with a 
space, have the same meaning as underscore or other word separation 
character. This means that in text editors, I can't double click 
to select a word and probably more importantly for some code editors, 
I can't autocomplete the word. Of course I could stop using dash 
myself, but there are a lot of system words with dashes in them, 
such as 'sendmail-pref-file or 'dsa-verify-signature.


So I sit in the code editor and type. But was it 'verify-dsa-signature 
or 'dsa-verify-signature? Darn it, have to look it up, because the 
text editor can't complete the word!

Why not simply get rid of rejoin and replace for the more useful 
DELIMIT?

Lots of English candidate words suffer because they don't imply copy, 
whereas in rebol this is important and it would be nice to distinguish 
between when we are copying and when we are not.

And DELIMIT

Currently we use REJOIN for most things, and sometimes we miss being 
able to add delimiters, after that, the next functionality is probably 
the quoting.

So I would drop the /WITH refinement and make it implicit in a DELIMIT 
or CONJOIN function... (maybe..)

1) rejoin/quoted [...]   ; <-- this is most similar to rejoin, or 
delimit without the /WITH

2) conjoin/quoted "," [...]    ; <-- this is like delimit/with/quoted 
 (and the non-optional "with" argument is specified first)

Anton, I really don't see the need for having ADJOIN and CONJOIN. 
There is a lot of code repetition for little gain in expresiveness.

I still feel I would enjoy having two functions here (adjoin, conjoin), 
so I think we just have to agree to disagree. It is a matter of taste. 
But, since there are benefits and advantages to each choice, and 
the choices are closely matched (to my eyes, at least :), then it 
does not matter which we choose. Flip a coin, or keeping arguing 
until the other guy gets tired. :)

In particular, I would need to be able to process blocks or lists 
or some such and have results of the same type. Basically the same 
behavior as rejoin, but with a delimiter. "Conjoin" means "join with". 
That /quoted refinement seems interesting though, when you are conjoining 
strings.

CONJOIN is good, and Brian maybe  right regarding droping the reduce 
refinement. So that [conjoin/reduce...]  becomes the idiom [conjoin 
reduce ...]

I am currently rewriting delimit and conjoin to implement a few of 
my own ideas for it. You do yours and we'll compare.

As far as I'm concerned, delimit and conjoin are separate concepts.

Hw about replacing 'rejoin with 'join and rename 'join to something 
else? Maybe a name for joining two things is easier to find?

We have also the issue if  the joins should return a string all the 
time. We could use old 'join for typed joins, by gibing the type 
as the first argument, and 'rejoin always returns a string. then 
it would be called 'join and join something with type in the name, 
join-as or something.

And if you need the old, source is in rebol2 :)

Strings are not the typical usage for me. I saw those functions posted 
above and none of them would work for me. I'm writing my own right 
now, for posting here. I have delimit so far, and am now working 
on conjoin.

I'm trying out a new control flow technique that is really fun to 
use, and devilishly efficient.