AltME groups: search

ALSO;   instead of  
    tmp: first series  series: next series  tmp
   also  first series  series: next series

No tmp required,  ALSO  will return the first result of the two expressions 
 BUT in this case why?   :) 
FIRST+;   instead of the (now) useless example I just wrote;

    first+ series    ;; return value at current reference and then advance 
    reference
No tmp, no next required.  All in one expression. 


Note:  SOURCE ALSO   it's cool and will make a lot of sense when 
you see it.

I use the following in my program:

name: any [
	also getname var: yes
	also getanothername var: no
]


if getname fails (returns none) the other function must be called, 
and a variable set to flag this. Could ofcourse be rewritten, but 
I wanted to try using also :)

You can do a call to net time

;Here is a handy skip function:

skip+: func [
    {Returns a series matching the skip sequence}
    series [series!] "Series to return skip values from."
    interval [integer!] "Skip interval"
    start [integer!] "Series index to start skipping from."
    /local blk][
    blk: copy []
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series
    if empty? blk [return none]
    blk
]

It allows you to start at any index position in a series and begin 
returning values that match the skip interval.

LOL geomol, I was looking all over for a function in REBOL that did 
that.

My skip function is a bit more efficient though.  Maybe we should 
replace extract with it:

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> stats/evals/clear
== [2 1 2]
>> b: extract/index a 2 1
== [1 3 5 7 9]
>> stats/evals
== [218 107 33]
>> stats/evals/clear
== [219 108 34]
>> b: skip+ a 2 1
== [1 3 5 7 9]
>> stats/evals
== [187 90 39]

Looks like extract is also a bit buggy

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> b: extract a 2 22
== 22
>> b: extract/index a 2 22
== [none none none none none]

But for what I'm doing I think extract will be fine since it is built 
in.  Will save me a few lines of code in my script.

I don't see a bug in any of those entries.

Probably not a bug but does we really want none to be returned?

yes, that's on purpose. in 2.7.6 you can define a different default 
value to be returned.

So how is it not a bug if you tell it to start at index 22 and there 
is no index 22 and it  is returning none?

>> a/22

>> a/22
== none

in 2.7.6:

>> b: extract a 2
== [1 3 5 7 9]
>> b: extract/index a 2 22
== [none none none none none]
>> b: extract/index/default a 2 22 'potato
== [potato potato potato potato potato]

I know that a/22 is none but shouldn' t it instead react like other 
REBOL entries in this regard and say "out of range"?

Not a fan of how it returns values.

well, you'd have to write a lot more code, if it returned an error.

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> skip+ a 2 22
== none

I can see you are worried about whether the returned none! is a value 
in your block or if it's out of range.

skip+ keeps the output in a block as well:

>> skip+ a 2 3
== [3 5 7 9]

much easier to do:

to-block skip+ a 2 3 


then to determine if a none is an actual value being returned of 
my series.

but... anyway, it's just two different principles. I prefer to do 
the error checking before doing operations in the series:

a: [1 2 3 4]
b: 7
either tail? at a b [print "whoa!"][extract a b]

That is defeating the purpose of a mezz.   The mezzanines are so 
we don't need to use more code.

Makes me think we should have a poll for mezzanine changes.  Let 
the community decide.  Could be very beneficial to REBOL.

sure. that's why I think is impractical for cases like:

foreach val skip+ a 2 3 [do-something]


you will get a crash, when it returns none, and you will still need 
to do some type of range check to avoid the crash.

; I liked this feature of ICON/UNICON where a func can have an initially 
block so I have this in REBOL
initial: func [wd [word!] /list /local functions]
  [
    functions: []
    if list [return functions]
    f: find functions wd
    either (found? f) 
      [return false] 
      [append functions wd return true]
  ]    


initially: func ['wd [lit-word!] blk [block!]][
    if (initial wd) [do blk]
]
; and to test initially
test: func [str [string!] /local prefix [string!]][
    prefix: ""
    initially 'test [prefix: "tested "]
    print [prefix str]
]
; which runs as, say
test "this"
; first time giving "tested this" and thereafter "this"
; thoughts on whether useful enough to go into the org library ?

