On Thu, Mar 07, 2002 at 06:17:59PM +0100, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
> 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..
Possibly...
> -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
[EMAIL PROTECTED]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
