AltME groups: search

It's a good thing the Power Mezz package is license compatible too, 
since some of those seem like good, non-disruptive adds.

I've been writing stuff using R3 functions ... and it seems a waste 
of my time to rewrite for R2

The R2/Forward functions that are unlikely to be incorporated in 
R2 directly are APPEND, REMOLD and LIST-DIR; the first two because 
they demonstrate the problem with adding too many options to a function, 
and the latter because it isn't good enough yet, even in the R3 version.

CureCode dismissed tickets are a good place to start - most of those 
were requests for R2 compatibility where inappropriate.

is there a listing of changed natives?  I rarely find that they make 
things better, if they change the api of a function.

There hasn't yet been a final list, but someone (probably me) should 
go through CureCode and make a draft list in DocBase. And there's 
the change list for the releases too, though that is mostly CureCode 
references.

Almost all of the changes have been for the better, though some were 
mostly for greater consistency. Changing the API is OK if the old 
one was really bad, and if there is a rationale for having any change 
be OK. For instance, changes are much more restricted in new R2 releases 
since the continuing existence and development of R2 is the justification 
for allowing the more radical changes in R3.

unless I have a  precise list of changes so I can quickly detect 
side-effects.

In theory, the combined test suite and combined docs should tell 
you the differences. When I get the time I can compile a list of 
relevant CureCode tickets.

We really need a simple list of changes compiled in a single file, 
I have no clue how and when the process of 2.7.7 occured, and really, 
I've got A LOT of other "cats to whip".


FYI, this not a negative comment, just stating that unless someone 
builds a (similar to prior versions) simple list of all changes, 
I won't be able to use 2.7.7... as previous versions have bitten 
me, I can't risk running code in an untrusted environment... I feel 
others with serious tools and services might feel the same..  a single 
little change change cause havoc like data destruction which is only 
apparent, once the process is done.

There were no changes in 2.7.7 that would cause semantic blowups, 
unless your code would fail when any of the new words are defined. 
The same will be the case with 2.7.8 (except the LATIN1? and ASCII? 
functions will no longer work poorly). I was just waiting for Carl 
to get done with the web site changes so there would be a place to 
put the release notes - they're already in the blog comments.

Here's the source to the new 2.7.8 functions that were posted earlier 
today, for those who haven't seen it on chat. I'm posting one function 
per message so bear with me for a sec. Not posting them in !REBOL2 
because that is just for release discussion.

resolve: func [

 "Copy context by setting values in the target from those in the source."
	[catch]
	target [object! port!]
	source [object! port!]

 /only from [block! integer!] "Only specific words (exports) or new 
 words in target (index to tail)"

 /all "Set all words, even those in the target that already have a 
 value"
][
	either only [
		from: either integer? from [

   ; Only set words in the target positioned at the number from or later
			unless positive? from [throw-error 'script 'out-of-range from]
			intersect words-of source at words-of target from
		] [

   ; Only set the words in the target that are also in the from block
			intersect words-of source intersect words-of target from
		]
		foreach word from pick [

   [unless value? in target word [error? set/any in target word get/any 
   word]]
			[error? set/any in target word get/any word]
		] not all ; See below for what this means
	] [

  either all [ ; Override all target words even if they have values
			error? set/any bind words-of source target get/any source
		] [ ; Only set target words if they aren't yet set
			foreach word intersect words-of source words-of target [

    unless value? in target word [error? set/any in target word get/any 
    word]
			]
		]
	]
	also target set [source target from] none
]
; Note: This is native in R3 and supports module! too.

; Implementation note: INTERSECT returns the values from its first 
argument,

; and WORDS-OF returns a block of words that are bound to its argument, 
so
;     intersect words-of source words-of target
; returns a block of words bound to source.

collect-words: func [

 "Collect unique words used in a block (used for context construction)."
	block [block!]
	/deep "Include nested blocks"
	/set "Only include set-words"
	/ignore "Ignore prior words"
	words [object! port! block!] "Words to ignore"
	/local rule word blk w
][

 deep: either deep [[path! | set-path! | lit-path! | into rule]] [any-block!]
	word: either set [set-word!] [any-word!]
	blk: []
	parse block rule: [
		set w word (insert tail blk to-word to-string w) | deep | skip
	]
	also either ignore [
		unless block? words [words: words-of words]
		difference blk intersect blk words
	] [
		unique blk
	] (clear blk set [block words] none)
]
; Note: In R3 this is native, called by MAKE OBJECT!

;   The words are not supposed to be bound, thus the to-word to-string.

what about a mv function where the target isn't relative to the origin? 
would be nice

Thanks Henrik, I wasn't aware, is this recent? still a mv function 
would be nice to have

As I recall, MV isn't possible due to limitations in R2 ports, but 
I may be wrong. You would have to load the entire file into memory 
and save it at the destination. If there already is a MV function, 
then I'm wrong.