Paul, the changes to EXTRACT are part of a whole series of subtle 
changes to REBOL that are based on 3 ideas:

- NONE is a value that denotes no value, like UNSET but not an error 
- sort of like SQL NULL.

- Out of range isn't necessarily an error - you can choose to treat 
it as such as you like, or not. Boundaries are really an implementation 
detail in a language with autoexpanding series. The choice to have 
fixed boundaries is left to the developer.

- There is no difference between a NONE in the middle of a series 
and a NONE off the end. It's a missing value either way.


REBOL worked this way already in many cases, so we're making it more 
consistent.

Creating, evaluating, throwing and catching those error! values is 
really expensive - nones are much faster. Also, these error! values 
are generated in many cases now where the situation isn't really 
erroneous, which is a little presumptuous.

I just don't like it Brian.  Like Henrik noticed I have a problem 
with it because it returns none as a value inside of the series. 
 I rather have it report none as a none! When it is reported as it 
is currently in extract it isn't a none! datatype it is a 'none word 
value.

And it returns a none datatype if out of range.  I don't have to 
check for "out of range" as the none being returned tells me that.

So if I'm using 'none in the block and it is returning #[none] then 
I have to check to determine if the value returned is a none! or 
a 'none.

Let's make a distinction here: The word 'none, the value #[none]. 
EXTRACT returns the value #[none]. What are you using 'none for?

Sometime I use the value none to specify that position in the series 
doesn't currently have a value.   I'm sure many have done this.

Brian did you create the EXTRACT function or something as I can't 
see how anyone would prefer its return value over a simple return 
for general use.

So your problem isn't with EXTRACT treating #[none] as no value, 
it's with it treating out-of-bounds as a non-error.

Notice here:

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> skip+ a 2 1
== [1 3 5 7 9]
>> skip+ a 2 11
== none

Re "Both": You said that you treat #[none] as no value, even in the 
middle of a series, and that is what EXTRACT does, so no, that is 
not your problem.

As an aside, whenever someone posts a message to AltMe my client 
locks up for 30 seconds to a minute, making it impossible for me 
to type replies. I am frequently unable to answer a question until 
much later because of this. Please wait until I have answered before 
asking the next question, or I won't be able to type the answer.

SKIP+ is a lot more taxing on the stats/evals, actually. There is 
more code in EXTRACT but that code is mostly error checking code 
that is run only once per call. The code that actually does the extract 
is more efficient:

    forskip block width [append/only new any [pick block pos value]]
versus
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series

Wait, you may be right. It turns out that forskip is a mezzanine 
in R2, where it is native in R3.

Even if the slowdown is fixed it will still return [none none none 
none ....] which is a feature of extract I don't particularly find 
as useful as just returning none!

I mean, the biggest problem I saw in SKIP+ was that start parameter. 
By using a seperate index you are just asking for out-of-bounds errors. 
Remember, series references include a position - you can just generate 
another series reference in the new position by using AT.

I see other problem potentials for extract.   If the position value 
could ever be user supplied it causes a major problem.

Well skip+ is not designed to need a fixed set of records towards 
its interval

>> blk: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> skip+ blk 2 1
== [1 3 5 7 9]

You are treating the series as a series of records of length 2.

I don't look at it that way.  I look at that I have a variable length 
of records in blk and I want to return every second one.

Mine is strictly a replace/all function it is much more tasking on 
the system but if made native could probably be cool

well that is where it gets a little of a concern.  Currently, I only 
check for equal?

was written for a particular use I had but not for general use.  
It will have some limitations to be a mezzanine

If you see a series it doesn't work on let me know.

Not bad. You use an inner function for the recursion, which should 
allow you to go to greater recursion depth before running out of 
stack space. I'd change the series? to any-block?, and the EITHER 
IF to a CASE, and the FORALL to a WHILE, and add type specs to the 
outer function, and change /local sd to /local sub-ic?, but otherwise 
good stuff.

There you BrianH..  You just thought of ways to improve it.  I just 
whipped it up when we were discussing it from another function built 
for a different purpose.

