AltME groups: search

Note that the options build the while statement without using compose, 
that no blocks are rebound, and that delimiter can be a thunk.

It could be tightened up a little in the empty data case, so I'm 
going to do that and post it again when I post conjoin.

Well, it will be a little hard to check against your delimit since 
that will be more comparable to my conjoin. Still, building the while 
statement this way is no slower than calling one of several different 
while statements depending on options, and it is a lot less redundant. 
Plus it's fun.

And here's a conjoin function:

Brian, I've read carefully through your conjoin (but haven't tested 
yet), and I like it, except for *one* thing - I would reverse the 
order of the data and delimiter arguments. (Actually, I'm searching 
now for a better word than "delimit". It doesn't quite seem right.)

So I'm thinking of readding the /LITERAL refinement and using DO/NEXT 
when it is not used.

; Anton's enhanced version:
; - /quote is applied to first value, if a string

; - reorders PAD and DATA arguments so PAD is first (being likely 
always short)
; - distinguishes /only and /pad-only
; - renames /quoted -> /quote
conjoin: func [

 "Join the values in a block together with a delimiting PAD value."
	pad "The value to put into the series"
	data [any-block!] "The series to join"
	/only "Inserts a series value in DATA as a series."

 /pad-only "Inserts a series PAD as a series." ; <-- this might not 
 be used much in practice (easy to add extra brackets around PAD)
	/quote "Puts string values in quotes."
	/local ; <- used to track tail of the result as we build it
] [
	if empty? data [return make data 0]

 local: tail either series? local: first data [copy local] [form :local]

 if all [quote any-string? local][local: insert tail insert head local 
 {"} {"}] ; quote the first value
	; <- (local should be at its tail at this point)
	while [not empty? data: next data] either any-string? local [
		either quote [

   [local: insert insert insert insert local pad {"} first data {"}]
		][
			[local: insert insert local pad first data]
		]
	] [
		either only [
			either pad-only [
				[local: insert/only insert/only local pad first data]
			][
				[local: insert/only insert local pad first data]
			]
		][
			either pad-only [
				[local: insert insert/only local pad first data]
			][
				[local: insert insert local pad first data]
			]
		]
	]
	head local
]

; test
conjoin "" []
conjoin "," []
conjoin '| [1 2 [3]]
conjoin '| [[1] 2 [3]]
conjoin ", " [{one} 2 [3]]
conjoin '| [["one"] 2 [3]]
conjoin/only '| [["one"] 2 [3]]

conjoin/only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make no difference 
in string mode
conjoin/only [pad] [[1] 2 [3]]

conjoin/pad-only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make no difference 
in string mode
conjoin/pad-only [pad] [[1] 2 [3]]

conjoin/only/pad-only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make no 
difference in string mode
conjoin/only/pad-only [pad] [[1] 2 [3]]

conjoin/quote "" []
conjoin/quote "," []
conjoin/quote '| [1 2 [3]]
conjoin/quote '| [[1] 2 [3]] ; QUOTE doesn't work in block mode
conjoin/quote ", " [{one} 2 [3]]
conjoin/quote '| [["one"] 2 [3]]
conjoin/quote/only '| [["one"] 2 [3]]

conjoin/quote/only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make no difference 
in string mode
conjoin/quote/only [pad] [[1] 2 [3]]

conjoin/quote/pad-only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make no 
difference in string mode
conjoin/quote/pad-only [pad] [[1] 2 [3]]

conjoin/quote/only/pad-only [pad] [1 2 [3]] ; ONLY and PAD-ONLY make 
no difference in string mode
conjoin/quote/only/pad-only [pad] [[1] 2 [3]]

Years ago, I successfully argued to Carl that SWITCH's VALUE argument 
should go before the CASES argument. My reasoning today is the same 
- it is easier to parse visually when the smaller or less frequently 
changing parts of an expression go together. As you can see above, 
all the conjoins with the same PAD argument are easy to see, and 
the more likely to vary DATA blocks begin sometimes at the same horizontal 
position (thus, easier to compare). Just scroll up and compare with 
the tests for your version; look at each line and try to see what 
the differences between them are.

The reasoning that a standard argument order is a good memory guide 
isn't strong enough for me; there is always HELP, and I think the 
particularities of each function are more important when determining 
the order of arguments.

that is consistent and comfortable

Anton, i think that conjion will be used often, but will the argument 
be an inline-block, or a block in a variable? 'rejoin is used as 
an template, 
rejoin["Its" now/time "o'clock"]

In that case the block should be last. 'append is used with block 
in a var, 
'append this-block something

With conjoin i  expect it less like a template and more like 'append.

I try to avoid using extra variables. They can be a real pain when 
it comes to optimization and make things look messier. Of course, 
when using a variable the argument order becomes less important. 
It's only important when no variables are used and specified directly.

The series function standard is
    function data-to-be-operated-on modfier-arguments

That's what I used with conjoin. It was also intentional that the 
data block not be reduced by conjoin. I see conjoin as an operation 
that you pipe data through, like utilities on Unix. If you want the 
data reduced, go ahead and do so - if not, don't.

Looking at your conjoin with the /only and /pad-only refinements, 
it seems that with the /only you are trying to recreate the delimit 
function, but not as usefully. I thought of using pad as a variable 
name, but "delimiter" was more appropriate since padding functions 
usually pad outside the data, not within it. Let me try to add you 
fixes to my version and see what I get.

Brian, I think you might have misunderstood how I reworked the /only 
and /pad-only refinements, or I've misunderstood what you're trying 
to say about it. Let's consider /ONLY:

The first value in DATA is a block, so the result is a block. The 
second value 2 is inserted as is. The third value [3] is a block, 
but the contents are INSERTed, so the block is unwrapped:
	>> conjoin '| [["one"] 2 [3]]
	== ["one" | 2 | 3]


Same result except this time the /ONLY refinement causes the third 
value [3] to be inserted as is, so it remains a block:
	>> conjoin/only '| [["one"] 2 [3]]
	== ["one" | 2 | [3]]


This seems to me to be a necessary option in the treatment of the 
input data.

Example:
	conjoin/only '| reduce [[option1] option2 option3]
	== ['pigs | 'sheep | 'goats]


So the data block was specified inline, but not used directly because 
of the reduce, and no intermediate variable was used.

But in this example the delemiter-version is actually shorter. And 
if i have something really one, i can live with an extra var. I guess 
i would pull it out of the code anyway.

So i think its rare and acceptable. While i would use it a lot for 
printing a result-block nicely delemited.

In this example the delimiter was very short and the data block was 
very short. Such short blocks can usually be processed manually in 
many different ways, so they are not good examples as is. You have 
to imagine much longer blocks.

just conjoin results as CSV and show them in spreadsheet..

Maybe it's hard to think of the usages now, but, you know, it took 
a while to learn when and how to use rejoin.

As for the word "delimiter" I made sure it wouldn't be exported to 
the external programming environment - no keyword arguments in REBOL, 
and I didn't use it for a function name or refinement. The more precise 
meaning of the word makes it a better choice for source that may 
serve as documentation, using the help or source commands.

I did understand your point about the /only and /pad-only refinements, 
but I realized that my delimit function made the change unnecessary, 
since its behavior was exactly what you were getting at. Using your 
example:
>> delimit ["one" 2 [3]] '|
== ["one" | 2 | [3]]

Keeping the concepts distinct wasn't the only reason I made seperate 
"conjoin" and "delimit" functions - it's more efficient too.

Yes, please.

I think I lost sight of the overall picture when I added /only and 
/pad-only. (Reminds me of a similar thought process in another frenetic 
function creation a year or two ago (?)) I was not thinking of the 
functionality that DELIMIT covered when I was "designing" those refinements. 
So on further reflection, it looks to me like you are right, for 
CONJOIN, using INSERT rather than INSERT/ONLY on the DATA values 
is more useful.

You can do this and anything else when passing in a function as delimiter.

Wow. A lot of thought here. I've skimmed it (trying to catch up on 
things quickly), and will just post a couple quick thoughts.


* REJOIN is probably a good enough name to stick with; I don' t know 
that any of the others are that much more meaningful in the context 
of REBOL. 

* Changing JOIN's params would break a lot of code.


* I have a DELIMIT function as well, and like the name. Mine doesn't 
have /copy or /only refinements (it always uses insert/only), but 
it has /skip.

Yes, that would be nice; PAD, JUSTIFY, and FORMAT are all related 
needs.

Gregg, I think Brian's last post with DELIMIT and CONJOIN are probably 
the best in this thread.

.. and as far as I can tell, we are now not thinking to replace REJOIN 
with either of those, they would be complementary.

The word "conjoin" means "join with", and is the shortest appropriate 
word we could come up wth for the concept of joining with delimiters.

On the other hand, if you don't want a full copy of the CSV fie in 
memory and would rather just convert to disk, conjoin should work 
just fine. It might be a good idea to add a /part option for fixed-length 
record blocks.

if I take the BREAK/RETURN above lexically, then it does not "belong" 
to the loop 1 [f 2] loop but rather to the loop 1 [ f: func ...] 
loop. This approach is called lexical binding and leads to 1 being 
returned as the result.

If I take BREAK/RETURN "dynamically" - i.e. when did it occur, it 
"belongs" to the loop 1 [f 2] and therefore the dynamic approach 
leads to 2 being returned as the result.

except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.

I see 'break and 'return as kind of catch/throw. So to me its clear. 
But i may miss something. The old way to build
  my-loop[break]
would still work lexically?

except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.

 - actually, in case of control-structs what you really want is lexical 
 break as you pointed out above and as can be demonstrated by:


    control-struct-test: func [control-struct [any-function!] code [block!]] 
    [loop 1 [control-struct code 2]]

>> control-struct-test :do [break/return 1]
== 1

I think lexically. if i pass a closure with a break, it should at 
least break into my code, and not inside some foreign code where 
it creates havoc.

regarding optimization: for the interpreter the dynamic way is faster, 
but it leads to "unexpected effects" sometimes as I and Volker agreed

So, you aren't specifying that your function f should pass along 
breaks, and you want it to pass along breaks? Even lexically the 
break is inside the f function, not the outer function. I don't get 
it, Ladislav.

Sorry, I get it now. I was mixing up break and return.

I would normally be on the side of dynamic break - it would be easier 
to teach, and the rest of REBOL follows that model. What would be 
the major advantage of lexical break in a non-compiled language? 
REBOL code blocks aren't really lexically associated with their control 
structures in the DO dialect, as my conjoin and delimit functions 
above demonstrate. This isn't rebcode you know.

right. OK, in case we will use dynamic BREAK in REBOL3 (highly probable), 
I will propose to introduce a new /THROW refinement for the WHILE 
cycle to "pass along" BREAK and that is all

Add it to the other loop functions too.

 - this is a "higher level" business and I will be content with having 
 at least WHILE/THROW. I guess, that it will not be used frequently 
 (?)

If you add /throw to while, it should at least be added to the other 
native looping functions. I will be used if it is there, and being 
consistent is easier than explaining the lack of consistency over 
and over again.

just a side note: it looks, that we will get CONTINUE in REBOL 3 
too and I suppose the /THROW to "pass along" CONTINUE too

APPLY would take refinements as positional arguments. That meant 
you would need to match the order of refinements in the declaration 
of the function you are calling, and that your function call would 
break if the function changed the order of its arguments - fragile. 
For some reason APPLY was slow too, and would crash REBOL if run 
too many times in a rebcode function.

I agree... and with dual cores becoming increasingly main stream... 
there is a definite advantage in that.

Linux and all of the commercial Unixes are good at threads now. I'm 
not familiar with the BSDs.

OpenBSD and FreeBSD have very good support for them. NetBSD is lagging 
behind. DragonFlyBSD has even better threading model.

peekus and pokus - more like ancient Latin language roots...

four days of fever and chills
that and c - zero based arrays

(the latest names are PICKZ and POKEZ, but I am not sure they are 
acceptable)

get and put

suck and blow

I think Ladislav is suggesting that, in addition to the existing 
PICK and POKE, which are 1-based, we add two new words which use 
0-based indexing.

suck and blow .... LOL  !

if you really use 0based, you know what you do, an can remember that. 
and it sounds dynamic :)

