World: r4wp

Right, because they print approximate values. If your proposal is 
to change MOLD to generate the smallest value that, while not actually 
being the value in memory, would generate that value in memory as 
a result of the loader trying to approximate what you wrote, then 
I might be OK with that if it can be done efficiently. If it can't 
be done efficiently, I'm OK with doing what all of the other non-scientific 
languages do and just use 15 digits.

That's precisely what Ladislav proposed: "Molding decimal numbers 
'precisely enough'".

R2 says 0.0 and -0.0 are the same, but R3 does not. I replied to 
Lad's googlegroup post that I would prefer "0.0", as evaluating -0.0 
returns 0.0. So, they are equal but not the same under R3. What would 
be a scenario where you would want to maintain the sign?

Evaluating -0.0 yields -0.0. But MOLD is used to format the evaluation 
result, that's what lead you to believe otherwise.

Ahhhh. So, is there every a case where we would want to maintain 
the sign (i.e. because we need the sign itself), or is "-0.0" preferred 
because it is more correct?

Anyone have a suggestion on how we can get trace/net functionality

R2 says 0.0 and -0.0 are the same

 - actually, in R2 it is possible to devise a test which would discern 
 -0.0 and 0.0, although SAME? can't discern them

, which means I can define my IDENTICAL? function so that

    identical? 0.0 -0.0 would yield FALSE

- if you want to see it, read

http://www.rebol.net/wiki/Identity

That clearly demonstrates that Rebol identity doesn't depend on the 
behaviour of the SAME? function as much as it seems...

It is possible to prove that Rebol identity does not depend on the 
SAME? function at all, in fact, and unsetting 'same? I obtain the 
same identity as when the SAME? function is defined.

(which is what the article demonstrates, in fact)

This actually demonstrates that there may be some level of "arbitrariness" 
in the implementation of the SAME? function, but if the SAME? function 
is arbitrary and differs from the IDENTICAL? function then we are 
able to prove that it is arbitrary and it is not the natural identity 
existing in Rebol regardless of the SAME? function.

The problem with writing a prot-send.r is that we have no guidance 
yet on where user variables such as name, email and passwords are 
to be stored.

I'll try to read the latest article soon Ladislav, though my scheule 
is packed right now. Thanks for posting it.

That is not "the latest article", it is quite old, to be honest.

You may have just forgotten you already read it

I remember if from before, but I thought you updated it. By "latest", 
though, I meant the most recently referenced here. I still have to 
finish some others I only read half of. :-)

Graham, put the settings in a structure that is local to the prot-send.r 
module and managed by it. Non-private module contexts are global.

Either that or don't have global settings at all, have the settings 
passed in a structure to the SEND function. Global settings are overrated.

Nonetheless, the plan was to have a user preferences system, with 
preferences persisted to a user-specific data file named user.r, 
in a declarative dialect (specifically no procedural code allowed 
in user.r). Unfortunately, that last sentence is as far as the plan 
got. We were going to have a community discussion about this, but 
hadn't gotten around to it yet because we're still too early in the 
development. Maybe now's a good time to start that discussiion.

non private global context ?

non private module contexts are global ?
so how to define?

I apologize if this kind of thing seems complicated, but a lot of 
the module system happened as side effects of the original design. 
Carl's original module proposal was high-level and not actually implemented, 
so there were some implications that he didn't really know about 
at first. Once we worked through the details, we ended up with a 
more flexible module system than he originally specified (that was 
the first rewrite). Then we changed the interface and usage to make 
it simpler and make the code more maintainable (rewrite two), then 
refined it based on the new model and added many new ways to make 
it even simpler to use, and some new features Carl and others wanted 
(rewrite 3). So I hope that you'll bear with me for a moment.

Regular

 modules have names and versions so they can be loaded only once, 
 and upgraded in place if need be. As a side effect, this makes the 
 module's context effectively global. We have a few built-in global 
 contexts, but we don't necessarily have to make built-in global contexts 
 for stuff that is managed by modules because the module contexts 
 are themselves global.

The exports of regular modules are collected in the lib context (the 
"runtime library") when they are initially imported. All potential 
conflicts between exports of different modules, any overrides that 
need to be done when you upgrade a module or use another module to 
make changes, these are all managed in lib. All modules import stuff 
from lib. You can tell if a module is loaded by checking for it by 
name, and for that matter even the module system itself can only 
tell if a module is imported by checking for it by name.

Private

 modules were a side effect of the module name being optional. If 
 a module doesn't have a name, you can't check for whether it is already 
 loaded, so you have to load it again every time it is requested. 
 The module itself can't even tell if it was loaded before, so it 
 can't know whether it needs to resolve conflicts between itself and 
 other instances of itself. That makes it basically unsafe to have 
 an unnamed module export to lib. So instead, we skip the lib middleman 
 and import those exports directly into the target module or user 
 context, which makes the unnamed module effectively owned by that 
 target, a "private" module.


We found this facility useful enough that we added an explicit option 
to make it private (options: [private]). That makes it possible to 
have a named private module, which has some interesting abilities 
just from having a name. Having a name means that you can have the 
module load only once, and being private means that if you want to 
use its exports you have to import the module explicitly, so combined 
it means an explicitly accessed module that can share resources with 
other targets that also explicitly import the same module.