Do source replace - it's a good way to learn some interesting optimization 
techniques.

I think I had that if for a reason but not sure why

lol - I'm just a hobbiest with REBOL.

That is why when you use a lot of programming terms I'm lost.

I think that replace function is good Brian.  I would push for that 
to be a mezzanine at this point.

>> str: "this is just a test of replace-all"
== "this is just a test of replace-all"
>> replace-all str #"t" #"d"
== "dhis is jusd a desd of replace-all"

The case did cut it down a bit on the evals:
>> replace-all b 1 2
== [[2] [[[2]]] [2]]
>> stats/evals
== [209 100 42]

I would say that is one heck of a useful function

same function just commented a bit and changed sub-ic to just subf 
meaning subfunction

Should it throw errors to a catch so that it doesn't expose the lower 
code?

If were sure that all the values that it traverses are comptible 
then I agree.  In fact I don't think we need one until it becomes 
known as a problem.

In general, I find that it is a good idea to let unset! values be 
erroneous, rather than changing your code to accept them. That makes 
it easier to make a clear distinction between non-values that are 
erroneous (unset!) and non-values that may not be erroneous (none!).

Is it a good practice to unset series within functions if the series 
is an argument to the function?  Not sure how the garbage handler 
in REBOL works or if it sees it as garbage until the next function 
call.

In other words if i pass a massive series of data as an argument 
to the function should I at the end of the function unset that argument?

That was something I brought up during R3 development. R3 series 
don't retain references between calls, R2 series do. In general this 
is not a problem, but if the extra references are becoming a memory 
leak, change this:
    series
to this:
    also series series: none

It would be any problem? wouldn't the get/any cause a problem if 
it encountered the unset!?

I suppose a catch attribute would be appropriate to add to the function 
too.

It relies on the FIND finding blocks based on whether they are the 
same, not equal. That means that the reference to the code block 
that is passed to INITIALLY can itself be used as a tag.

RobertS; Regarding initial blocks, make sure you check out http://www.fm.tul.cz/~ladislav/rebol/
and in particular http://www.fm.tul.cz/~ladislav/rebol/#section-5.6
  As Ladislav himself puts it, "a comfortable Func replacement".


An lfunc does all the work of localizing words set in a func, allows 
an init block (of which set-words are wrapped in use for static variables) 
 etc...etc...

Anyone know why there is a space after the first string?

>> form reduce [ "hello" newline "there" ]
== "hello ^/there"
ie. why isn't it "hello^/there" ?

I'm more surprised that there isn't a space after the newline, since 
form throws those in everywhere :)

Might be related to, how PRINT is working, which has a built in reduce. 
This would look weird, if there was a space after the newline:

>> print ["Hello" newline "World!"]
Hello 
World!

And you need those spaces, when doing something like:

>> print ["Hello" "World!"]
Hello World!


So it's because REBOL is clever and do, what you expect. (Mostly.)

I can understand spaces between words ... but at the end of a line??

I bet, it's faster, the way it is. The internal rule is:

Add a space after a non-newline.
Don't add after a newline.

I doubt that adding a new rule - don't add a space if next character 
is also whitespace will slow a native down much.

It's a very little annoyance, that you can work around. If REBOL 
were close to perfect, it would make sense to go into such things. 
There are much larger problems or things, that's nott finished with 
R3. (My opinion.)

The reason I note this is that I was inserting an EPS into a block 
of words and then forming it.  This adds an extra space on to the 
image data in the EPS and as the routine in the EPS to read the image 
data is white space sensitive, it dies.  I have to do a replace/all 
{ ^/} {^/} on it before I submit to the printer.

