AltME groups: search

exactly.  this is dangerous.  cause someone might do:

REBOL [
	modifier: [val + 2]
]
and then your whole script crumbles.

for such a simple effect its trivial, but if you start using the 
header for code, it might become a habit and then you'll open a door 
you didn't realise.

can be as simple as a binding error, which uses a global value instead 
of a local one, and bam, instant very hard to tackle bug.

in this simple case, its still pretty harmless, and you can still 
argue that its still a "setting", but I do think going to far is 
a dangerous can of worms.

rebol's binding and mutable series has a tendency to whip you in 
the face sometimes.  and a overly competer user might "assume" more 
than he should and create a bug he can't really understand.

I used to put history editing commands in the headers, and changed 
to a specification + data in the header, then parsed via a dialect. 
 seems cleaner and pretty in the end, and the user has to properly 
understand the spec in order to do anything, so its like forcing 
proper documentation and learning.

Callbacks.  One instance I'm thinking of is to have a file containing 
only a parse dialect -- parse "text" load %rule.r -- and having some 
callbacks specific to the rule - eg. on-success and on-fail.  Feels 
like it could be a natural way to do it.

But, yes, binding has to be apparent and understood in order not 
to screw up.

remarks v2 binds parse rules to html and functionally rebuilds a 
page, much like what you describe.

The type and exports header fields are used by R3 modules, in much 
the same way as your's Chris. Same with Gabriele's modules. In general, 
it is best to not put executable code in a header unless it is executed 
by the script itself. Don't assume that any word values assigned 
to fields in the header will be bound at all in R3, let alone bound 
to the same context as your script. Dialect code should be OK to 
assign to header fields, as long as it is not executable code.

thanks! I just run some data printing in a loop, and I want to stop 
at each iteration, and press enter to get another row ... 'ask served 
very well for me ...

I wonder if we could have iteration via two blocks? I have two blocks 
- first with field names, second with values. I could write some 
map function and put it into object, but field names have spaces, 
so I did something like following:

stock: read/lines %stav-zasob.csv

forskip stock 2 [

  fields: parse/all stock/1 ";"
  values: parse/all stock/2 ";"

  i: 1
  foreach name fields [
   print [name ": " value/:i]
   i: i + 1
  ]

 ask "Press any key to continue ..." 


]

This function sounds more like MOVE than FLATTEN. We had a debate 
about both of those functions, and MOVE was included while FLATTEN 
wasn't. It all came down to three factors:
- Is this function generally useful, or would it be used rarely?
- Is there consensus about what it should do?

- Is the function so difficult to get right that it makes sense to 
include it for that reason alone?


In the case of MOVE and FLATTEN, both were considered useful, but 
only MOVE had consensus and was tricky enough to be worth including, 
especially since the features had to be carefully restricted for 
it to work safely. FLATTEN was considered useful, but no two people 
requested the same behavior, and every implementation was so simplistic 
that it was hard to get wrong.


This multi-series loop function seems more like MOVE in this regard, 
but only if we can agree on what it should do.

Pekr, I was thinking that the outer join approach would fit in the 
best with the R3 treatment of series changes and none. There are 
fewer occasions where errors are triggered in R3, and those occasions 
are carefully chosen (except for bugs, of course).

The next thing to fix would be having the words and data interleaved 
- they should be separate for easier data processing.

Brian, by separating words and data, do you mean this format ?
>> nforeach [a [b c]]  [[123][456789]]  [print [a b c]]

Gabriele, if we had DO in PARSE we would still need DO/next. Just 
not for nforeach - neither DO/next nor DO in PARSE would be appropriate 
there. Nor would REDUCE be needed. All you'd need would be BIND/copy 
and SET, and some loop function.

it basically parses the text string returned by the daytime server, 
and works out what utc is ( nist-time )

it then displays the difference between utc and your pc time.

now, when I set my pc clock to canadian time, or EDT ( -0400 ), on 
vista, Rebol says timezone is -3 and not -4

and we have shifted last week-end.

and what timezone should they choose??

it superseeds older ones... (there are two previous kb I think... 
one in the 7 range and one in the 8 range IIRC)

Gabriele, I don't think the wiki will be ignored. It's just that 
a wiki and an official manual are different things. Noone would sensibly 
expect a wiki that can be edited by anyone to be authoritative. But 
a wiki can fill in the blanks.