Overall, "private" modules are really useful if you are writing traditional 
modular systems that require explicit importing to manage complexity. 
This should be familiar to people who have worked with Maxim's slim 
modules, or Gabriele's module system for R2.


The "regular" modules are more useful for writing library code that 
is intended to be used by people writing scripts, as if R3 were not 
a modular system. This should make things easier for people coming 
from R2 or some other non-modular or weak-modular language. Underneath, 
a "script" is another kind of module; it's just the type of module 
that does the best job of pretending that it isn't a module.

one big difference is that slim doesn't bind to a global library 
area.   each module is completely shielded and imports "on its own". 
 

its a hierarchical system without namespaces.

but I'll probably be using modules as the basic construct for slim 
R3, instead of objects... in my model, it might not really matter, 
I manage access/biding to/from modules actually altering and expanding 
the module when it is being loaded.


the data being sent to slim isn't executed directly, the block is 
sent to a manager, which does some binding and security stuff first.

it also adds some extra capabilities to all modules, stuff like vprint/vlogging.

anyhow... Brian and I will eventually get to actually implementing 
the R3 module /  slim model sometime this year.  I don't want to 
start a philosophical debate here.  :-)

I mean, I will implement, based on discussions and tests I'll have 
with Brian, to understand the intricasies of why/how modules are 
as they are now.

Brian, is there a doc that has your above comments in it? http://www.rebol.net/wiki/Module_Design_Details
looks like it covers a lot of ground, but I don't know if you wrote 
it, and whether it has some of the design notes included. I think 
they're very useful and informative.

And it should have links to Slim and other alternatives.

Gregg, I wrote that doc (and forgot the link, thanks), but it needs 
updating. It is about one or two rewrites behind.

Hard to keep up, and keep track, with everything. :-)

Maxim, slim modules are like R3's named private isolated modules. 
And the equivalent of the "global library area" in R2 is system/words, 
so if you have any code that binds to or imports from system/words 
then you have the equivalent of lib.

Btw, module systems like slim are the reason why I changed the underspecified 
parts of Carl's original module system into features that you might 
find familiar. It wasn't based on slim specifically, or even Gabriele's 
system, but an earlier module system that I wrote for the Apache 
module version of R2 back in 1999. It had similar characteristics 
to your module systems because I had come from strong modular languages 
like Oberon and Delphi, and because I had to solve some of the same 
problems you did.

Most of the characteristics of R3's module system are the result 
of combining the system model of R3, the binding model of Rebol, 
and Carl's goal of simplifying things for developers not familiar 
to modular programming. Every bit of syntax that Carl wanted to be 
optional or minimal in order to make things easier for end-developers 
had semantic consequences. The runtime library lib, for instance, 
is the result of having to manage a modular multithreading system 
that can be used by scripts that can be written as if R3 were single-tasking 
and monolithic like R2. Doing that requires that modules have certain 
characteristics (such as a name).

Adding the slim management tools won't change the semantic model 
of R3's modules much, because that semantic model is the result of 
the system model. However, applications designed to be managed by 
slim would likely use a different module type by default than applications 
that are designed around R3's model. Same for porting stuff written 
for Gabriele's module system, you'd be using the same module type 
(named private isolated). That's OK, R3's module system supports 
those models already :)

If R3's system model changes, that *would* affect the semantic model 
of modules. Right now the task! model is a bit underspecified and 
extremely underimplemented, and the module system is built around 
Carl's proposed tasking behavior. If that changes, as it might since 
Carl's proposal isn't fully implemented yet and is incomplete even 
in spec, then we might have to tweak the semantic model of modules 
accordingly.

News for people interested in decimal molding:

>> system/version
== 2.101.0.3.1

>> mold 0.1
== "0.1"

>> mold 0.3
== "0.3"

>> mold 0.30000000000000004
== "0.3"

>> mold/all 0.30000000000000004
== "0.30000000000000004"

>> mold/all 0.3
== "0.3"

>> mold/all 0.1
== "0.1"

>> mold/all 0.10000000000000001
== "0.1"

>> mold/all 0.10000000000000002
== "0.10000000000000002"

>> system/version
== 2.101.0.3.1

>> mold/all 0.10000000000000001
== "0.1"

>> mold/all 0.10000000000000002
== "0.10000000000000002"

>> mold/all 0.3
== "0.3"

>> mold/all 0.30000000000000004
== "0.30000000000000004"

And, BTW, Andreas, regarding the 15 vs 17 digits: I think that we 
can give in easily in this case, just put 

system/options/decimal-digits: 17


to your rebol.r and MOLD decimal will behave exactly like MOLD/ALL 
decimal.

In R2 I have this

>> any-string? read/binary %test-module.r
== true

In R3
>> any-string? read %test-module.r
== false

Yes, Graham, in R3 a binary! is not an any-string!:
>> any-string!
== make typeset! [string! file! email! url! tag!]

Why?

the change?

I'd assume because only Unicode datatypes are considered any-string! 
now.

Ladislav: looks great!