Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Mold, load and Core 2.6

From: holger:rebol at: 7-Mar-2002 10:24

On Thu, Mar 07, 2002 at 06:17:59PM +0100, [nitsch-lists--netcologne--de] wrote:
> haha. change then import-email. or, use it, have some mad spammer and destroy > your archive next time you save. since it "to-emails" whatever this guy thinks could > be a nice broken address. > i think this is generally, one will not check everywhere for proper formatting, > to-email does the job 99,99% of time, then some crazy data destroys all.
We will have a look at that.
> remembering {{} . i expect a fix in a year or so?
> why binding global ? > we get kicked whenever somebody inserts a paren! cleverly.
No. paren!, set-word! etc. are evaluated less aggressively in Core 2.6. Carl mentioned that in his last message. Basically, if the intermediate result of an evaluation (e.g. looking up a word) is a paren!, set-word!, then in Core 2.6 the interpreter no longer continues the evaluation at that point, but rather uses the intermediate value. For instance: Up until now:
>> a: to-paren [1] >> type? a
== integer! In Core 2.6:
>> a: to-paren [1] >> type? a
== paren! Same for set-paths, set-words etc. After loading the data you will still have to check for function! types though (using get-words), if you later want to be able to safely access your block without having to use get-words.
> having load/unbound would be more secure.
That's what to-block does.
> and binding to a restricted set of words in a fresh context, like > [make object! true false none].
That would not help. Words not found in that context would still be bound into the global context. Besides with literals for true/false/none you no longer have to use the corresponding words to represent the values in molded data.
> (to-block hangs sometimes here, and is not exactly the same)
We are not aware of any such bug. Please send details to [feedback--rebol--com].
> all in all sounds great. makes load/mold for serialisation pretty usable. > drawbacks are: > -unparsable data breaks all -> no use of handy parsings like import-email. > at least some check while molding would be nice, > instead of something like [equal? mold data mold load mold data] as today..
> -global binding -> paren! kills security (or use :this :that everywhere..),
No. See above. The only danger are function! types, which are now available as pseudo-literals. Perhaps we will add something like load/safe to prevent that additional work.
> -crazy molded set-words
> -oh yes, and if the newline-tag could be set by programm.. > i don't like having 4K-lines after reduce, unable to fix it in block-form. > having to mold everything by hand and reload isnt the best solution..
Perhaps a mold and save refinement to add word wrapping... -- Holger Kruse [kruse--nordicglobal--com]