AltME groups: search

The declarative forms, like they are written in the specs of a function 
are trully lit-word! and get-word.
I don't understand why you get so upset about that

Ladislav's terms are better, in the sense of being more descriptive, 
but I'm unlikely to remember them because I've been using the old 
designations for 10+ years. I'll try, but don't give me a hard time 
if I don't get it at first.

To add more confusion to the mix, lit-arg(ument) and get-arg(ument) 
worked fine as terms in the past :)

Moreover, MOLD usually does preserve REBOL code in the sense, that 
you get the same program when loading the result of MOLD more often 
than not.

btw... why we need the parens to get the expected result?

>> mold/all true: not (false: true)
== "#[true]"

>> mold/all (true: not (false: true))
== "#[false]"

It's kinda interesting, how complexity sneak into a language like 
REBOL. I have never used constructs. I save REBOL data and code to 
disk all the time. I even created a file system/database, that is 
all about saving and loading data and code. I get along using a combination 
of simple REBOL functions like SAVE, LOAD, REDUCE and DO.

When copying a string, you get what you see.

When copying deep a block containing strings, you get more than what 
you see.

I am doing some tel. report automatic checking, and I need an advice 
- how do I get easily substracted two time values going thru the 
midnight?

>> (fourth 29-7-2011/00:02:00) - (fourth 28-7-2011/23:52:00)
== -23:50


If I substract whole date value, it returns 1, it simply counts just 
dates, not time ...

There is a lot of type checking in REBOL. I feel too much sometimes. 
Calling many functions involve two types of type checking, as I see 
it. Take ADD. Values can be: number pair char money date time tuple
If I try call ADD with some other type, I get an error:

>> add "a" 1

** Script Error: add expected value1 argument of type: number pair 
char money date time tuple

I can e.g. add pairs:

>> add 1x1 1x2    
== 2x3

and issues:

>> add 1.1.1 1.2.3
== 2.3.4

But I can't add a pair and an issue:

>> add 1x1 1.2.3
** Script Error: Expected one of: pair! - not: tuple!


So that's kinda two different type checking. First what the function 
takes as arguments, then what actually makes sense. If the user also 
need to make type checking, three checks are then involved. It could 
be, the first kind isn't done explicit for natives, and that it's 
kinda built in with the second kind. But for non-native functions, 
the first type checking is done:

>> f: func [v [integer!]] [v]
>> f "a"
** Script Error: f expected v argument of type: integer

I came across a funny thing with binding. We've learnt, that the 
binding of words in a block is done, when the words are put into 
the block. This little example with two functions illustrate that:

blk: []

f: func [
	v
][
	insert blk 'v
	g v
]

g: func [
	v
][
	if v = 3 [exit]
	print ["v:" v]
	probe reduce blk
	g v + 1
]


F puts the word V into the block, then calls G, that has its own 
V. When G reduce the block, we see the original value of V from F, 
even if Gs V is changed:

>> f 1
v: 1
[1]
v: 2
[1]


Then I tried this next function, which puts V in the block in the 
start, then call itself with changed V value:

