AltME groups: search

in parse, a good example of where the index creates many problems 
is when you use the 'TO or 'THRU words.

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.

Gregg, I think I recently made a function probably similar to your 
LIKE?.  Have you published that somewhere ?

But yes, multiple search terms are the next level up. To get the 
full range of matching rules with multiple search terms will take 
some work, however the basis is there.

So anyone know of a rough date for 3.0 ?

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.

i'm actually planning to bring a friend that speaks french ;)

I'll hopefully be there. Need to take my wife as she knows french 
a bit so I'm not completely lost ;)

I plan to look disgusted every time somoene does not speak English...this 
seems like a good attack plan while in France..... : )

Reichart, you'll look disgusted a lot this way.

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 ...  :-)

they sometimes look at you with a numb expression... you can almost 
see the gears working hard behind their eyes  ;-)

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 can speak only a few words of French but didn't have encounter 
any  problems, the few times I visited Paris.

Perhaps learning just a few words makes a difference ?

for my part, the first time I landed in Charles de Gaule airport, 
I saw a lost traveler (french) asking for bus schedules, get screamed 
at by the stewardess at the help desk... cause he asked twice!  :-)


I got cut off in a line (as I was going to be served) waiting for 
a train ticket in paris... twice in a row... I was soooo surprised 
I didn't know how to react!  I was then told a lot of people expected 
you to start arguing or else they are right ! 

its just funny really.  :-)


but my guess is that the more alien you are, the better people react 
.

they sometimes look at you with a numb expression... you can almost 
see the gears working hard behind their eyes  ;-)
   LOL!

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.

It's funny to see Native English people afraid of going in a country 
where English is not as known as in  ie. North european country :)

Be sure that native French people are afraid too to go in ie. US. 
Very very few people speak a second language there !!

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.

:-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

I'll have to add Danish if I ever do it again. :-) I couldn't have 
done it without a lot of help from the native speakers, particularly 
Richard. I wasn't even *close* on my Czech, working from translated 
text. At least he got a good laugh out of it. :-) Fortunately, nobody 
was there who could criticize my Indonesian.

depends of the meaning of "arm",
arm like a limb or like a weapon.

And the vocabulary of weapons is a little limited.

What advantages does HASH have over regular blocks, I can access 
a regular block like a dictionary anyway

I posted something on the APPLY thing on empty argument blocks, which 
I think should produce an error. This made me think of whether there 
is a very easy way to tell how many arguments a function requires?

variable arg dispatching breaks a major premise of rebol dispatch 
mechanism.

Henrick. In scheme/lisp. 

apply :+ [] ;== 0

whichs is a very sensible result.

Rebol functions can't accept a variable number of arguments with 
the exception of refinements. So the issue is becomes important. 
APPLY is kind of incompatible to the principle that * every  function 
has a fixed number of arguments*.

In scheme the parenthesis tell the function where the expression 
ends. In rebol the number of arguments tell the function where the 
expression ends. This is a very fundamental difference and the tradoff 
made when dropping parenthesis or any kind of expression delimiter.

but we can just implement our functions with a single block argument 
if we wish... then its a moot point... no?

For example:  1 + 2  becomes + [1 2], and then how you handle + [a 
b]. You need a prebinde code. Basically that reitroduces parens.

in the example of a function which accepts one variable length block, 
it could cause the prebind (reduce) itself as a pre-entry operation.

in this case it would allow a parens-like calling method, but we'd 
use blocks and the caller would not need to reduce the value explicitely.

obviously, the function args spec would have to be expanded a little.

Or maybe  a single DOT

or.... an yet unused char !!!!     a simple comma.

I actually think BLANKSPACE is a good candidate.

;-)   for my part... REBOL's code looks are a reason I like it.

Actually scheme is pretty much free form; after using it for a while 
you no longer see the parens. Python removed the parens but forcing 
identation. Acutally there is a scheme mode that allow you to program 
without parens.