I would use z-pick/z-poke rather than pickz/pokez. It mentally expands 
to zero-pick rather than pick-zero, and reads as zee-pick rather 
than picks.

I like z-pick and z-poke

but I'm fine with pickz and pokez as well - no problem to me

cpick and cpoke ?   (Inspired by C++'s  cin and cout)

interesting part is, that imo if Carl and Cyphre work on new View, 
then hopefully Core R3 is ready to some extent?

Uhm, as I posted in Linux group, many systems are targetting its 
future towards vectore usage. Co-author of KDE 4 blogged about how 
fast Qt 4 based vector pipeline is, and it seems other engines can't 
stand the competition. Of course he generated some noise, as Cairo 
fanboys did not like it :-) http://zrusin.blogspot.com/So I looked 
at http://www.antigrain.com, to see what is new with AGG. It seems 
to me, that it is not good for RT - they are changing licence for 
any new version to GPL

Also if I understand correctly, Maxim has now full time job, non 
AGG related. I wonder what the future of AGG is for us, and if we 
should not look into something else ....

Pekr: The 'old' licence for AGG 2.3 and 2.4 remains. GPL is for 2.5 
which is at the moment at the same leve as 2.4(regarding functionality). 
So far noone from the AGG comunity(or at least at the ML) don't know 
why Maxim decided to change the licence.(everyone is waiting for 
his reply)