As for nforeach, you didn't catch that the first thing I would change 
would be to have the words and data in separate blocks, to make generation 
of the data and pipelining easier. The words are an artifact of the 
call to nforeach, not part of the data. You need DO/next to implement 
the old version, not a version that I was talking about. Any REDUCE 
would be outside the function.

Geomol, yes, but not all datatypes, and expect binding issues with 
object! and function types.

Pekr, Bacon has been doing good work, and the wiki is getting prettier 
:)  But there have been a few factual errors on those pages...

BrianH: I don't agree. While he is doing really a good work, he also 
completly ruined some stuff. He restructured Carl's docs so that 
they don't make much sense and he intermixed it with Gab's former 
VID docs, not understanding VID3 and VID 3.4 are different things. 
That fact alone is totally confusing ...

I'm not assuming it's a him until I see a full name. The factual 
errors can be cleaned up as the GUI design progresses, no worries. 
In the meanwhile we have a new doc structure and examples of formatting 
to copy, so I'm grateful. This does illustrate my point about the 
difference between a wiki and a manual though.

Brian: I don't like it that way as then you have to keep in your 
mind the relationship between words and blocks; furthermore, please 
name me one case where you wouldn't need reduce. A function that 
*always* needs reduce is badly designed. :P

As for the Parse Proposals wiki, I'm afraid it will need some cleaning 
down. I kept trying to tell Peta the rules Carl set up, but Peta 
kept ignoring them and going into great detail about parse theory 
and such. Half of the contents of that page are going to have to 
be moved to other pages, and I'm probably going to have to summarize 
the best of the proposals to Carl if we want to convince him to implement 
them.

You have a good point about the nforeach reduce thing, but I am not 
convinced that giving up the ability to generate the data in other 
functions is worth it. I usually don't like to see DO/next in mezzanine 
code anyway: DO/next is usually a sign of a function that doesn't 
work in a REBOL-like way and has too much overhead to use. However, 
I still want Carl to fix DO/next in R3 - it doesn't work at all at 
the moment, and there are some proposed functions that can't be implemented 
without it.

