On Sun, Nov 16, 2008 at 9:29 AM, Eduardo Cavazos <[EMAIL PROTECTED]> wrote:
>Yeah, words that provide literal syntax for library data would have to go in a
> separate library. But that actually sounds good for use with words
> like 'parse-with-vocabs'. It seems desirable to say:
>
> "... FACTOR DATA ..."
> { "syntax.literal" "syntax.literal.library" }
> parse-with-vocabs
>
> and have control over what syntax is available.
If float-arrays defines F{ in syntax.literal.library, then the
following won't work in a new image:
USE: syntax.literal.library F{ 1 2 3 }
> I was actually thinking of categorizing 'syntax' even further:
>
> syntax.defining Defining words like ':' and 'GENERIC:'
> syntax.literal Literal syntax for data
> syntax.parser Stuff that affects 'use' and 'in'
This categorization would only apply to core syntax. Library syntax
never goes in the syntax vocab. For example, the MEMO: word is a
'defining word' however it is not in the syntax vocabulary, it is in
the memoize vocabulary.
> It would be nice to categorize parsing words by various properties. For
> example, I think there's a notion of a "functional parsing word". I.e. a
> parsing word which has no side effects besides pushing onto the 'accum'.
These are exactly the 'safe' words I am proposing. If they simply
parse a literal, you can use it without worrying about undesired side
effects.
> As far as safe code goes, I think defining words isn't so bad, it's changing
> the using list which is dangerous.
Actually, you can change the using list all you want and still get a
safe parser. I'm talking about making a safe 'parse', not a safe
'eval'. The latter is much more difficult.
> I think breaking down 'syntax' into the 'literal', 'defining', and 'parser'
> sub-vocabularies might be a step towards composing those capabilities in
> limited listeners. However, it may not be as simple as that. For example,
> even if you deny access to 'IN:', code might still be able to set 'in'
> using 'set'. (but would it be possible at parse time?) Since 'use' and 'in'
> affect things in such a powerful way, and since they are involved via
> the 'namespaces' subsystem, controlling the ability to change variables
> generally should also to be considered.
A safe parser would not allow IN: or <<, hence you'd never be able to
change 'in' at parse time.
A safe parser would still be able to parse code which is unsafe if
executed; for example,
USE: io.launcher
[ "rm -rf /" run-process ]
involves only safe parsing words.
So safe eval is harder problem and one I'm not interested in having
for Factor 1.0. But safe parsing seems pretty easy if you flag parsing
words as 'safe' and don't actually call the resulting quotation.
Slava
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
