AltME groups: search

This topic comes at a good time for me as I have a complex issue 
that I need to address which is similiar to what Pekr's sounds like 
except that I'm binding object/words to object/some-func.  I'm going 
to have the need to not allow someone to access object/words by probing 
object/words.  Object words is to large to have all of it inside 
of object/some-func which is why it is external to that function 
and only parts of it get bound to that some-func.

I'd like to thank the 2.7.6 team for all the great new stuff.  In 
particular  Brian Hawley  - well done.  Kudos; the new mezz features 
are awesome.  ALSO and FIRST+ being just two of many that will make 
for more concise code.

Long Live R2.

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.

Yeah the mezzanines will be very useful and should be in there just 
because of the frequency they will be used.

also 1 2    1 and 2 are evaluated by the normal sequence of getting 
arguments.   This func captures the two results (simply by having 
them as arguments) and returns the first.   Love the REBOL.  :)

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

Nah .. it's CS Lewis, and Narnia

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

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?

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"?

the error checking you could do, would be to check for the range 
first and then pick your value, if the index is in range.

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.

Skip+ does it find BrianH and I don't have to catch any errors.

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.

I looked at skip+ above and could see from the code what it does.

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.

Now in answer to your question, EXTRACT was created by the whole 
REBOL 3 group, though I wrote it. The changes to it were very intentional 
and the result of much debate. Please see the reasoning I wrote above.

The only difference between SKIP+ and EXTRACT related to bounds checking 
is that you can generate out-of-bounds references with SKIP+ using 
the start parameter, where with EXTRACT you would not be able to.

How so, and what do you mean?

EXTRACT and SKIP+ extract values at fixed intervals, so that means 
you use them with series that are formatted in fixed intervals. Thus, 
fixed-length records.

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.

Ok Brian.  Hey the rebol community has extract and at least I have 
extract and skip+ so I'm happy.

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.

Be sure to change your oldval and newval references to get-words 
for safety.

If so I suggest you keep the replace function and make this an entirely 
different replace function.  Call it replace-deep if you like.

Then just cut out out the /all from your current replace function 
and leave as is.

I didn't realize that you weren't using 2.7.6. I wrote REPLACE and 
EXTRACT in that release.

Keep thinking of like switch when I see case and I use case often.

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

Add the [series!] type check to the series parameter of the outer 
function and you'll be set.

The only problem would be if your blocks have cyclic references and 
you get stack overflow. I'm not sure you can catch that.

Don't put [any-type!]. The only difference between that and no type 
spec at all is that your function would be able to accept unset! 
values, and that would require other changes to your code to work 
properly.

I changed newval to new-value and oldval to old-value

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

I wish Carl would give us pointers on when to use unset function 
and how to optimize our use of the memory space and other performance 
tips.

I think your INITIAL and INITIALLY functions could be combined though.

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

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

May be annoying, but it's fast and small code.

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.

Sorry, just found out that to binary! on tuples moves binary and 
not formed binary.  And wanted to try it.  Not what you want in this 
case.

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.

You can nest { and }, so it will know without some special mark. 
Use an editor with bracket matching and you can tell too.

This is for constructing stubs of other languages that use {, and 
then we don't have to escape them.

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:

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.

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

It's worth notice, there is a difference in how words are evaluated 
and how numbers are. At first they seem to behave the same:

>> 1 = 1.0
== true
>> 1 == 1.0
== false
>> (to-word 'x) = (to-lit-word 'x)
== true
>> (to-word 'x) == (to-lit-word 'x)
== false

But using variables, you have to be a bit careful:

>> a: 1
== 1
>> b: 1.0
== 1.0
>> a == b
== false
>> x: 'x
== x
>> y: to-lit-word 'x
== 'x
>> x == y
== true
>> :x == :y
== false

The thing is, both integers and decimals are sub-types of the number! 
datatype, and you can't have a variable of type number!. A word! 
datatype is sort of more general than a lit-word, so my compare above 
is mis-leading (can be seen as mis-leading). If you compare lit-words 
with set-words, they behave more like integers and decimals:

>> x: to-lit-word 'x
== 'x
>> y: to-set-word 'x
== x:
>> x = y
== true
>> x == y
== false

Fork, I read some of your posts again. I'm wondering, if this is 
different in different versions of REBOL. I tried one of your suggestions 
and found, that it worked here with version 2.7.6 (and 2.7.5) under 
OS X:

>> reduce [y: 'x switch to-lit-word y ['x [print "hello"]]]
hello
== [x unset]

