This is a very quick request for comments on some changes that will be made to get the new LOAD/SAVE code working the way we want in A108. I think most of these are obvious, but if you have some insights, post them.
If you add your comment in the next couple hours we'll check for it prior to A108 release.
Maxim Olivier-Adlhoch
18-Oct-2010 19:12:56 |
MOLD/options [base: 64]
does this mean you will remove the option to save a default manually and we'll be forced to use /options on each call?
or am I mis-understanding something? |
Brian Hawley
18-Oct-2010 19:13:04 |
After examining the code closer, append isn't quite as good a place to put the append-context code. It might be best to just add a /new option to resolve which would cause it to add any missing words to the target, similar to bind/new. That way you can use its /all option as needed to handle overrides.
If you decide to add the append object! object! trick as well, it would be equivalent to resolve/new/all object! object!, and append/part object! object! [words] would be equivalent to resolve/new/all/only object! object! [words]. |
Brian Hawley
18-Oct-2010 19:16:44 |
Maxim, that would be the preferred outcome. The system options that apply to mold have been a big problem for years, as they have to be set globally, but are used as if they are local. They are not recursion or concurrency safe either. We want them to be set at the point of call instead. |
Maxim Olivier-Adlhoch
18-Oct-2010 19:18:18 |
I'm also curious on the APPEND object option
does this mean things like:
append context [b: 77] [a: b]
== make object! [
b: 77
a: 'b
]
could end up being this instead:
append/bind context [b: 77] [a: b]
== make object! [
b: 77
a: 77
]
|
Maxim Olivier-Adlhoch
18-Oct-2010 19:24:11 |
although I understand the idea of mold/option, from a script writer's POV it would still be nice to have a (user context) default.
if a tool explicitly needs a format the mold override is nice (very), but its tedious if every call you will write will require the option in user scripts themselves no?.
|
Brian Hawley
18-Oct-2010 19:33:57 |
Maxim, no it means that that things like:
>> append context [b: 77] [a: b]
== make object! [
b: 77
a: 'b
]
Could be written as:
>> append context [b: 77] context [a: 'b]
== make object! [
b: 77
a: 'b
]
Or like this:
>> append/part context [b: 77] context [a: 'b c: 'd] [b]
== make object! [
b: 77
a: 'b
] |
Brian Hawley
18-Oct-2010 19:54:31 |
As for the mold defaults, the ideal solution would be for them to be hard-coded and unchangeable. If the default is at all changeable, that puts us back in the situation of having to save and restore the default (not recursion or concurrency safe), of of having the behavior of mold be unpredictable without checking to see if the default has changed. Getting rid of system/options/binary-base or making it read-only for documentation purposes would be the best solution to avoid all of that checking code. |
Carl Sassenrath
18-Oct-2010 20:39:39 |
There's more than one thing I want to achieve with APPEND of object... but not had time yet to formulate all of it.
On MOLD... perhaps system option could remain... I understand your point. But, can be problematic.
|
Henrik
18-Oct-2010 23:50:58 |
Is ENCLOAK an option that could be added? |
Gregg Irwin
19-Oct-2010 1:57:42 |
It's hard to provide useful comments on topics like this when one isn't familiar with the context or related R3 internals. And the short time limit doesn't help either.
Not trying to be negative, just meta-commenting about why you might not get much feedback on this. |
Christian Ensel
19-Oct-2010 2:10:35 |
I'm all for the change to making the binary base an argument to MOLD, but I'd like to see a /BASE refinement as in
>> mold/options value [base: 64]
>> mold/base value 64
to shorten code when you don't need to refine MOLD much. Checking for a /BASE refinement wouldn't be too expensive compared to checking for an /OPTIONS refinement along with having to parse the block supplied, I hope. |
DideC
19-Oct-2010 5:49:16 |
+1 for Christian suggestion.
Or maybe there are other options pending that we don't know of ! |
Oldes
19-Oct-2010 10:06:17 |
When you will be modifying CHECKSUM and DECOMPRESS functions, wouldn't it be possible to add native GZIP support?
It would be really nice to be able use GZiped scripts and data and it would be also useful for HTTP and other protocols as a common transfer option.
thanks. |
Brian Hawley
19-Oct-2010 15:54:59 |
The options block is a convention that is being added in a lot of places in R3. It is more easily expandable than the list of refinements of a function, because of stack frame overhead and the consequences of the use of apply. With one /options refinement the number of elements on the stack frame is fixed, with no overhead for options not taken, and all the actual refinements in the same place in the spec. This is especially important for actions like mold, where options might be type-specific and every change to the refinements list has to be redone for every type. If there may be more options in the future, existing code will still work.
Script headers now have an options block too, though it is a simple block of words that act like flags. Some of the previous module-related optional header fields have been changed to words in the options block; isolate for instance. |
Brian Hawley
19-Oct-2010 16:12:50 |
Oldes, compress and decompress will get /gzip options. See the change log. |
Brian Hawley
19-Oct-2010 16:35:10 |
Carl, the problems with the system option could be solved if you protect it. That way it could be customized by host kit users and at lower --boot levels, but still relied on by regular script writers. Otherwise script writers would need to use the mold base option every time, not just when they want to use something other than the default. |
You can post a comment here. Keep it on-topic.