f: func [
	v
][
	if v = 3 [exit]
	if v = 1 [insert blk 'v]
	print ["v:" v]
	probe reduce blk
	f v + 1
]

>> clear blk
== []
>> f 1
v: 1
[1]
v: 2
[2]


This time, we see the latest version of V. The first V, which has 
the value 1, was put in the block, and it's still there somewhere 
in the system, but we get the V value from the latest F.

Is this a problem or a benefit, or is it just a bit strange?

The first V, which has the value 1, was put in the block, and it's 
still there somewhere in the system, but we get the V value from 
the latest F.

 - this is again false, you should read the bindology article, where 
 the behaviour is analyzed, modelled and explained

That bug is really weird! I put in some prints to show, what's going 
on:

f: func [x] [
    get in make object! [
        a: "ok"
        if x = 1 [
            a: "bug!"
            print ["f 2 :" f 2]
            a: "ok"
        ]
		print ["a:" a "x:" x]
    ] 'a
]

When I run it, I get:

>> f 1      
a: ok x: 2
f 2 : ok
a: ok x: 1
== "bug!"

I can't get my head around, what's going on internally.

I can't get my head around, what's going on internally.

 - I do not know if you already got your head around or not, but the 
 behaviour is exaplained by the simulation.

To me, it's like if the following code would return "bug":

>> o: context [a: "bug" a: "ok"]
>> get in o 'a
== "ok"

The fact is, that in the article, there is a simulation fully explaining 
what is going on. And, moreover, the MAKE OBJECT! [...] binds the 
[...] block, which is a modification, that does not get "reversed". 
And, moreover, there is a code that shows how to "cure" it.

Gabriele, I guess, you're joking, but to answer your question: it 
would be simple, if the above function returning "bug!" would instead 
return "ok" like this function:

g: does [
	get in make object! [
		a: "ok"
		a: "bug!"
		get in make object! [
			a: "ok"
		] 'a
		a: "ok"
	] 'a
]

>> g
== "ok"

In REBOL, literal blocks are just literal blocks. If you modify them... 
they are modified. Binding a block modifies the words inside the 
block, ie. it modifies the block. It can't get any simpler than this.


Now, you may argue that MAKE OBJECT! should bind/copy the block instead; 
the reason it does not is purely performance (as 99.99% of the time 
the copy is not necessary). In that 0.01% of cases where you need 
it... you just write MAKE OBJECT! COPY/DEEP [...] instead.

BTW, did you already succeed to get your head around the difference 
between a function and a closure?

Gettin' rid of this bug doesn't mean, we should or would sacrifice 
self-modifying code

 - actually, you get rid of the bug by not writing a self-modifying 
 code. Unless you forbid me to write a self-modifying code, I can 
 always recreate the bug.

Anyway, for the readers that are curious, here is the explanation:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1

While, we still get:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third a ; == [print 'ok a: 1]

Posting once again, to not confuse anybody:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1
get third a ; == [print 'ok a: 1]

>> o: context [a: "x"]
>> p: copy o []
>> append get in o 'a "y"
>> ? p ; a == "xy"

when I change 'a in O, it changes in P as well.

Oh shame on me! I forgot to GET the values.. Thank you.

One more question, I use COPY on objects to be able to use same series! 
values in different objects, is that right?
I mean pointing to the same series inside different objects.

In R2 I do like that:
>> o: context [a: ""]
>> p: context [b: get in o 'a]
>> append p/b "*"
>> o/a
== "*"

Gregg, I get back to you, as answering your questions might take 
this into another direction.

Ok, now we're getting somewhere. A question is raised, if MAKE should 
copy arguments given to it. This isn't the bug, as I see it, and 
I'll explain that a bit later.


But first, if MAKE disn't copy the body block when making a function, 
then we would be able to change the function by changing the original 
block. Like:

>> b: []   
== []
>> f: make function! [] b
>> f
>> insert b 42
== []
>> f


After the last call to f, we would get the result 42, if the body 
block wasn't copied. This is not desirable to me. Is it to you guys?

Let's look at the example again. My version of the example is this:

f: func [x] [
    get in make object! [
        a: "ok"
        if x = 1 [
            a: "bug!"
            f 2
            a: "ok"
        ]
    ] 'a
]

I can pick the inner-most block this way:

>> b1: pick pick pick :f 2 5 7
== [
    a: "bug!" 
    f 2 
    a: "ok"
]

Now I run the example and pick the block again:

>> b2: pick pick pick :f 2 5 7
== [
    a: "bug!" 
    f 2 
    a: "ok"
]
>> same? b1 b2
== true

It's the same block.

John, it sounds like where you get confused, or think of things as 
bugs or design flaws, is when having your REBOL "That's funny!" moments, 
borne of deep tinkering. Aside from the "copy series in funcs" behavior, 
which I think bites many people at some point, your issues don't 
come from writing application code in REBOL and bumping up against 
REBOL's behavior. Rather, it seems that REBOL's implementation and 
design don't match your expecations in these cases, and you really 
want it to. :-)


The reason I asked about consequences is because you may want a change 
that affects other users negatively. Imagine REBOLers as being in 
one of two groups. Group A is the gurus. They have internalized REBOLs 
design, understand it deeply, and use BIND and recursive PARSE rules 
without fear. That group is very small. Group C contains everybody 
else, which includes people that don't know about using /local with 
funcs, and suggest REBOL should use  = for "assignment". They have 
never used USE, BIND, or many other functions, because they aren't 
sure how they work. Some of them know a little about series references, 
so they always use COPY to be safe. (Yes, group B exists too, but 
they are much more like C than A).


If REBOL were meant only for A users, it would be very different. 
As a designer, it seems pragmatic to make it so things work well 
for the B and C users who, when they hit a problem that requires 
advanced understanding, will work around issues with the bits they 
understand (and adding many COPY calls), no matter how inelegant. 
Group A users may suffer at their expense, but I'm OK with that, 
because I'm not one of them.

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

and it's more useful than the other way I think. Once I wrote a function 
to test if two object is similar. It looks a bit silly but works 
for me. Can be extended to test values also:

similar?: func [
    {Returns true if both object has same words in same types.}
    o [object!] p [object!] /local test
][

    test: [if not equal? type? get in o word type? get in p word [return 
    false]]
    foreach word sort first o test
    foreach word sort first p test
    true
]

As suggested by some people, I am making the COMMENT directive standard, 
improving all the directives, and enhancing the way how INCLUDE generates/uses 
errors. When INCLUDE is traversing a large set of files, I feel it 
convenient not only to get an error, but also the file, where the 
error occurred.

That is possible by either


- enhancing the error to contain the information about the file, 
where it occurred

- storing the name of the culprit file somewhere else, not into the 
error itself

The former situation (the information about the "culprit file" is 
stored in the error) looks as follows, currently:

performing localization
** User Error: INCLUDE
** Near: do last-error: make error! spec


The trouble is, that the present error-forming code does not show 
all the attributes. If you examine the error on your own, you get:

print mold disarm last-error

make object! [
    code: 802
    type: 'user
    id: 'message
    arg1: 'syntax
    arg2: %gui/include.r
    arg3: [
        id: missing
        arg1: "end-of-block"
        arg2: "["
        arg3: none
        near: "(line 949) ]"
    ]
    near: [do last-error: make error! spec]
    where: none
]


, which shows all the data as "stored" in the error, which is referred 
(for convenience) by the LAST-ERROR variable

The second option would be to not "enhance" the error, in which case 
it might look like:

** Syntax Error: Missing [ at end-of-script
** Near: (line 949) [

, and examining the error we would get:

make object! [
 id: missing
        arg1: "end-of-block"
        arg2: "["
        arg3: none
        near: "(line 949) ]"
]


here, clearly, the information that it was an error in the %actions/tabs/data.r 
file is missing, but the "standard" error message is more informative. 
The missing CULPRIT-FILE information could be supplied by defining 
a CULPRIT-FILE variable for that purpose. Any preference(s) which 
alternative you might prefer?

The second approach has got the following advantages:


+ no need to "intercept" the error, since no "error enhancement" 
needs to be done

+ the error is displayed by the interpreter in a standard way, the 
user needs just to get the CULPRIT-FILE name elsewhere

Disadvantages:


- the error does not contain the CULPRIT-FILE information, which 
is important, thus, the user needs to look for it elsewhere

(did not even get any error, as far as I remember)

I do not need to, if I want to obtain %1 somewhere, I can write:

["this is a string containing '%1'" "%1"]

, and I get it (although substituted)

using NEXT with call-by-word (I like the name :) ) looks ok to me, 
but I remember that, "guru"s may say "it leads performance overhead 
for next, as it is a native and used a lot. it should check the argument 
and get-value if it is a word."

I like the idea, but it looks it needs using too much GET value in 
all the actions above.

You can easily see the extra overhead:
SOURCE ++
additional IF, GET, SET and CASEs..

>> f: func [v] [either word? v [get v] [v]]
>> f 1
== 1
>> a: 2
== 2
>> f 'a
== 2

Mezzanine example:


>> my-next: func [series] [either word? series [set series next get 
series] [next series]]
>> my-next [a b c]
== [b c]
>> block: [a b c]
== [a b c]
>> my-next 'block
== [b c]
>> block
== [b c]

Guys, thanks for all the input. I didn't mean to cause this much 
excitement. :-) I just wanted to get my crazy DB program to work. 
And by the way, it does, at least so far.

I sometimes wonder about having a NEXT that does not move to the 
tail, but only to the last element in cases where you always do a 
FIRST on the block afterwards to get the first element.

Then you don't need the trivial

unless tail? next blah [blah: next blah]

idiom.

In R2:

>> type? :sine
== native!
>> type? :sine/radians
** Script Error: sine expected value argument of type: number

In R3:

>> type? :sine
== native!
>> type? :sine/radians
== native!
>> do :sine 30
== 0.5
>> do :sine/radians 30
== 0.5			; Wrong result!?

Shouldn't things like :sine/radians just be invalid get-paths?

In R2:

>> type? first [:sine/radians]
== path!

in R3:

>> type? first [:sine/radians]
== get-path!

(R2 does not have get-paths)

Also, in R2 operators are evaluated by DO itself, which has a set 
of keywords that it transforms from operator to prefix function syntax. 
R3 does this swap by value, not by name, so operator renaming is 
possible. However, this leads to behavior like this:
>> f: func [a op b] [a op b b]
>> f 1 get quote / 2
== 2

>> f: func [a op b] [op a b]
>> f 1 get quote / 2
** Script error: op operator is missing an argument
** Where: f
** Near: f 1 get quote / 2


This is why, when you are accepting and calling function values, 
it's best to either limit yourself to the types of functions you 
are expecting, or use APPLY.
>> f: func [a op b] [apply :op [a b]]
>> f 1 get quote / 2
== 0.5
>> f 1 :divide 2
== 0.5

It is a potential security hole, but not more of one than assigning 
a function to an object field. It requires the same ASSERT/type call 
to screen for it. Still, it would be nice if it triggered an error 
on evaluation, especially since newbies would benefit from that error 
when they naively try to do a get-path for a function call instead 
of using APPLY or a direct call.

I'm trying to reach a time server but having trouble.

I can get a time from my rebol based time server on my server with 
"read daytime://myserver.com"

but if I use it for any of the well known online servers I get :
>> read daytime://time-b.nist.gov
== ""
>> read daytime://nist1-ny.ustiming.org
== ""


sometimes it seems to work but more often than not I get an empty 
string

2 amacleod: time protocol is not very accurate, the same levely of 
accuracy you can get by reading any HTML size and distile the time 
from HTML header. OTOH NTP protocol is able to get milisecond accuracy 
but by quite difficult handshake and as far as I know not yet written 
for rebol

Does it work? Or do you hit a 4GB boundary with some internal structures, 
so there is an error, you don't get out?

I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r

To sort files you can use for example:

dir: %/e/DCIM/100CANON/
t: now/time/precise
result: copy []
foreach file read dir [
	error? try [
		ctx-exif/parse-file dir/:file
		exifdate: ctx-exif/get-tag-value 306
		repend result [exifdate dir/:file]
	]
]

sort/skip result 2

print ["sorted" (length? result) / 2 "files in" now/time/precise 
- t]
result

;>>sorted 120 files in 0:00:00.153

Anyone knows of a simple way to get to the binary encoding of a decimal! 
using just REBOL/Core (i.e. no struct!, no /library)?

Building in the type test functions into the language would have 
the same effect. The type inferencer could determine some of them 
statically. If they are regular functions, that would require partial 
evaluation to get the same effect.

My old version of LOAD used it a lot, but the new version uses the 
CASE/all style to get the same effect with less overhead.

Code like this in FIND-ALL:
    assert [series? orig: get series]

could be internally rewritten into this as part of the compilation 
process:
    orig: get series assert/type [orig series!]

Enough for tonight, it's very late here. I just wanted to give you 
some taste of what Red/System would look like. I'll work on Cheyenne 
new release and new documentation tomorrow, I should be able to get 
back to Red after that. I hope to be able to put the current codebase 
on github during the weekend.

Let me get this straight: Is this instead of using C?

I'm not sure I get your "DSL like emiter"? Do you mean compiling 
to an intermediate dialect, that would be compiled to native code?

If you set the compilation logs to 3 (-vvv) and take only the entries 
starting with ">>" you'll get a feeling of what such IR would be. 
In fact, just recording these steps instead of reducing them directly 
to native code, would almost give you a good IR to start making optimizations 
(other than the very trivial ones that I've included in IA32.r).

libc support will come as soon as we get support for a loader done

while [yes = yes] 

 => this cries for a better logic values support ;-) I was working 
 on a TRUE/FALSE support in the train when coming to ReBorCon 2011, 
 but never finished it. I need to get back on it.

I can compile it with the last Red/System version (adding calling 
converbut I get a "zmq_err0 entry point not found". I guess, there's 
a regression in the compiler or an incompatible change. I'll check 
that after publising the new revision with extended Linux support.

That would be safer, until we get a smarter one.

I wanted to get back to the roots (80's for me) of computing, a time 
where an entire OS + programming langage could fit in a 16KB ROM 
;-).

When I compile the tests on Linux and try to run them on Syllable, 
I get this in the kernel log:

I don't know, I'll have to dive into our loader. It's much like Red: 
the minimum we needed over time to get things working :-)

We determined that the shared library trick isn't even necessary, 
so we have a backburner plan to change it. So I hope it will be possible 
to get regular executables to run

(Take that with a sufficiently sized grain of salt, as I don't know 
anything about how ASLR on Windows works. But I find it hard to imagine 
how they would get away without PIC :)

Here we go, hello.reds now results in a 1065 bytes binary (882 previously). 
For this bloat, you get the following information:

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES 
  Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00 
       0   0  0

  [ 1] .text             PROGBITS        08048074 000074 000290 00 
   AX  0   0  4

  [ 2] .data             PROGBITS        08048304 000304 000085 00 
   WA  0   0  4

  [ 3] .shstrtab         STRTAB          00000000 000372 000017 00 
       0   0  1

Ask, and I'm sure you will get a LGPL version.

For that matter, why would he make a GPL library for tutorial purposes? 
You can get in legal trouble for reading that code if you actually 
use what you learn to write code that isn't GPL licensed. This seems 
like poor planning, or just being mean. Is there at least a commercial 
license?

there is. and where do you get the idea from that this library is 
for tutorial purposes?

Unfortunately, the public domain argument won't get far:
**  Copyright 2010 REBOL Technologies
**  All rights reserved.

I first wrote 1MB, then I raised it thinking of possible libs that 
could get statically linked by users. But, it could be even easier, 
just hardcoding the DATA address offset somewhere in the CODE segment 
at linking time might be enough (no need to reserve fixed space in 
CODE segment).

Another milestone reached ;) Now I get "segmentation fault" instead 
of "illegal instruction" :)

Nick: french talks passed through Google's translation service really 
do look weird...but the meaning seems mostly preserved. About Red, 
the potential is huge: draw a triangle with C, Lua and REBOL on each 
corner and put Red in the middle, you'll get a feeling of the possibilities. 
;-)