Do you get same result?

That uses what sqlab was suggesting, and it works for my case.   
I'd like to be sure there isn't some string that would break this, 
e.g. that the word can be preserved...

How I came about this is that I was writing a REBOL script that would 
dump out a file of function definitions for all the builtins.  I 
made some symbol browsing rules for a code editor that would pick 
up on function and variable definitions and let me jump around the 
code easily.  So I was using a lot of function names very literally, 
and in fact, as conditions of switch statements.  e.g. switch commandname 
[usage [print "Usage"]]

(Rather than being so sensitive to the details of whether contexts 
were evaluative or not, and using non-quoted style only if it wasn't)

I knew I could go commandname: 'usage and then later switch commandname 
[usage [print "Usage"]]. But  I was looking for a symmetry and was 
working on quoteswitch commandname ['usage [print "Usage"]] .  I 
could not figure out how to write quoteswitch without the above ability.

All you have to remember is that word! and lit-word! are different 
datatypes, so values of those different datatypes won't be equal.

Ah, well that's even better.  :)  So the trick here, though, is you 
can't do z: to-lit-word y, and then switch on z.  If you do that 
you have to switch on :z -- I think this is what confused me.

Er, I meant just a reference to z and not ? z, sorry.

Fork: always using "quoting" is actually the source of your problem, 
as it does not really bring symmetry in. the reason is that ' is 
not an operator, rather, we have word! and lit-word! as two separate 
types.

it is true that you have to know where evaluation happens and where 
it does not. but this is the key of rebol: since data is code and 
code is data, there is no explicit sign of what can be evaluated 
and what cannot. anything can be evaluated, if you make the interpreter 
evaluate it.

about "word-active" values: i'm not sure lit-word! being word-active 
is useful, but i'm sure Carl has a good reason for that. it's a good 
thing to always use :x instead of x when you want to get the value 
as opposed to evaluate the word (they are the same in most cases 
except a few types, especially any-function! types and, as you have 
seen, lit-word!)

Thanks Gabriele, I think I understand, and knowing the actual answer 
is helpful in understanding the fundamental springs and pulleys that 
make the REBOL machine work.

One of the first errors I encountered while trying to run an installer 
that was built in REBOL was that a state machine driven by a variable 
was failing to match a case and falling through to a default, due 
to a spurious linefeed on one of the cases that was read in.  It 
was attempting to match foo, but had foo^/ ... and so it fell through 
to the wrong case.  So I have been tinkering with a checked enum 
for REBOL.

Oops, deleted some spurious code and that made a typo, will make 
a better version that prints section headers for the tests...

I guess you figured it out already, but you can use TRIM to remove 
leading and trailing whitespace from your input.

Fork, perhaps you can show us the original (approximate) example 
from your installer state machine, with a few example inputs and 
expected results. Then we can see what started all this :)

There is no integrated debugger, and so tracking this kind of stuff 
down isn't as easy as it might otherwise be

And pretty much everything else... I'll go over it.  I should probably 
use "function" as I don't care so much for /local

I get the feeling that I'm going to want to have an analysis tool 
which will read through the functions, find any variable: assignments, 
and ensure they're in the local list unless there's some sort of 
indication they should be global.  Because it seems relatively uncommon 
that I would, inside a function, set things in the global space. 
 I'd be happy to use something wordier (set?) for that

I recommend FUNC over FUNCTION because having "/local" written makes 
it clearer and explicit what the locals are, and is shorter when 
there are no locals. Compare:

When there are no locals, func wins, because less characters to type.
	func []
	function [][]

When there are locals, same number of characters written, but func 
more clearly specifies the locals.
	func [/local]
	function [][]

Additionally, when you are modifying your func spec back and forth 
so that there is a need, or no longer a need, for locals, then func 
wins by less typing needed.

I go without such a tool for analysing function local variable consistency, 
which, I think, turns out to be a difficult problem to solve. Some 
people have written alternative function creators which somehow make 
set-words into locals by default (Ladislav ? with his lfunc ?) or 
something like that. I just maintain a strict habit of checking for 
accidental globals. It's good to review your use of variables regularly 
anyway, and be aware of what context they're bound to.

When I do something like a for loop and I specify a name for the 
loop variable, is that defined globally by default or locally?

do context[do :block] ... that would give it a new context and run 
it there.  What kind of thing would that break?

No, and the set-words are searched only in the block specified (not 
"sub-blocks").

It appears that REBOL is just more free about this by default.  You 
make a context for a whole bunch of code, the words bind freely, 
and then you blow it all away on the context level.

Yes, much more free. And I love it that way.

I'm an EE, so my biases are going to be a certain way.  In fact, 
I try to bring that need for structure and formalism to things that 
are typically thought of as unimportant for having them, e.g. GUI 
code.

I worry, for instance, about the semantics of if your app starts 
drawing on MOUSE_DOWN and then keeps processing MOUSE_MOVE as if 
you are drawing until you get a MOUSE_UP... but then your app loses 
focus while the mouse is down (for instance, due to a window popping 
up or maybe the user hit alt-tab).  So the app gets lost, or information 
gets lost, or whatever

Yes, high-speed prototyping does seem to be REBOL's area.  I've tried 
Awk and PHP and Perl and such and thought they were all terrible.

Yes, that's very interesting, and I'm going to have to spend some 
more time thinking about it.

I guess my attitude was to just get the thing working first, and 
worry about these sorts of edge cases later.

I like this quote: "Some facets of usability (
such as cancellation, 
undo, progress bars, and others) 
require software architecture support 
 .
