AltME groups: search

You deviate from a contract, you deviate from social rules, the right 
path, etc.

On a good day :)

equal? a b

diverge? a b

I missed a lot of this conversation, but saw some mention of NAN 
and INF.  Exceptions by default seem like the natural choice.  Anything 
different could be done with refinements.  divide/symbolic 1 0 ... 
or something?

Problem with `diverge?` is that the proposed function will not return 
a boolean, unlike equal?.

A small gotcha for people who want to write scripts that run under 
both R2 and R3.

I'm still not sure this specific stub should be removed.  it will 
invalidate *many* R2 scripts and its not such a big thing to leave... 
as long as it prints out a warning.

it could actually be part of a "compatibility" mode switch.... something 
like a delayed module which only need to import when running r2 code.

That is a better plan than leaving these anachronisms in R3 by default 
:)

but we need to make sure we collect them all (I gather you've been 
a pack rat about this ;-)>

I expect that with the R2/Forward additions to R2 there might be 
a useful middle ground.

(a classic case of.... if you can't convince them... use the stuff 
they put all those hours on... its probably better than yours  ;-)

Just added this note to #1722: "Note: This ticket is not a dup of 
#1177. We made the same error again with a new module system. We 
have a better solution this time though."

And it was a two-word fix :)

since you are telling it none, its not a security hole you chose 
to ignore the name.

That won't work for IMPORT, but might work for sys/load-module with 
a little care. Not sure about that one though.

Import doesn't have a rename feature on purpose, as a simplification. 
IMPORT is supposed to be user-level automagic stuff. The real work 
is done by LOAD-MODULE.

For one thing, renaming something already imported is an error. And 
a lot of the time IMPORT is just giving you access to stuff you already 
imported earlier with Needs.

If you want the reloading, use DO. DO works on scripts and modules 
both, and does them every time. It even tries to import the module 
after it is created. This is everything that you were requesting 
out of reloads. What it won't do is override a loaded module in the 
module list that is the same version or newer, but you can import 
those directly using IMPORT options.

What /no-lib does is converts a module to a private module. It does 
a full import directly into the user context instead of importing 
through lib. It doesn't even go into the system modules list as a 
reusable prebuilt module, which named private modules otherwise do.

Fork.... earlier discussion of INF is here:

   http://www.rebol.org/aga-display-posts.r?offset=0&post=r3wp771x5711

As Brian says, best place for any proposals for Carl to consider 
is here:
    http://www.curecode.org/rebol3/ticket.rsp?id=1717&cursor=1


The range of possible approaches extend from INF always throws an 
error to INF is a first class value. Somwhere in the middle is INF 
acting like UNSET! -- something you can use, but must be handled 
with great care.

...approaches extend from INF always throws an error to INF is a 
first class value. Somwhere in the middle is INF acting like UNSET!...

 - I do not think this describes the situation. I see it differently, 
 thinking, that there are only two consistent alternatives (the current 
 state is inconsistent, as everybody agrees with):


1) inifinities are not REBOL values (this state existed before FP 
pairs were introduced). I am pretty sure, that the description "INF 
always throws an error" is misleading, exactly because such a value 
does not even exist in REBOL


2) infinities exist in REBOL. In this case, they have to be "first 
class values", but, of course, they are not handleable by all functions, 
since e.g. +INF + -INF is not defined

supporting infinity opens up a can of worms IMHO.  if one really 
needs to do heavy math stuff, its probably better to use C and professional 
math libraries via an extension.

I almost agree with Maxim here. I think there should be a clear definition 
of REBOL 3 math *can* and *cannot* do. Leave the complex numbers, 
symbolic math and infinity to modules and extensions.

Cyphre - I re-tested with all possible special czech alphabet chars, 
and even with default font in console, it worked OK. Or was I just 
lucky, and your note was more general, e.g. that such a font can't 
support all possible chars in different than czech language?

if, however, the binary is compiled as console app, a console will 
_always_ pop up (if if only for a very short blink).

so when you start view.exe by dropping a script which displays a 
rebol gui on it, you'll have a short blink of a win32 console before 
the rebol stuff launches. which is probably undesirable.

This guy is somehow reusing dos console in GUI app, but maybe it 
is a different matter - it seems he is just redirecting the console 
to give it a GUI look? 
http://www.codeproject.com/KB/threads/consolepipe.aspx

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

Unnamed modules (that stay unnamed) don't get listed in the module 
list. Instead, they get converted to private modules and get imported 
directly into the target context (system/contexts/user, or the context 
of the module that is requesting the import with its Needs header). 
Unlike regular private modules, if you import them again they aren't 
reused - you get a fresh module every time. This can be a useful 
property at times, so we kept it. We have done a great deal to make 
unnamed modules useful, and as a side effect even preferred in some 
cases.

