World: r3wp

But, you started it. ;) -- all related to the meaning of "quit"

What about suggested names to FOR-ALL? Not important, but there were 
some suggestions in related tickets (and blog) ... e.g. FORFOUND 
(sounds a bit weird, so maybe FORFIND)? :-)

The question on tuples was related to IPv6 addresses. Just thinking 
about how the 128 bits might map into a type and syntax.

Having a different datatype for IPv6 addresses would pay off in practice 
- the networking code would be more efficient. Even if that other 
type is binary!, you would get better efficiency as long as it isn't 
tuple.

I'm all for having an IPv6 type.

And that doesn't even get into the syntax issues: IPv6 syntax is 
really different, not the same as dotted. A different type would 
allow different syntax. But that syntax is really specific, only 
used for that one thing, and not necessarily a very common thing 
at that (do you tend to type out IPv6 addresses, or the domain names 
that refer to them?). It's not like tuples, that get used outside 
of the networking realm. It really might not be bad to just use strings 
for the IPv6 syntax, and binaries for the decoded values. We don't 
have to wait for syntax changes to get started. And once we get something 
running, the syntax changes would be easier to justify :)

yeah the ipv6 addresses really are different.

They are quite a complex data structure, or can be.


Perhaps a first step would be for someone to write a parse rule to 
identify/vaidate IPv6 strings and, optionally, translate them to 
a normative form.


Link to someone who has made  a stab at a BNF defintion for  IPv6, 
and then produced a regex:

   http://crisp.tweakblogs.net/blog/2031/ipv6-validation-%28and-caveats%29.html

funny how all of his problems seem to disapear when we look at it 
with a parse mindset  :-)

PEG beats BNF :)

but even the BNF is something I can use almost directly in parse 
and its easy.   now trying to use that in regexp or a loop/conditionals 
driven function ... yeah... mental.

I stripped all rule tracing from the following. Tests not included 
either, to save space here.