Maxim also wrote "Current AGG users who are willing to continue using 
AGG under the old terms and conditions are encouraged to contact 
me and I will consider their requests." so nothing is lost if we 
would like to use 2.5.

Anyway, even the AGG2.3 framework is very stable and have 99% of 
the features same like 2.4 and up. The whole code quality is very 
good so it is possible to enhance it...so this shouldn't be a big 
problem for Rebol.

Another thing is that in the 'worst case' current AGG users/developers 
who don't want or cannot use the GPL version are planning to continue 
with improving the 2.4 codebase separately.

Maxim: yes, this is already in current DRAW but only two filters 
are supported. (NN and bilinear)

I'm always wondering why people depend on the next release to start 
their app... take what you have and do it. There is always a way. 
It's like with a team. You got the people you have and good management 
is, to get to the goal with your team you have. Winning with a dreamteam 
is no art.

I'm always wondering why people depend on the next release to start 
their app... take what you have and do it.
 <--- Precisely!

I mentioned "waiting" in another sense though - it was wrong word 
choosed on my side probably, I just meant "awaiting", not "waiting 
for", sorry. And my argument was, that in MY opinion, devs would 
welcome more often, incomplete early alpha releases, than inhouse 
only testing of R3, late release. I very much liked days of Rebcode 
development - I found it very vital cooperation, and it clearly showed, 
that some community folks had very good influence on RebCode architecture 
itself ...