Anyway, I'm not against switching to a better (unique) name, but 
it needs really to fill my criteria:
- short
- sounds ok in english
- doesn't sound bad in french
- have a meaning related to the language
- if possible, not a backronym (they are usually bad)

- has .org / .com / .net free (it's ok if adding "-lang" is needed 
for that)
- I need to like it (or at least be able to get accustomed to it)

Brian: it might be too high-level for Red/System. I need to have 
a fine-grained control on memory accesses. A variable-size datatype 
would get in the way. But I admit I didn't consider that option, 
I would need to think about it deeper to see if it could be an advantage.

brian "I think that readable trumps consise in this case, Maxim."

well, right now, red is much less readable than C when types are 
involved. 


when I look at something like this (which is proposed as an extension 
to current type syntax): 
p: &[array! [20 integer!] 0]

I get nervous cause this is the anti-thesis of REBOL
why can't it be expressed like:

p[20]:  0  ; infered type


p[13 string!]: "hello"  ; explicit type, though usually superfluous

I.e. while you can get rid of pointer! and just use &[integer!], 
that is fine. But if you specify integer! as always being a 32-bit 
integer, you lose out in hiding cross-platform quirks.

Though I would change this:
    p: &[pointer! [string!] 0]             ;-- char **p = 0
to this:
    p: &[&[string!] 0]                         ;-- char **p = 0