ipv6-parser-ctx: context [
    IPv6address: [
        (=IPv6address: none)
        copy =IPv6address [

                                           6 [h16 ":"] ls32     ; 8

            |                         "::" 5 [h16 ":"] ls32     ; 7

            | opt [h16]               "::" 4 [h16 ":"] ls32     ; 6-7   0-1::6

            | opt [h16 0 1 [":" h16]] "::" 3 [h16 ":"] ls32     ; 5-7   0-2::5

            | opt [h16 0 2 [":" h16]] "::" 2 [h16 ":"] ls32     ; 4-7   0-3::4

            | opt [h16 0 3 [":" h16]] "::"    h16 ":"  ls32     ; 3-7   0-4::3

            | opt [h16 0 4 [":" h16]] "::"             ls32     ; 2-7   0-5::2

            | opt [h16 0 5 [":" h16]] "::"    h16               ; 1-7   0-6::1

            | opt [h16 0 6 [":" h16]] "::"                      ; 0-7   0-7::0
        ]
    ] 
    h16: [
        (=h16: none)

        copy =h16 mark: 1 4 HEXDIG ;(print ['h16 mold =h16  mold mark])
    ] 
    ls32: [
        (=ls32: none)
        copy =ls32 [[h16 ":" h16] | IPv4address]
    ] 
    IPv4address: [
        (=IPv4address: none)

        copy =IPv4address [dec-octet "." dec-octet "." dec-octet "." dec-octet]
    ] 
    charset-1: (charset [#"1" - #"9"]) 
    charset-2: (charset [#"0" - #"4"]) 
    charset-3: (charset [#"0" - #"5"]) 
    dec-octet: [
        copy =dec-octet [
              "25" charset-3               ; 250-255
            | "2"  charset-2 DIGIT         ; 200-249
            | "1"  2 DIGIT                 ; 100-199
            | charset-1 DIGIT              ; 10-99
            | DIGIT                        ; 0-9
        ]
    ]
    DIGIT: charset "0123456789"
    HEXDIG: charset "0123456789ABCDEFabcdef"
    

    set 'parse-ipv6-address func [address [any-string!]] [
        reduce [parse/all address IPv6address  =IPv6address]
    ]
]

It's a mechanical translation of the ABNF, with some rules reordered 
for PARSE.

Is it worth pursuing? If so, what should be next?

Dealing with the formatted addresses is kind-of the last step. The 
first step in looking at the native TCP code and seing what needs 
to be done to support connecting over IPv6. There might be some native 
API changes required.

Could this be used to get R3 running on the JVM? Seems too easy...

http://www.axiomsol.com/

that's interesting.

That must be pretty slow if you use it for a complete interpreter. 
And you would still need some REBOL level binding to use Java classes

I had given the topic some thought, with the Portable.NET C compiler.

At this point, all attempts to *use* R3 have been inspiring the improvements 
of R3. We are better off not separating them for now.

And we have use groups for particular topics, like modules or networking.

We could probably make a !REBOL3 Proposals group, but expect a lot 
of overlap with the other R3 groups :)

Back to REBOL on Java, I expect that the REBOL on .NET bindings would 
be semantically similar. We would be better off if we tried to make 
them as similar as possible in low-level semantics, so more code 
will be portable between Android and WinPhone7, for instance.

yeah there would be overlap....  but it would be the proper place 
to argue about new ideas, changes in the language, naming wars, etc, 
  how *should* it work


the other groups, IMHO, are meant for more "getting things done". 
  how *does* this work?.

wrt REBOL on JAVA...  probably only the host-kit would be an issue.

not sure REBOL on JAVA would be usefull nowadays. JAVA is dead :-) 
REBOL on JS would be interesting though :-)

And even slower

The host kit would be an advantage if we are going the native library 
route. All we would need is to create hosts that asct like Java-like 
or .NET-like native extensions.

Java is not dead on Android (yet). I am very interested in REBOL 
for Java because of this.

yep... I meant that it would be only thing which would really require 
changes to make it work... the rest is just bits and memory allocation, 
which is being run within the loaded app.

Never pronounce something dead, as it will live longer

Kaj: Amiga? :-)

Many things. REBOL, for example

REBOL is much deader than Java, for example

Trying to game the system, Kaj? :)

Just explaining the system...

Petr, Java the language has lost a lot of its shine, though you'd 
be surprised how widespread it still is in lots of companies. The 
thing is that the JVM is still a great platform to target and there 
are languages like Clojure and Scala which compile to this VM and 
their rapidly rising popularity will keep the JVM around for a long 
time to come. Remember, by riding on the JVM you instantly cover 
a whole bunch of platforms at once.

yeah, in most ways, the JVM bytecode specification is outliving both 
JAVA and the JVM itelf.

since the bytecode spec can be translated to other targets too. (androids 
own VM)

I think I know how JAVA is positioned. IT is one of the main corporate 
platforms - JAVA vs .NET. 10 years I was in the JAVA world, now 4 
years I am living in MS world :-) It is just apart from that, I know 
noone who would use it for his/her private project - too complex, 
unnecessary. But - as Max says - there's JAVA, and JVM, and the latter 
is more interesting for us. The question is, how can we integrate? 
Are we about to create some wrapper, which would allow us to utilise 
JAVA classes for e.g., or are we up to "porting" REBOL into JAVA 
entirely?

Pekr, I think you are dreaming like I am.

The idea is really nice. Having REBOL onto JVM or onto .NET using 
DLR would be really a dream.

Also I don't know which complexity is behind this kind of porting. 
Nice to read something about this from the gurus.

I think there are 2 ways : make a Jebol like Jython or make REBOL 
work on a JVM like Groovy or Scala. 

Jebol why not but I think there is no professionnal need behind. 
Because REBOL is very lightweight.

But make REBOL work on JVM  is very interesting because in that way 
REBOL could work on any device that has a JVM.

For the futur of REBOL, make it work on Mobile Phone, Tablet PC and 
WebOS is really important !

Can a couple of people check this bug on non-Windows platforms, please?
   http://www.curecode.org/rebol3/ticket.rsp?id=1753

Same problem on Linux:

>> mold tangent 89.99999999999986 
== "399405529304859.^O"

Looks like a MOLD problem, not a TANGENT problem.

>> type? tangent 89.99999999999986
== decimal!

Right. But it's only a problem when it is displayed or molded (regular 
display calls MOLD).

Yes, this was meant to illustrate that it's very likely some kind 
of MOLD issue.