First I thought R3 alpha will be released before the end of the year, 
now I wish we could at least see long time promissed diagrams of 
R3 architecture as a Christmas gift :-))

if functions had a refinement which said /grab or /varargs  then 
we could simply let the function grab all the values until it hits 
a wall (the end of a paren or block)

maybe the behaviour could then be toggled like a refinement on demand 
as an option when the use is not always mandatory  like so:

(sum/grab  1 2 3 4 5 5)

This doesn't scale well. The problem is what defines a wall. Actually 
that is the definition of delimiter.

This type of composition appears a lot when using combinations of 
apply and map and fold.

why not just use a block argument?

Ingo, but Max suggestions doesn't use parens. Just a refinement. 
Also in rebol parens escabe the interpreter and re-enter it. Slowing 
execution. I don't think see as a good fit.

Maxims approach is used in vid, where the wall is not the end of 
block but something "wrong". IE it could be standart to terminate 
such things with a dot.
  a: sum 1 2 3 4 .  print a

all needed would be a way to parse the callers code, i wish that 
for years. Other question is if is really is needed. blocks work, 
and the reduce can be done inside the function.

; works as a terminator.
I used it once for a function with many unset! arguments

yes, it  works just until a newline.(

With this three features a lot of possibles programming patterns 
are open. Like light multi-threading without needing to wait for 
some change in the C side.

I think this article explains the importance of having a truly extensible 
language using Dialects and Smalltalk .vs. Ruby comparison. http://onsmalltalk.com/programming/smalltalk/domain-specific-languages-ruby-a-sign-post-on-the-road-to-smalltalk/

weird article. Not a ruby guy, but have read: ruby can do smalttalk 
style if/else just as well; yiled is used in iterators, kind of continuations; 
continuations in squeak are a hack based on the low-level stack implementation.

hmm, I expected RT to at least say few words about how development 
of R3 goes. "REBOL projects and priorities" is once again off-base, 
and needs a bit of update ....

In REBOL3 there will be a native APPLY function, as you may be aware 
of

currently Carl thinks, that it should not reduce the supplied argument 
block, but it does to a GET on variables

...but it does *do* a GET on variables..

my preferences differ, I would leave all values as they are supposing, 
that if there is a variable, then the function is supposed to obtain 
the variable, not the contents of it

one more note regarding APPLY situation and my preferences. In addition 
to APPLY not doing GET on variables I would like to generalize the 
GET function a bit. It would be ideal if GET was a counterpart to 
SET and accepted a block of variables returning a block of their 
values. This way if we had a block of variables we could write: APPLY 
GET block-of-variables.

to reduce or not to reduce, that is the question. I have no clear 
answer myself, although I might prefer Ladislav's version too, if 
it allows more functionality. But generally speaking (not telling 
this is the case), if we will create some scenario, where 90% of 
usage will push users to add 'reduce word, because user wants it 
in those 90% of case, then reduced state should be reduced, or users 
will a) do mistakes not reducing themselve b) regard it being a bug 
c) use reduce automatically without thinking why is it needed :-)

I like your idea about GET. Your idea about APPLY sounds nice in 
theory, but in practice it would add a block allocation to almost 
every call of what should be a low-level, efficient native function.

hehe, now one question, maybe a stupid one - would it be technically 
possible, for functions which reduce by default (because in 90% of 
cases you want to reduce), to have some dont-reduce function in rebol, 
telling it to not reduce? :-) Not probably possible, because func-x 
[block of arguments] - there is no place in evaluation order how 
to order the func-x to not reduce the block? :-)

Petr, I would be more than happy to, but I would neet to retrofit 
REBOL with support for more Microsoft technologies before I could 
use more at my current job. Much as I like REBOL, I like a salary 
too.

>> make money
** Script Error: money has no value
** Near: make money

BrianH, Rebol doesn't care. :-) Just a joke.

I'm wondering a bit how general the closed core will be? Will it 
be only CPU dependent or delivered as an object for linking against 
upper and lower layers?