It seems that R3 doesn't have a MV function. RENAME can't be used 
for it.

as you can rename from one directory to another with a relative target, 
the mv would only need the target to be converted to relative to 
origin and it should work, no?

seems that BrianH has changed it a lot. I wanted to compare a specific 
source and destination.

From the help:

Returns the relative portion of a file if in a subdirectory,

althought the definition is right "Returns the relative portion of 
a file if in a subdirectory, or the original if not." the function 
name would have suggested to me that in the secon case I get a %../ 
but no

Yeah, sorry, TO-RELATIVE-FILE doesn't do full relative, it's mostly 
a variant of CLEAN-PATH. I wrote the R2/Forward version for use in 
DevBase 2, included it in 2.7.6, then ported it to R3. It's one of 
the two functions where the flow went the other way (IN-DIR being 
the other).

It wasn't based on any preexisting function (not even yours, Henrik), 
it was in response to a real need of REBOL apps, particularly DevBase, 
where the base path is the app path. Carl considered it useful enough 
to include in 2.7.6, same as IN-DIR.

Money! type is nice but not nice enough...

I find it t hard to read the amount when values are large without 
the commas seperating thousands...
I know know some use periods

Has anyone created a function to format money for better display?

amacleod, we've been discussing FORM-DECIMAL for a while in this 
very group. Scroll up to see.

Pekr, that works but  would prefer commas...
but can you go the other way:
	>>$10000000
	==$10'000'000

Thanks, Henrik, I'll have a look..

Working on LOAD this week, actually. Already fixed one bug earlier, 
now working on a tricky blog request.

load in R2 has even returned a word! datatype to me !

(on a binary zip file)

Wouldn't do so in R3 unless the zip file had some contents somewhere 
in it that resembled an embedded script-in-a-block. Zip files occasionally 
have uncompressed data, so that can sometimes liik like an embedded 
script.

What hapens if the data is corrupted by a disk error ?

LOAD should be a quick way to tell whether I'm loading REBOL valid 
data or not. Returning an empty block for an unknown 1 MB binary 
isn't appropriate, because the outcome is suddenly loadable.

is there anything like a lint tool for R2 ... even some simple scripts 
or tools?

lint is sometimes called a program that looks at your code and warns 
you about any potentially stupid behaviour you did

Thinking out loud is good. 


I've used them in the past, and sometimes they make things look a 
*lot* nicer. Other times they end up being a pain, especially when 
you're generating code. That is, you want to generate the arg dynamically.

One criticism of rebol that I saw is that because of no parens , 
you have to know the number of args of each word to understand the 
program like >> first join get-name id << . I don't see this as a 
problem in practice, and like the fact that there are no parens needed. 
 but if you add that some functions can use take args that look just 
like they will eval into values in every other case it becomes a 
little more complex. :) but as I said I am just debating.

I think the lack of parens on function calls is esential thing to 
make programs flow better .. I really like that. You can always add 
parens and if some part is a little more complex. Or if you add all 
the parens you get relisp >> (first (join get-name id)) << :)

On Lisp, exactly. Now, on the paren thing in general, it's not just 
better flow. Remember that REBOL isn't a programming language, it's 
a messaging language. Now, think about dialects. Next, imagine how 
you would make dialects work.

Lit-word arguments

 actually aren't lit-word arguments, this is just a function specification 
 dialect specifying how the arguments are evaluated; in this respect 
 R2 "lit-word arguments" are different thing, than R3 "lit-word" arguments, 
 since in R3 they actually are "sometimes evaluated arguments (get-word! 
 and paren! cause evaluation, otherwise the argument is passed without 
 being evaluated), while in R2 they are not evaluated, just the value 
 of a get-word is retrieved.