rebol [
	purpose: "Demonstrate how to use the findany function."
	note:  {This is a function I would like included in Rebol3.
		One of you experts (I don't remember who) made this function 

                for me, and I use it all the time. Do you see any ways it can
		be improved before I submit it? --- Louis
	}
]

s: "findany will return true if it finds in this sentence any of 
the strings you enter in the request box."
print [s newline]

forever [

 bs: copy parse (request-text/title "Enter the strings you want to 
 find separated by a space.") none

	findany: func [ 
	     "Searches string x for any substring found in block ys."
	     x [string!] "string"
	     ys [block!] "block of substrings"
	    /local pos
	] [
	    foreach y ys [
	         if pos: find x y [return pos]
	     ]
	]

either findany s bs [print true][print false]

]
halt

(... but, most important is defining the user interface and functionality 
clearly, as well as eliminating undesireable side-effects.)

Who can make these functions the most efficient, and display them 
in a benchmark program to prove it? And correct all the other problems 
mentioned by Anton.

Stayed up all night, and succeeded in making a parse rule generator, 
so if we want to search a string for any substrings:

string: {Hello there Anton. Arrow in the box. What nice antlers you 
have.}
substrings: ["ant" "antler" "anton" "arrow" "bar" "box"]

rule: [start: [["a" [["nt" action ["ler" action | "on" action]] | 
"rrow" action]] | ["b" ["ar" action | "ox" action]]] | skip]
Found at: 13 Substring: "Ant"
Found at: 13 Substring: "Anton"
Found at: 20 Substring: "Arrow"
Found at: 33 Substring: "box"
Found at: 48 Substring: "ant"
Found at: 48 Substring: "antler"
true

(very happy about this..) I'll clean it up and publish it probably 
later tonight.

Maxim and Anton, what difference does it make which value is returned? 
It is the true or false that I am looking for. If any of the strings 
are found, why look any farther? I'm sure you guys have a reason, 
but I want to know what it is.

.. and a name like FINDALL suggests that it returns those matches.

Your functions might better be named:  ANY-SUBSTRINGS? and ALL-SUBSTRINGS?

FINDANY and FINDALL might be fine for personal use, but to get acceptance 
out in the community, the names should be more accurate.

But I would really like to see funtions that find-any-substring and 
that find-all-substrings included in REBOL3, as they make programming 
a lot easier---at least for me.

they jump exactly like the above... and well it makes them much less 
usefull within the context of trying to get to the next value of 
"equivalent" values.

You guys a way more advance to me. That is why I hang out here---I 
get help when I get stuck. And by the way, thanks to all of you guys 
for the help.

Anton, my LIKE? function generates parse rules, but I doubt it's 
as advanced as yours, since it's just meant for simple pattern matching 
and doesn't deal with multiple search targets.

Fixed and republished (with same version number).

probably me. It depends if I opt for a new job or no, and if I am 
succesfull :-)

Paris is difficult to negociate unless you speak parisian... and 
even then, many french will tell you paris is almost like a separate 
country  ;-)