Because they reach so deeply into the architecture of a system,
these 
facets must be built into the system from its inception 
rather than 
added after an initial system design
and user interface has been 
achieved."

Well, back to REBOL/Core :) I do feel that it's nice to find ways 
in which it can be applied more formally.  Maybe you can't validate 
the *process* by which a REBOL program achieves a result, but you 
can validate the *product* of its processes and check them for validity. 
 I think I would consider it that way, in that I would write tools 
to do all kinds of massive things in REBOL but then very carefully 
write an output-checker in another language.

Ok, gnite, and thank you for all your help.  I've updated the code 
and still appreciate suggestions: http://pastebin.com/m1f01d32a

Fork, it's tiny issues, but you might wanna do this:
In the set-value and switch functions, you have
... none = find ...
In the case of checking for none, you might wanna do:
if none? find ...

It's good work, you've pulled! And a fine idea with an enum! type 
implemented as an object. A good way to get a feeling about context 
and functions in REBOL.

You talked about locals. If you have a function with locals and no 
parameters, you can also use HAS:
f: has [v] [v: 1 + 2]

On parens, the reverse is true as well. Sometimes you need them in 
REBOL, where you wouldn't in other langs, because ops take precedence 
over funcs and math is strictly L->R.

As one who has been pushing for better PitL tools for REBOL, I hear 
you Fork. When I found REBOL, a lot of the initial things I did were 
to replace stuff from lanugages I was used to, that were "missing" 
in REBOL. There are still holes, and each of us will have different 
ones, but I eventually found that REBOL's way is not bad or wrong, 
just different. It takes a very different mindset to work effectively 
in REBOL. And use can use its power and flexibility to create a mess 
as easily (or more) as to create a beautiful and elegant solution.

For me, a breakthrough came not when I realized code was data and 
data was code, but (in my mind) that *everything* is data, and sometimes 
it gets evaluated. This can give rise to a view that things like 
mistyping "banana" aren't syntax errors, as you would view them in 
other langs, but "unexpected data". And if you think that way, in 
the enum case, how would you write code to deal with that. Not just 
at the local level of a /default handler for switch, but for propagating 
that information all the way up to the caller and user.

Another question I still struggle with is how forgiving and flexible 
to be. On the one hand, it's nice when you can accept a variety of 
input forms. On the other hand, where do you draw the line, and how 
to you write "soft" specs. At some point you still need to be able 
to make sense of the input and do the right thing with it.