Technically, get-words are evaluated by the lit-word calling convention 
in R2 as well, just not parens. Look at this:
>> a: func ['a] [:a]
>> w: 1
== 1
>> a w + 2
** Script Error: Cannot use add on word! value
** Where: halt-view
** Near: a w + 2
>> a :w + 2
== 3


The only difference between "just the value of a get-word is retrieved" 
and "the get-word is evaluated" is that evaluation also triggers 
the op! processing trick, if an operator follows the get-word.

The new or changed mezzanines in R2 2.7.7+ that use the lit-word 
calling convention explicitly evaluate parens to be more like the 
R3 version of the functions. However, since the evaluation is explicit 
within the function rather than performed by DO at the call location, 
op! evaluation isn't triggered:
>> a (w) + 2
** Script Error: Cannot use add on paren! value
** Where: halt-view
** Near: a (w) + 2


Since the lit-word calling convention is only really appropriate 
for functions that act like syntax (like FOR), interactive functions 
that work on files (like CD) or functions that use word values as 
flags (like SECURE), they are never used with functions that take 
as arguments the types of values that are returned by op! expressions 
(numbers, binaries, true or false). So this is never an issue in 
practice, only in bad code that should never work.

ah, I stand corrected:

a: func ['a] [probe :a]
w: 1
a :w + 3
; 4
; == 4

, i.e. the get-word really triggers evaluation even in R2, so the 
only difference is, that paren! does not trigger evaluation in R2.

Is size? %somefile limited to a certain limit? When trying to get 
a size of a 4GB file, it returns 22927360.

(in a limited range:)

Is this logical?

>> negate 2 - 1
== -1
>> - 2 - 1
== -3


(Notice I put space after the first minus making it a unary minus.)

unary minus is Negate (in R3). The R2 case certainly is weird:
- why should binary infix operators behave as prefix?
- why should binary infix - operator become unary prefix?

- why should unary prefix - operator have a different precedence 
than any "normal unary operator in Rebol"?

And the reasons to not have a prefix minus:

- It's ambiguous with the infix minus, and we don't have a compiler 
to resolve the ambiguity.

- The special case of DWIM for a missing first argument slows down 
DO, and makes user-defined ops not work.

What's the best name for such a function?

f: func[words data][forall words [insert data make set-word! words/1 
 data: skip data 2] make object! head data]

Oldes, I have them but in R3.

the first one in an aternative way to make objects.

as-object: func [w d][set w: bind? use w reduce [:first w] d w]

>>as-object [a b c][1 2 3]
== make object! [
    a: 1
    b: 2
	c: 3
]

I named the second one Mixin, with a slightly different code too.

mixin: funco [a [series!] b [series!] /local v][
    parse a: copy a [some [skip if (v: first+ b) insert v] a:]]
    head clear a
]

>>mixin "12345" "abcdefgh"
=="1a2b3c4d5e"

>>mixin [1 2 3 4 5 ] "abcdefgh"
==[1 #"a" 2 #"b" 3 #"c" 4 #"d" 5 #"e"]

I have ALTERNATE and MERGE at the lower levels. The first combines 
two series and returns a new series. The second merges one series 
into another, with a /SKIP refinement. I have TO-SPEC-BLOCK , since 
that's such a useful and common need. I avoided using AS- in the 
past, thinking more standard non-copying coercion funcs would make 
them confusing. Those haven't appeared, so I do use AS- sometimes 
now.

I've just found out from the mailing list that 'exclude creates a 
block of unique items.


so, unique block [block!] is the same as exclude block [block!] [ 
]


So, what's the best way to remove items from a block without making 
the first block unique ?

well, it makes kind of sense, I guess to return something else. returning 
a block from a modifying function seems a little bit like a "round 
circle" to me.

I suppose it's the cheapest thing to return and he thinks it's valuable 
information, so fine. I previously used REMOVE-EACH as a filter though, 
so it means more code for me in some (admittedly rare) circumstances. 
Overall, R3 code tends to be cleaner for most standard code patterns, 
though in some cases the best features are slightly undocumented 
(except in mezzanine code that depends on them).

it's probably a recurring code pattern for him

and now I made a round circle comment :-) (I talk way too much today)

For instance, in R3 (can't check R2 right now on this computer) comparison 
is allowed to unset! and error! values can be done with operators 
if the unset/error value is on the left side of the operator, but 
not on the right. This is because operators redirect to actions, 
and action functions are different depending on their first argument 
(single-dispatch). The comparison actions for unset! and error! can 
compare to other values, but the comparson actions of other types 
don't support comparing to error/unset. The action! function that 
calls the action has a typespec for its first argument that doesn't 
allow error/unset, but the op! redirects to the internal action, 
not the action! function, and it works because it uses a DO trick 
instead of a standard function call.

Sorry, that was awkwardly phrased. If there was a better way of explaining 
that to newbies that didn't require a full article, it would be in 
the docs.

Basically, the functions that you see in REBOL aren't necessarily 
the functions that are actually called. For each function type DO 
calls them a little differently, and this eventually gets to the 
actual function code. For most functions the argument spec type checking 
is done by DO, not the function itself. For natives (or mezzanines 
with explicit type checking) there can sometimes be some extra checking. 
Apparently all actions have to do some extra internal type checking 
because the argument compatibility rules are too weird to be expressable 
using the REBOL function spec syntax, so that syntax doesn't tell 
the whole story sometimes - the source of many dismissed documentation 
bug tickets, I'm afraid.

... bug when trying to use EMPTY? as an actor in a scheme

As for EMPTY? and TAIL?, a function has no way of knowing what it 
is called. That error message generated from within the TAIL? port! 
action guessed wrong.

Oh, it gets trickier (in theory - I've had to do a lot of scientific 
method on the internals, not decompiling). I think that DO does some 
of the function call work, and the function type itself does the 
rest through an internal action. DO handles the evaluation rules 
and builds the stack frame, then passes along that stack frame to 
the function dispatch action of the function type for it to redirect 
to the real code in a type-specific way.


Now it definitely works that way, the only question is whether the 
type-specific dispatch code is built into DO itself, accessed through 
the action dispatch mechanism, or action code called directly without 
going through the action dispatch mechanism. Only Carl or a decompiler 
could say for sure. But really, it doesn't matter because the behavior 
is the same in any case.

This is how LOAD can be a mezzanine, btw, and still be called by 
DO. And it's how the module system can be mostly mezzanine too.

when i construct ports with a spec block, i would rather prefer to 
use dialect (using delect) instead of passing a prototype of the 
spec object

Yeah, I've cleaned up begin and make-module a bit, and rewritten 
DO completely many times, but make-port is still on my list.

It actually does use a dialect already, that just resembles an object 
spec.

not really a dialect, just a bunch of case/if

using  DELECT would allow a more versatile syntax.

I'm not doing anything with DELECT until after it's settled. A complete 
rewrite of DELECT with a new dialect model is scheduled for the next 
host kit release.

Maybe we should also have a set! datatype ( need to use a different 
name though ) to indicate a unique unordered collection

a tuple is an IP by default,
an integer is a port-id by default.
etc...

And a scheme is nothing by default.

a word is scheme by default :)
open [http 12.34.45.56 80]

Graham, we have set functions that work with the block! type, we 
don't need a set! type. There is a budget for built-in types - we 
can only have a limited number of them. There has to be a major need 
that can't be handled easily enough otherwise for a new built-in 
datatype to be added. A set! type might merit a user-defined datatype, 
or a spoofed datatype like the ones I added to 2.7.7+, but it's not 
an extreme enough difference from the behavior of block! with set 
functions to merit a full datatype.

Seems a bit of overhead if you're trying to maintain a set if you 
have to check each time you add something if it already exists or 
not.

On the other hand, if your data has good locality you can do a bitset 
minus a base value and it can still be small. Say if you are doing 
the numbers from 100000 to 100100 just subtract 100000 first.

map! as a primary index , and bitsets for linked indexes when data 
have good localities

Yup. Not a bad project, and it should even be fast in mezzanine code. 
Maybe as a user-defined index type if you like, though a set of related 
functions would do.

Though sparse-bitset! would be a more accurate name due to the integer/char 
restriction for contents.

Found ...

f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
]

