World: r3wp

(closer to on topic) The same goes for GPL REBOL scripts, like the 
BEER framework before its relicensing.

Brian, please, this is just FUD. There is no GPL in play at all here. 
Boron is LGPL

I notice you write *GPL, and while I could agree with stating that 
GPL is a one-way street, LGPL is not

LGPL projects can be mixed with or incorporate code of other licenses, 
with some acceptable limits, more or less. However, the code itself 
can't be adapted to projects with more permissive or closed licenses, 
without carrying over those restrictions, or in the case of LGPL 
quaranteening the code in seperately linkable portions. Less restrictions 
than GPL, more than Classpath, but still one-way. Not FUD, but definitely 
off topic.

Porting code in Boron itself - rather than code that was just written 
in Boron - to Red itself without relicensing it would make Red mixed-license, 
BSD and LGPL. Going the other way, porting code in the Red project 
to the Boron project wouldn't affect the license of Boron; it could 
stay LGPL only.

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

And the original authors of any LGPL code in Boron could relicense 
it as BSD if they want it added to Red. No problem, if the author 
agrees to it.

quaranteening -> quaranteeing

I miss the auto-spellchecking of web browser text boxes when in AltME 
:(

I believe that it is most unlikely that any code will be ported from 
boron to Red because Red will first be written in REBOL and eventually 
in Red whilst boron is written in C.

Yes

Brian, it's FUD because you are changing the topic. You're jumping 
from the effect of the licence of platforms on application code to 
the ability to mix and match platform code

You're also steering the topic to discussing the GPL, which has nothing 
to do with this

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.

I am firmly of the belief that all problems are solveable, so FUD 
is against my principles. Sorry if I took offence at your initial 
FUD remark.

I am sure you mean well. That's why I keep pointing out that these 
issues should not be conflated :-)

Peter changed the topic when he said "I don't believe it is GPL because 
of that just as all Java code is not GPL because Java is GPL.", and 
that is what needed clarification. Unfortunately, I couldn't move 
that message to the Licensing group, or edit my responses to be more 
clear (stupid AltME).

Sorry, that went in the wrong group.

What about using just:
	p:   integer!
instead of:
	p:   pointer [integer!]

hm... probably not.. because it would be problematic with aliases

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.

same in 4.7... or is it by design?

let me see that...

Do you mean pointer instead of pointer! ?

These two are different, pointer! is used to refer to the datatype 
and have to be used in function's spec blocks. Pointer (without !) 
is a keyword (like struct) used to represent a literal pointer value.

You're using the http://issue.cc/r3/546style AS operation?

Adding to this, pointer! can also be used for type casting (following 
AS keyword).

Is that typecast changing the integer to a c-string! (a kind of pointer 
to byte), or is it changing the pointer to the integer to a c-string!?

It seems to me that the latter would be:
    s: as c-string! c

In the example from 4.6.6, c/value refer to the pointed integer value, 
so it is the former, integer! -> c-string! (== pointer! [byte!])

Exactly.

I might have been inspired by your ticket (I remember vaguely reading 
it a long time ago). Using AS for type casting, was a natural extension 
of the as-string / as-binary syntax from R2.

As was the ticket. Remember that in Red proper, AS should do conversions, 
not casting, for safety. Given all this typecasting, it is looking 
more and more like Red proper should have the handle! type instead 
of pointers, where a handle! would be a pointer-like thing with no 
dereferencing, arithmetic, or value setting or getting in Red itself. 
Then let Red/System cast the handle! to whatever pointer type it 
needs to.

And then back to a handle! if it's going to be passed back to Red 
code.

Pardon my mistake if you weren't thinking of Red/System as being 
a bit like unsafe code sections in C#, JNI code in Java, or extensions 
in R3.

Yes, that is a good option. Red has to be safe, that's one of the 
main reason for having Red/System dialect.

No mistake, that is a correct way to see the separation between Red 
and Red/System.

Cool. That will allow us to reuse some of the the reasoning about 
code that has been made about those situations in other languages, 
and tweak the model to learn from their lessons.

Precisely. :-)

I was thinking about struct parameters to functions. If C doesn't 
allow struct parameters and return values, only struct references 
or pointers, then Red should follow that model when declaring functions 
with the cdecl calling convention, and similar restrictions for stdcall, 
fastcall, etc. Then when we need to support other calling conventions 
that do support passing actual structs as parameters, we can just 
add to the list (pascal or Delphi, for instance).

I haven't had a chance to look yet... Does the revised struct model 
support seeing pointers as equivalent to references to structs with 
one member?

Implicitly, yes.

Calling convention: adding new ones shouldn't require much work (unless 
they are very exotic).

BTW, I was thinking these last days that I maybe should allocate 
a week before starting the work on Red's compiler, to implement an 
experimental JVM bytecode emitter (and a .class file format). The 
reason for that is to have a 2nd emitter (in addition to IA32) that 
is addressing a very different architecture. This should help make 
a cleaner abstraction layer for upcoming emitters (especially those 
not written by me).

I might alternatively pick up CLR for that task, thought (less work 
for the file format as it is basically PE).

A good calling convention to add would be JNI, for Java and Dalvik 
code. We would have to reverse-engineer the behavior of the C macros 
and types that implement this in the JDK and NDK.

This should help make a cleaner abstraction layer

 To be more accurate, I think the current one is OK, but it will certainly 
 need some tweaking when a 2nd emitter will be added, so better tweak 
 it sooner than later.

Brian: what about JNA? Isn't that interface better than JNI?

Never heard of JNA. Java and Dalvik both use JNI.

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

Sounds interesting. Is it an addon that can be used on a standard 
JVM? I'll look it over later, especially to see if Dalvik supports 
it.