Now Modules are here. A central repository is going to be created. 
Then GUI will be completed.

A question: what's next for REBOL ? Datatypes ? Will we go out of 
alpha then ?

There is still a lot of work haead. It will take 1 and half year...

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.

Finally implemented http://curecode.org/rebol3/ticket.rsp?id=637
thanks to a bugfix in alpha 108.

My dreamed feature is to have a release, instead of a not-for-distribution 
- which effectively doesn't exist

The question is what a script writer should do.

The example script you gave is valid: for what you've written, I 
consider there to be a bug.

I need a reliable way to QUIT with a return value from a script. 
But I do not know how this script is called.

A friend of mine is asking about support for IPV6 addresses in REBOL 
3. he figured that REBOL 3 would have to support 128-bit numbers. 
I told him that there might be a separate datatype for it, but would 
it possible or would there a different way?

Andreas, coincidentally, he owns and actively uses a VAX :-)

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots? I don't know that it's a great idea to map 
IPv6 addresses to them, or the feasibility of adding an ipv6! type. 
A utype! may be good enough, but I don't know how those are going 
to work either.

If we go all out for IPv6 integration then we can do a utype or even 
a built-in type with syntax (utypes won't have literal syntax). But 
we don't need to do that to get IPv6 support; we can get that now 
using the existing datatypes and some functions to work on the data, 
in theory.

No, I meant utypes. That utype! datatype is short for user-defined 
datatypes, a planned feature (for R3.1). But literal syntax for utypes 
is *not* planned.

Yes, utypes are a bit vaporware right now. But we've given the concept 
a great deal of thought, and their constraints are known already.

Sure, but you sound like a good culprit :-)

just a joke Brian

Btw, as of alpha 108, bug#885 has upgraded itself to a potential 
crash bug, though it is partially fixed in other ways. See here for 
details: http://www.curecode.org/rebol3/ticket.rsp?id=885

I'll add a ticket for the FIND-ALL bug (it's minor and only affects 
erroneous code).

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots?
 - yes

Is the safe R3 way to execute a script to use:
   do load %script-name
rather than R2's way:
   do %script-name
?


The reason I ask is the different behaviours I see here (I'd expect 
them both to print a 1)....
    n: 1 try [do %test-script.r ] print n
    n: 1 try [do load %test-script.r ] print n

....where test-script.r is these two lines:
    rebol []
    0 / 0

If you need a 16 slot tuple, you're using the wrong datatype.

Sunanda, yes... a bug we know about.

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.

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 :)

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  :-)

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.

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

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

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

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.

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.

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

Looks like a MOLD problem, not a TANGENT problem.

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

I have a question.

Somwhere, between Rebol Wiki and BLOG appeared an article about OBJECT 
creation and what is copied and what is shared.
Do you remember the exact position ?

Excuses

 is the total wrong word and interpretation. We had this topic over-and-over 
 again: A lot say "Rebol is bad because it's not open-source.", well 
 I want to ask: "How many of you have contributed to the parts that 
 you can work on now?"

My list of what needs to be fixed/done before we can consider beta, 
in CureCure tickets: #539 (likely as definitional return), #851, 
#1509, #1515, #1518, #1519, #1520, #1742, #1743, maybe #1744, #1758, 
#1759. Plus all the PROTECT bugs. There isn't a single one of those 
that isn't more important than tasking or a new codec model.

And #1521 (which is a side-effect of #1509 getting fixed).

This one is a poll question everyone should not have trouble to answer. 
In R2, the USE function initialized the local values to #[unset!] 
for better user protection. In R3 (implementation quirk) the local 
USE variables are initialized to #[none!]. Which alternative do you 
prefer?

I think it should be the same, as if you were to use those values 
local to a function. Aren't they set to #[none] there too?

I sometimes have a tendency to write code like:

use [blah] [...body...]

and later move that code to:

func [/local blah] [...body...]

and it would be nice not to have to change the body.

thanks, leaving the score as is, but making a note for myself

Which means, that a variable being intitialized to #[unset!] behaves 
like being "uninitialized"

I have a slight preference for unset!, but the consistency argument 
overpowers it.