Chris, that sounds like a good job for DO/next. It also sounds like 
a function that would be replaced by CASE [NOT ... when the code 
is being optimized. REBOL programmers can be pretty ruthless when 
it comes to hand-optimization, so one of the goals of R3 is to make 
the mezzanine functions powerful and efficient enough that they will 
actually get used rather than optimized away, and to make native 
the functions that need to be. The hope is that the users of REBOL 
can just use functions and trust that they will be efficient, rather 
than having to manually inline code all of the time.

Seems a stretch as to-char "a" works, and to-char "ab" returns an 
error...

Would it make sense to let this return true?
1
 = 1

There is a trap here, because we easily run in circles with char, 
string and integer. There are some special rules about char!, and 
it's probably hard to deside the best design.

In other words, would it make sense to compare apples and pears? 
We kinda do that with char and integer now.

I'm not sure that comparing char! and integer! is comparing apples 
and pears. Given that Rebol is written in C, it is most likley that 
internally it is stored as a char which is simply a single byte integer.

But you see the problem, if
#"a" = "a"
and
#"a" = 97
then
a
 = 97

which doesn't make much sense. But it could be a nice thing to have 
some of those implicit type conversions.

http://www.rebol.net/wiki/Datatype_math_compatibility_tables


Those tables were generated programmatically, so I don't recommend 
editing the wiki manually. The idea is that running the generator 
will produce results based on acutal behavior. 


If we care about which version, that will need to be added, and we'll 
need a way to deal with the information. e.g., run under multiple 
versions and aggregate the results.

As much as it seems like adding coercions support would help, IME 
it only helps in *very* simple scenarios, and can lead to problems. 


As a historical note, when Visual Basic added the Variant data type, 
it started down this road and went so far that it eventually spawned 
a petition of "VBers against Evil Type Coercion".

The table suggests that, apart from a few exceptions, Rebol coerces 
numeric types and not non-numeric types. If this is the case, it 
would be good for this to be documented.

I have sympathy for the opinion against coercion, if it is a real 
problem in real applications, but I also think, coercion can be good 
in many cases.


We have == (strict-equal?), and I think, it works as == (or =) found 
in many languages, and that is without coercion. And then we have 
=, that can be seen as a loose equal with coercion. I would like 
this coercion to be extended (if it makes sense), so these will give 
true:
1
 = 1
#"1" = 49
49
 = 49
a
 = "A"
a
 = 'a

1
 should not be equal to #"1", because this is true:
(first "1") = #"1"

(Just suggestions.)

("a" = "A" and #"1" = 49 in my example above is already true today.)

User type something in, and you wanna check, what number was input. 
Like:

if input = 42 [print "The answer!"]

Maybe we could ask, where do you use = today, where you couldn't 
go with ==
And why?

What I'm after are very good arguments to have both equal? and strick-equal?. 
The less differences between them, the better argument to not have 
both. I think, both should be there, and equal? should have even 
more coercion than today. Maybe it even makes sense to take it further 
to include blocks? Should two series with the numbers 1, 2 and 3 
in them be equal?

123
 = [1 2 3]


Why not? Today we have to put to-string in front of the block to 
make them equal.

Ask a user, what she typed in, and she might answer the number 42. 
She wouldn't say, she types in the string "42".

Input checking is about the last place I want coercion applied. Yes, 
you can eliminate some calls, but at the risk of letting bad data 
in, and still failing on valid data. e.g.,  which of these are OK? 

1 = "1"
1 = "1 "
1000000 = "1,000,000"


What we need, IMO, is an I/O dialect that makes it easy to specify 
mapping and formatting. The problem with coercion is that it's *hidden*, 
so you have to know all the rules.

I'm totally for human readable, as you probably know, but "123" is 
defnitely not the same as [1 2 3]. It might be considered the same 
as "1 2 3" by some people, but not "123". 


What the user types in, and what the programmer has to know it's 
translated to, are two different things.

You touches some problem, I have, with remembering the difference 
between FORM and TO-STRING. I can't remember what these produce:
form [1 2 3]
to-string [1 2 3]

I have to try it. You have good points. What do you see as the arguments 
to both have = and == in REBOL?

Based on its speed characteristics, I would say that the length is 
tracked in the string and just accessed by LENGTH?.

Steeve, you can put ^(00) in strings in R2 and R3. They get converted 
to null-terminated for calling C routines, but they aren't internally.

But sticking to R2 and putting aside conversion to c routines, are 
you saying that R2 doesn't terminate strings with null?

Steeve, you can put nulls in the middle of strings and their length 
doesn't change. Thus, not null terminated.

Otherwise length? would be O(n), and my testing has found it to be 
O(1) for avery series type except list!

by default, an empty string allocate 3 slots.
1 storing the logical address
1 storing the physical address and the length
1 storing storing the real data .

These slots can be stored at any place

Well this is where I have the concern.  Because at a lower level 
you would want to allocate memory for string large enough for certain 
variations of the string during runtime.  And that approach seems 
to negate that  possibility.

I'm obviously talking low level here and not what we have ability 
to do via REBOL.

there is no other way... you have to know the bounds, and allow ram 
to be recycled.  indirection is the only way to do this.  rebol has 
its own memory manager.

other languages do not use mutable series.  they use immutable strings 
within a single index.  every operation is a memcopy and then replace 
the pointer.

and all references to a string are actually independant... change 
the string in varA  and varB doesn't reflect it.

rebol changes the actual bytes within the ram. most languages, create 
new strings and assign the new pointer to the variable.

wasn't that also the difference between R1 and R2?

then rebol reallocates a new region of ram and copies the current 
data into it, adding a few extra bytes based on heuristics, so that 
small changes don't need to constantly re-allocate ram.

Correct, that is how I see it and why I ask about this.  Because 
to me this makes more sense as to assigning the length before hand.

no since strings are objects, just like all datatypes.  they have 
internal counters for offset, length, etc.  the string itself really 
is just a buffer.  which is why in R2 strings and binary really are 
the same thing.  in R3 this is quite different.

the binary and character lengths of strings aren't the same thing, 
depending on the encoding of strings.

In HLA, the string is prefixed with a dword value indicating max-length, 
then a dword value indicating current length, then the string characters 
and then a null termination.

>> license
...
The copyright, trademark, and other proprietary rights notices
contained in the SOFTWARE may not be removed, altered, or added
to in any way. You may not reverse engineer, decompile, or
disassemble the SOFTWARE.
...

Oh you must be referring to those that dissassembled.  Shame on you 
Steeve and Brian.  ;-)

There's no such exception in the EULA. The EULA is a contract between 
the end user and the publisher. AFAIK, EULA applies in EU too.

Paul : never and I never plan to do so.

Doc, knowing how rebol works internally isn't guess work and disassembling.

some of this comes from RT itself, and even from such things as playing 
around with structs.

By installing or using the SOFTWARE, you are consenting to be
bound 
by and are becoming a party to this AGREEMENT. If you do
not agree 
to all of the terms of this AGREEMENT, do not use the
SOFTWARE.

I'm a guy with principles and respecting the work done by other is 
one of them. I like playing by the rules.

Same way I came up with the initial documentation about REBOL contexts 
and binding back in 2000.

What do you see as the arguments to both have = and == in REBOL?


There are times when you care about strict equality, and times when 
you don't. And it's a balancing act between usability, strictness, 
and risk; similar to the choice of making a language case sensitive 
or not.

Let's look at this example. I have two words, iss and str, that represent 
some value, and they're some datatype. This is charasteristics of 
them:

>> series? iss
== true
>> series? str
== true
>> first iss
== #"a"
>> first str
== #"a"
>> length? iss
== 3
>> length? str
== 3
>> pick str 2
== #"b"
>> pick iss 2
== #"b"
>> str/3
== #"c"
>> iss/3
== #"c"

They seem quite alike. Are they equal?

>> str = iss
== false

Nope! Why not?

>> str
== "abc"
>> iss
== #abc


Again, I see little point in having both equal and strict-equal, 
when there's so little difference between them. If there were more 
differences between them, it would be good arguments to me for having 
both.

Issues and strings should be equal, I think, like integers and decimals 
can be equal, and numbers and chars can be equal.

Also I think, you can do exactly the same things with e.g. blocks 
and lists, but they're not equal:

>> [1 2 3] = make list! [1 2 3]
== false

Obviously, a and b are pointers to the same memory address that  
holds the string.

Or you could use fixnums: integer! and a scale.

I was trying to help new guy on ML, and just would like to ask - 
why is there a difference in evaluation when printing a block, and 
printing first block?

>> colors: [red green blue]
== [red green blue]
>> print colors
255.0.0 0.255.0 0.0.255
>> print first colors
red

so 'first does not reduce the value, while print itself does?

As chris states, there is a difference between how rebol show some 
chars and how they are kept internally

ahh I see. I need this string to compose a url and get a error. thought 
by 'probe the second phantom caret was the failure.

yes, made a string and then to-url. this helps if the caret is hex-encoded 
 %E5

thx, chris and steeve

REBOL has always had a policy of "normalising" times with >59  minutes. 
Even without the to-time and string:
>> 1:111:11
== 2:51:11

I think you may have a typo........My example was 1:0:5000 (two colons). 
I see identical behavior in R2 and R3

The primary example use was in functions, to return the contents 
of a variable and also free the variable. eg, this:

	add-one: func [value][1 +  also value value: none]

replaces older code such as this:

	add-one: func [value][1 + first reduce [value value: none]]

When I think about it, much of this is based on assumption how memory 
is handled in REBOL. We don't really know, because it's not documented. 
When is it good to free a local, and when not? There may be something 
wrong, if this should be handled by the programmer (also when it's 
not documented).

Then it kinda makes sense. But then I think about all the internal 
sub-results, REBOL have to handle, and which I guess is freed by 
garbage collection. Is the problem, that REBOL keep locals, also 
when the funciton is finished?

If I have a simple local in a language like C, I wouldn't allocate 
and free it every time, I call my function.

Have you tested performance when you free locals and if you don't?

I wish we could supress the garbabe collection and had the tools 
to handle that task ourselves.

Has anyone done anything with REBOL and UNC (looks to me like UNC 
is M$ way of keeping networks and drives from being compatible, just 
like Paul Allen's backslash trick from long ago) http://technet.microsoft.com/en-us/library/cc939978.aspx
where \\servername\sharepoint\subdirectory\filename.


Almost looks like Microsoft took the "Refinement" concept of / and 
unrefined it with \

A link to where Gab answered this, and yes, your example looks correct, 
http://www.rebol.org/ml-display-thread.r?m=rmlJZJQ

Maybe a combined get-word! and path! ?

and inside the block, it can be interpreted as a path. basically 
get-path! is a good idea. :-)