You can get rid of the pointer! name altogether and still keep the 
syntactic shortcut.

But you might be able to get by with only structure references and 
not have real structure variables. Then structs would be conversion 
metaphors.

considering callbacks are just pointers, its not that big a deal 
to provide the capabilities...  all you need is a way to get the 
address of a function rather than call call it, and you're good to 
go.  this could be achieved easily with get-word notation...

cause, I never get seg faults, always bus errors :-)

I know how to get both :)

Because github is the most known one, there's a lot of programmer 
there, so that the place where Red can get the most visibility.

http redirection for the root domain looks good:

$ telnet red-lang.org 80
Trying 216.239.34.21...
Connected to red-lang.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: red-lang.org

HTTP/1.1 302 Found
Location: http://www.red-lang.org/

I've only succeeded since a billing snafu caused my email provider 
to delete a year's worth of email, about 5 years ago or so. All I 
missed was the REBOL mailing list, so I just never resubscribed to 
it. Since then, people call or text msg me to tell me they've sent 
me email, or I get it several months later. Paper mail is nearly 
dead for me too.

so red is compiled but then it's systeme dependant and we can't test 
small chunks of code like in R2 consol in my opinion one of the strong 
point of rebol was this ability to open it's consol test an epurated 
bunch of code and then once working enhance it on our script file. 
I would like red somehow to get that  ability maybe it will be possible 
in the IDE or as a side stuff. For me the 2 best points of rebol 
were reflexivity code <--> data code = data data = code and parse. 
Even if I didn't fully understand parse I made a great use in my 
productions in rebol script VID oriented of the reflexivity code 
<---> data. All the other arguments of rebol are not really interresting 
since they are double sided and so not objective and so just a matter 
of mood and point of view.