graham, just bring a sleeping bag and a really big lunchbox.

Graham , yea I visited france last spring and was surprised how few 
people spoke english

we're probably going together with Cyphre so I should be there as 
well.  Unfortunately, languages I speak (ENU, DEU, RUS...) are probably 
not very popular in France :) It's shame when people thinks their 
native language is enough  and refuse to learn something else(actually, 
this is problem not only in France ;)

I don't mind translating french to/from for you guys ... just tag 
me along , and pay the food  ;-)

Note that I have a lot of fun trying to get French (especially in 
paris) to understand quebec's dialect of french which can be as different 
as irish and american ...  :-)

I don't speak French...and do not face much problems moving around 
Paris speaking English.


though... for Reichart's case, you will need to speak MUCH slower.

its funny because talk about visiting/working at any european country 
with people and they usually all have good things to say...

talk about visiting/working in paris or some other big city in france 
and many people will have a funny story about being rebuffed ...

I really do think it depends on who you meet and why you go!

actually, i don't think it will be hard. i don't think english is 
less known in france than it is in italy, and we've been fine here 
:)

When I have landed to Dallas, people understand my english but me, 
I didn't understand anything. But don't worry, I had no problem there. 
You will experience the same in Paris if you speak in english, you 
will not understand the french response, but that's not a problem, 
people are very nice and will help you like people in Dallas did.

But, he ! Paris is a touristic town !!

So don't be afraid, you will find a way to be understood by others.
And "arms" are universal language ;-)

:-) Not only do very few of us speak a second language, but many 
of us have trouble with English. I always smile when I chat with 
people from around the world who apologize for their poor English 
when, in reality, it's often more correct than what American's write. 
It doesn't have the natural flow of a native speaker, but more advanced 
words are used, and used correctly. 


Knowing, now, how hard it was just to learn a few phrases in other 
languages for my dialect session, I have even more respect for all 
of you who give *entire* presentations in a non-native language.

Of course, I write that, and then see I've misused an apostrophe 
in there (American's). :-\

:-D

Gregg, you did a marvelous job with your multi-language intro at 
last DevCon. You tricked me for a second to think, you were fluent 
in all those languages. :-) I remember, I started to speak danish 
to you, and you raised your finger like saying: "I'm coming to that." 
hehe

And 
arms" are universal language ;-)"

So is MONEY : )