Which means, if I understood you well, that your favourite behaviour 
is:

    use [a] [type? get/any 'a] ; == unset!

as well as

    do has [a] [type? get/any 'a] ; == unset!

, the current behaviour

    use [a] [type? get/any 'a] ; == none!

and

    do has [a] [type? get/any 'a] ; == none!

being the second best only?

and

type?

... Yes... but, if on a scale of 0 to 100, where 0 is unset! is my 
exclusive favourite and 100 is none! is my exclusive favourite, then 
my preference is about 49, with an uncertainty of ±10.
So I don't think my vote should count for much. :)

+1 for R3's USE. Uninitialized variables aren't really as much of 
a problem when:
- They are declared right there where you can see them.

- They are initialized to a known value that you can rely on or test 
for.

Is this simply a variant of known existing issues; and, if so, is 
it what R3 intends?

    if all [return none][print "I was printed"]
        R3: ==I was printed
        R2: == ** Throw Error: Return or exit not in function

Ditto with BREAK, EXIT

Crap, that affects IF too? I'll write up a ticket.

Ah, there will _always_ be a top 12.

Just a joke, because the talk here is awfully mathematic, while REBOL 
is based more on English

On the other hand, I am not sure, whether it is a good idea to allow 
empty VARS block in LET - that looks like a user error to me.

Empty vars or values blocks, like all of the other assignment-related 
characteristics of LET, serves the same purpose that they do in SET. 
Remember, a lot of the time LET will be used on data, not just inline 
words and values. Sometimes you want to screen for #[unset!], because 
being screened for is the whole point to that datatype, so setting 
it should be an option like it is with SET. Other times the words 
will be collected from the body, such as with COLLECT-WORDS/set. 
It is not necessarily an error if there are no words - it depends 
on the programmer's intention.

Doing a block with set-words set to a local context and initialized 
to none: let collect-words/set block none block. Still correct if 
there are no set-words.

My note to the "rehashed #[unset!] argument": I like the "The whole 
point of #[unset!] is to trigger errors" formulation. Nevertheless, 
it is broken in a big way by USE and function contexts. Only any-object 
contexts adhere to this convention now, so it is an error to write.:

context [
    print a
    a: 1
]

, while a corresponding

use [a] [
    print a
    a: 1
]

would be an error in R2, but not in R3 anymore, while

do has [a] [
    print a
    a: 1
]

was not an error even in R2.


Therefore,  "The whole point of #[unset!] is to trigger errors" is 
true, but, as demonstrated, the #[unset!] value is sneakingly losing 
its point to the extent, that it is becoming negligible. BTW, this 
is one more "arms race", which a protection measure is losing when 
confronted with the freedom of a programmer to write code he likes 
to write. The previous victim of this race in the datatype space 
seems to be the #[none!] value (at least to me).


I do not object, since due to the changes the #[unset!] value is 
becoming more of an annoyance, than a useful bug protection. And, 
there are other benefits, like increased compatibility between USE 
and functions, exactly as the discussion revealed, as well as the 
fact, that the protection was never as useful as it was planned to 
be.

I suppose you would consider the unbound variable errors to be the 
next round of the arms race though. It is getting to be a tiresome 
metaphor :(

Maybe I surprise you, but not. The reason why is, the unbound variables 
are not a "new datatype to enforce something", they are an existing 
datatype used for a reasonable purpose, and not starting a new round 
of "war" introducing some GET/WHATEVER.

But, being at it, there is one annoyance I perceive:


1) the variables bound to a function context don't cease to exist 
even when the function is not running
2) code like:
    f: func [/a]['a]
    block: [a]
    bind block f

do not work, while I can do such a bind on my own without needing 
any permission:
    change block f
So, this is clearly just an annoyance, and not a useful feature.

+1 for consistency, as long as functions keep their implicit initialization 
to none.  


to me this is a feature, one which I have relied on in all my REBOLing.

About the annoyance, that is a side effect of two things combined:

- Starting with R2 we got direct binding, rather than dynamic binding, 
for a 30X speedup IIRC.

- Starting with R3 we got stack-relative contexts for functions, 
for security, task safety and better recursion safety.


You can't have the words in functions lose their bindings once the 
function returns because they will need those bindings the next time 
the function is called, and you can't rebind because definitional 
binding depends on the order of binding operations. So instead the 
context becomes invalid. It's an annoyance, sure, but it is more 
of an understandable side effect of some *extremely* useful features.

Is it critical that they get syntax? It looks really ambiguous with 
tuple syntax. It looks like a user-defined datatype would help here, 
as they can do math with the actions but won't get syntax.

Be loaded in literal form by LOAD. That is the only advantage of 
a datatype! over a utype!.

The same could be done with IPv6 addresses. But both of those could 
have all of their support functions implemented in a module with 
regular functions and commands in it and you would have the same 
functionality now, before utypes start working.

Here's a possible example of use.  Carl could be assigned an oid, 
and then he could sub assign an oid from his root to Andreas.  Andreas 
can now uniquely identify each of his builds with an oid as can Carl 
with no overlap.  We can tell from the tree where they lie.

So, sounds like a good idea for a community utility module :)