There will be limits to code <--> data, because Red is compiled. 
Basically the same limitations as a modern compiled Lisp. Source 
code will be data, but not as much after it is compiled. However, 
when we get a JIT then that data --> code thing will be available 
at runtime. If it's done right, reflection APIs might be able to 
recreate or save source too.

After re-reading the new specs draft, I noticed a few errors in the 
pointer! examples. Also, I think that having struct! passed as value 
by default was a bad move, it makes the "passed by reference" case 
too verbose (requires to declare a pointer! [struct! ...] and a get-word! 
syntax). I think that I'll revert default struct to be passed "by 
reference" and find a special syntax for the extremely rare cases 
when a struct needs to be passed by value. I can't remember any OS 
API nor mainstream C lib that require passing struct by value (anyone?).

Nicolas: "Why is it more popular than boron? Did the boron guy start 
red?"

A few apparent reasons:
- Red is new (shiny!).

- Red is compiled, which is a new challenge for us. Boron is interpreted, 
like REBOL.

- Red is BSD licensed; Boron is LGPL licensed. Most of the REBOL 
community is not very (L)GPL-friendly for various reasons, such as 
license incompatibility with REBOL.

- Red being compiled and BSD means that it doesn't directly compete 
with REBOL, and is considered to be complementary. We might even 
be able to get them to work together directly without causing license 
problems. This means that more people who contribute to REBOL itself 
can contribute to Red as well, which means that there are more qualified 
contributors available early on.