Greetings,my name is Brian (http://hostilefork.com).   I am new to 
REBOL, and was introduced here by Reichart.  I have a question I 
can't yet figure out.

switch to lit-word! 'x ['x [print 'hello]]  should work.  It all 
comes down to knowing when values are evalutated.  


'x  outside a block is evaluated as the literal word x and is seen 
as the word! x   ['x]  inside a block is unevaluated until reduced 
so is in the block as an actual  lit-word!  'x   Clear as mud?   
Same for none.  Outside a block (or anytime evaluated, none is a 
value none of type none!   Inside a block it is simply a word!  that 
hasn't been given a value.  That case got me a few times  if  first 
 [none]   ...   is true, as all word! data tests as true.   if first 
reduce [none] is the false case.  mold/all can be you friend when 
exploring this.

And when I say "given a value", I mean an evaluated value.   words 
in blocks have value, just not a variable substituion "value".   
Oh and I suck at explaining this.  :)

Yes, it comes to evaluation. In the second example, the block isn't 
evaluated, which can be seen with this:

>> switch 'x probe [ to-lit-word x ["hello"]]
[to-lit-word x ["hello"]]
== "hello"

If you try reducing the block, you get an error:

>> switch 'x reduce [ to-lit-word x ["hello"]]
** Script Error: x has no value

What you tried to do was this:

>> switch 'x reduce [ to-lit-word 'x ["hello"]]
== none


You can get it to work AND get the block reduced with this (if that's 
what you want):

>> switch 'x reduce [ 'x ["hello"]]
== "hello"


The thing is, putting a lit-word in a variable, and it's seen as 
a word, when evaluated (I think):

>> a: to lit-word! "x"
== 'x
>> type? a
== word!

I hope, it makes it a little clearer.

I would like to propose an addition for R3

When deguggin successive expressions it is a drag to keep shuffling 
down 
  comment {
until the suspect is reached
Could we not use
	;{
to be the equivalent pf
	comment {
for code which has a REBOL header with a
	needs:
that points to an R3 version?

Almost there!  I just use a multi-line string. :)
	{
	...
	}

Geomol/btiffin/Gabriele -- thank you for your help.  I'm actually 
trying to do something where the condition of the switch is inside 
a variable, and I had tried the to-lit-word and found it wasn't working. 
 Apparently if I had done to-lit-word x' it would have worked, but 
my situation is:

In this case, is there a manipulation I can perform on y to make 
it match the condition?

The comment character isn't { - comment is a function that takes 
one value and ignores it.

You don't have to use a lit-word to make a word if you are not evaluating. 
On this line:
    y: 'x
you are evaluating the lit-word and getting a word. On this line:
    switch y ['x [print "hello"]]
you are not evaluating the lit-word 'x, so it stays a lit-word.

I need to substitute in *** f(y) *** something that is a function 
of y that will result in printing hello

It's kind of a "how do I get there from here" thing

probably still not what you are looking for, especially if you are 
looking for a function 
reduce [
    y: to-lit-word "x"
    switch  :y ['x [print "hello"]]
    ]

It's a strange situation, you have Fork, that I don't understand 
completely, but you can do this:

>> f: func [v] [to-lit-word v]
>> reduce [y: 'x switch f y ['x [print "Hello"]]]
Hello
== [x unset]


You get "Hello" printed, and the result of the reduce is a block 
containing x (from y: 'x) and unset (from print, which returns unset). 
I suggest, you move on and use REBOL some more, then after a while 
go back and look at this problem again. You might then see it with 
new eyes. I had programmed in many languages in many years before 
REBOL. It typical took me a week or so to "get" a new language, to 
understand it more or less completely. It was different with REBOL. 
It took me more than a year to really "get it". That's normal, because 
REBOL is so different from most of the rest.

I would do such a switch this way:

>> y: 'x
== x
>> switch y [x [print "Hello"]]
Hello

Less code and easier to understand.

I realize my situation may be "strange", but it is a real question... 
and I'd like to get a grasp on why I can't build an expression in 
the slot I've described to match the condition I seek... if there's 
a fundamental reason why rebol can't match a quoted/literal switch 
instance when the switch condition is a variable ... I think it would 
be beneficial to know why not.  (Especially because when I look at 
new languages, my intention is to know their limits!)  I've developed 
compilers for many DSLs and as a result I'm always focusing on this 
kind of fundamental... I appreciate the help, and I am doing other 
REBOL invesigations in parallel with this question, but I still want 
an answer :)

Did my example with the function making a lit-word help?