r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Maxim
22-Sep-2010
[5019]
A108 now uses  #  to represent none... neat!
Gregg
22-Sep-2010
[5020x2]
Thanks for doing the func-with-init research Ladislav. While I think 
we sometimes focus too much on optimization, I can see this as being 
important in the big picture for writing function generators that 
produce efficient results.
This version is not as cryptic, even though it's longer. I can understand 
it. :-)
Henrik
22-Sep-2010
[5022]
http://www.rebol.com/article/0487.html

Function splitting.
Pekr
22-Sep-2010
[5023]
bleeeah :-) REBOL as a messaging language has networking protocols 
being an optional package = no standard functionality over the REBOL 
installations. Great, what's removed by default next?
Andreas
22-Sep-2010
[5024x6]
Pekr, network protocols are still there and bundled within the binary.
So they still are "standard functionality over the REBOL installations".
It's just that you'll hvae to explicitly import them, if you need 
them.
Let's use DECODE-CGI as a simple example: currently in R2, you fire 
up R2 and can use decode-cgi in your code straight away.
Currently in R3, it's not there at all.
In the future in R3, the code itself will be bundled with R3, but 
if you fire up R3 and type decode-cgi, it won't be available straight 
away. You'll have to explicitly import the CGI functions with import 
'cgi first.
Pekr
22-Sep-2010
[5030]
do you use rebol without networking or db protocols? what for?
Andreas
22-Sep-2010
[5031x2]
Yes. Many different scenarios. I have never used REBOL's ftp protocol, 
for example.
And obviously there are many REBOL scripts which will never need 
the CGI stuff :)
Henrik
22-Sep-2010
[5033]
Pekr, I believe this is not just for distribution purposes, but for 
allowing R3 to start up faster in certain cases, not having to initialize 
various protocols, etc.
Andreas
22-Sep-2010
[5034]
And to reduce clutter in the "global" default namespace.
Gregg
22-Sep-2010
[5035]
The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?
Andreas
22-Sep-2010
[5036x2]
Gregg, same response to you: nothing will be excluded. Just not imported 
by default.
And you can do imports in the header, or on a single line.
Maxim
22-Sep-2010
[5038]
and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.
Andreas
22-Sep-2010
[5039]
IMPORT with a block! as argument does the same as the NEEDS block 
in a header.
Gregg
22-Sep-2010
[5040]
Right, what I don't want is to have to explicitly import "basic functionality" 
in every script. The question is what is basic? And while we can 
certainly do it in a single header line, that's far from the same 
as having it "just work". 


I just want to make sure we're saving enough to make it worthwhile. 
You know how I hate premature optimization. ;-)
Andreas
22-Sep-2010
[5041]
That's precisely the point: what one considers "basic" functionality 
varies widely :)
Maxim
22-Sep-2010
[5042]
I think the point of the public release of this effort is to collect 
what you want (or not) as default.
Andreas
22-Sep-2010
[5043]
And some simple modularisation helps everyone, in the end.
Gregg
22-Sep-2010
[5044]
Right, so where is our list of options and dependencies?
Andreas
22-Sep-2010
[5045]
Heh, _compiling_ that list of options and dependency is part of the 
work in progress, I think :)
Gregg
22-Sep-2010
[5046x2]
So we know if we allow a url! as an arg we're sure to get all the 
protcols that are supported for any url! we might get.
Yes, and that task is important.
Andreas
22-Sep-2010
[5048x2]
I wouldn't say so. Those functions which process urls must ensure 
that the protocols they need are loaded.
(Just as READ, OPEN, etc will have to do internally.)
Gregg
22-Sep-2010
[5050x3]
Not sure I want to think about what those simple, generic, rebol-leveraging 
funcs might look like. Still, I'll keep an open mind. Show me the 
benefit and let me count the cost.
If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.
Sorry, "weigh their value" should be "evaluate their cost".
Andreas
22-Sep-2010
[5053x2]
$ rebol3 --do what | wc -l
480
(-3, because of some useless startup output.)
Maxim
22-Sep-2010
[5055]
so rebol3 is worth 480$ ?   ;-)
Andreas
22-Sep-2010
[5056x4]
+ all schemes (currently only http is bundled with R3), + all functions 
which are not yet bundled in R3 but where available in R2 (cgi, html), 
+ modules which might be worth bundling (database?)
I guess the first step will be to go through these 480 functions 
and group them into some basic modules: possibly core, extra, math, 
debug.
extra == "plus". In a recent CC bug Carl for example mentioned having 
LAST? in core and moving SINGLE? to plus, if it is still wanted.
(And note that all "plus" functions will still be immediately available 
per default.)
Pekr
22-Sep-2010
[5060x2]
I am fully with Gregg here. At least http(s), ftp, smtp, pop, could 
be allowed by default ...
I often use those protocols in console, and I don't want to become 
'import monkey ...
Maxim
22-Sep-2010
[5062x2]
well voice, your needs on the web  ;-)
hum... the comma there makes the sentence a bit weird... ignore it...
Andreas
22-Sep-2010
[5064x2]
Pekr, import [http ftp smtp pop] is tough typing, for sure.
And as I mentioned above, most likely READ will do the import automagically 
for some "blessed" internal modules.
Maxim
22-Sep-2010
[5066]
there will probably be shortcuts like import_plus  import_full.
Andreas
22-Sep-2010
[5067x2]
Maybe a pseudo-module named 'full, then import 'full will do.
And I'm sure there'll be a way to just put the import in user.r/rebol.r 
and be done with it.