A sparse index lookup with map!/bitset! in R3 would just be: find 
select index to-integer x / period x

I also often use a FILTER function which is just a wrapper around 
remove-each which does a copy on the source input and adds a NOT 
to the comparison block you provide.


this means you keep data instead of removing it and don't break the 
original series.

a keep-each

a keep-each

Actually, it's so easy to add a copy where you need, that i think 
all the  serie's constructing native functions should update the 
input by default, rather than construncting new ones.
Think About UNION, UNIQUE, INTERSECT etc...

They are handy functions but involve too much overhead on big series.

I would love the /INTO refinement be added to all series manipulators.

This way we can make a huge buffer and reuse it all the time.

didn't I suggest we have a set! datatype?

and yes, it's common to want to maintain a set ...

INCLUDE isn't a good name for it, though, because of conflicting 
with the much more common INCLUDE for dependencies.

Steeve, you are presuming that Carl has a use for ALTER - I haven't 
seen him use it yet.

BrianH, in 2.7.7:

types-of :now

returns a lot of type blocks. Is that correct?

Refinement arguments are either of type NONE! or of type LOGIC!, 
so there is a reasoning.

Btw, that APPLY trick with the missing arguments is used in USE in 
R3 to initialize the words to none. The source:
use: make function! [[
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]]

Regarding cutting off arguments, that was "just another" typo. The 
last should have been 8 NONEs ending in a TRUE for the /PRECISE refinement.

Oh, I never realised that USE is just a mezzanine ... cool stuff!

USE is a mezzanine in R3, a native in R2. They made the behavior 
of R2's USE into a function datatype: closure!. And then Ladislav 
and I backported closure! to R2 as a fake datatype (though USE doesn't 
use it).

The reference to the block provided is passed by value, not by name. 
You can't change the position of it, since position is a attribute 
of the block reference, not the block itself.

since position is a attribute of the block reference, not the block 
itself
 - that wasn't something I knew already ...

This means that SKIP is a pure function for series, returning a reference 
to a new position - while it is modifying when applied to ports, 
changing the internal position. Same with the other position functions 
like AT, HEAD and TAIL.

I know such things when writing code, but more in a subconcious way. 
Of course different references to the same block having different 
positions doesn't go together with position being an attribute of 
the block (series) itself. That's of course obvious after only a 
little amount of thinking ;-)