3 ways? Does your cell phone run .NET? And what is the third option, 
a native rebol port?

Your idea about APPLY sounds nice in theory, but in practice it would 
add a block allocation to almost every call of what should be a low-level, 
efficient native function.

 - I am not sure I understand what you have in mind - do you mean 
 you didn't like APPLY :f GET [...] ?

get needs to allocage a block.

I accept your refinement suggestion as a more optimal variant

Sorry, I meant explicitly doing that in mezzanine (which we want) 
would be a bit slower as opposed to doing it internally in APPLY 
(which we don't want).

APPLY usage discussion continuing


It is interesting, that BrianH thinks, that almost every call of 
APPLY will obtain a block of variables needing to be examined.

My envisioned usage is, that APPLY obtains a block of values sent 
e.g. from the Internet, where it does not make sense to sent a block 
of variables unless the variables are meant to be the arguments.

...but even then everybody is going to have a hard time trying to 
supply a variable as argument

yes. some way to do without get  is a must-have. and for get one 
can write  the code directly instead of going thu apply. I now prefer 
your version.

i would be happy to just do a reduce or get in that case.

So it is a beter way to pass refinements? Thats good :)

Ladislav, it seems to me that APPLY will be more often used in wrapper 
functions. Still, I can see your point about APPLYing to straight 
data. Your example of passing an unexamined block gotten over RPC 
seems like a security hole to me, if you can trust the source, the 
idea has merit.

The REBOL convention for this type of thing is to have the more common 
case (which I think will be wanting to get variables) be the default, 
and have the less common case by done with a refinement. The refinement 
that would fit in with the majority of REBOL functions would be to 
have APPLY/ONLY refer to the no-get case.

Love the proposed enhancement to the GET function though. Even though 
you wouldn't need it for APPLY, it would be useful to have GET on 
a block  return a block of values, for other purposes.

As for triggering errors, I would prefer that argument type mismatches 
to APPLY would generate the exact same errors that a direct call 
to the function would generate - that way you wouldn't have to document 
2 sets of errors.

I am not clear how GET on a block of variables would be different 
to REDUCE.

How would this block be treated ?
[a b 1 + 2]

when speaking about the REBCODE APPLY, variables A and B would be 
examined to obtain their values.

GET versus REDUCE: there is a difference. When a variable refers 
to a function, REDUCE evaluates the function, while get just obtains 
the function without evaluating it.

a couple of new blog entries discussing ++/-- and ranges

In the comments about ++/--, I suggested a new way of defining arguments 
to functions:

>> mult2: func [value:] [value * 2]
>> mult2 4
== 8
>> a: 3
>> mult2 a
== 6
>> a
== 6

With this addition to the language, INC could be written:

inc: func [value:] [value + 1]


Of course it would be better to have INC native, but with my suggestion, 
it will be possible to make our own functions, that works like INC 
and DEC.

What do you think?

but  i dont  like  funcs that  way. i read a and think  it is  evaluatet. 
leads  to confusion.

Volker, maybe not. But then we should just stick with

a: a + 1

shouldn't we?

but i prefer    a: + 1

or     inc 'a

a:  -  1 ; disambigius.

Volker, I follow you. Our normal way of thinking about functions 
and lines of code in REBOL is, that if we see a word, and we recognize 
it as a function, we look for arguments after the word. And we wouldn't 
think, those arguments would be changed. If words (variables) change 
value, we expect a set-word (like a:). Conclusion might be, that 
my suggestion will probably lead to more confusion. Falling back 
to ++/-- (or INC/DEC), those might be confusing too.

Problem with

a: + 1


is, that the plus sign can be seen as a unary plus. Because what 
should this mean?

a: + b

yes, but if we think c,   += and  -=  are  a close accosiation.

unary + makes no  sense.  unary minus makes, thatis a  problem.

a+: 1
maybe?

Not good, because a+ is a valid word.

or  without space,  a:+  1

argh, it's hard to define a language! :-)