- Doc made Red, and we like Doc, and he is here. Karl Robillard is 
not here, afaik (I'm sure we'd like him if given the chance).

Doc - do you think we can get Red to the following page, or is it 
too preliminary?

http://en.wikipedia.org/wiki/List_of_programming_languages

It's very hard to get into SoC, beginning with the rush to register, 
and if you don't have the organisation to conduct the mentoring, 
or your project is too eccentric for students to get into quickly, 
it's fairly pointless

It's also questionable if the students will go on to maintain their 
code. The biggest advantage if you do get in is simply the marketing, 
because people suddenly think you're associated with Google

Yes, I saw that and want to test it, but I'm very busy. Maybe I'll 
get to it tomorrow

None of this affects user code written in either language though.

When I realized that Peter was talking about user code, not code 
from Boron itself, I said "Cool." and then just clarified something 
based on what Peter said next. It was not steering the conversation, 
though I apologize if it gave that impression. License compatibility 
for contributions is a real problem (which is why I reacted to the 
FUD remark), but it is a problem with limited scope, and is solveable 
even within that scope. My response to that FUD remark gives the 
overview of the limited scope of the problem, and how to get around 
it (relicensing with author permission). No unsolveable problems.

btw... in the example in chapter 4.6.6 is probably typo:
foo: func [
   /local
       c [pointer! [integer!]]
       s [c-string!]
][
   c: get-hello
   s: as c-string! c/value
   prin s
]

there should be just:
       c [pointer [integer!]]

as used above.

brian, can we already build the FROM as an op in R3?  I've tried 
using the to-op and I can never get it to work.