[REBOL] interesting article - Why compilers are doomed

[chaz]

By Jean-Claude Wippler, creator of MetaKit, "an efficient embedded database
library with a small footprint"

http://www.equi4.com/jcw/wiki.cgi/56.html

[REBOL] A small security hole REBOL, and a huge one!

[brian . hawley]

I hate to be the bearer of bad tidings...

First, the small security hole:

I just found out that second returns the original
code block when applied to a function value. This
code block can then be changed, which changes the
function without recreating it and reassigning it.
This kind of change is invisible to the query and
protect functions. This means that a script can
add code to any of the mezzanine functions without
you being able to tell. I don't know any easy way
to protect the REBOL interpreter session from this
kind of attack.

I know that you should read untrusted code before
you execute it on your system, but the WWReb is
based on executing distributed code. The first and
second functions were changed before to return a
copy of the blocks when applied to object values.
Is there some reason that second and third applied
to function values returns the original? Memory
efficiency, perhaps? Avoidance of deep-copying
possibly cyclic structures?

Can we count on this behavior in the future, or is
it subject to change? It enables self-modifying
code, for example. If we could count on this trick
it would make things more interesting for advanced
REBOL programmers.

I don't see how adding modules will change this in
any way. I don't see how you could prohibit changes
in the inner blocks and parens referenced by the
code without too much overhead.

I guess the best way to secure REBOL is to use the
launch function and run the script in a separate,
secure interpreter environment. This brings me to
my next discovery though...

The big security hole: The new launch native!

Right now, the launch native launches a new REBOL
process with the command line arguments you pass
as a parameter. Command line arguments just like
those accepted on the command line of REBOL. This
command line can include REBOL options, including
"--nowindow --quiet --secure none", with no kind
of security warning!

Launch should be rewritten so that the command
line options normally accepted by REBOL are passed
as refinements to the launch native. The /secure
refinement then needs to have the same restrictions
that the secure native would have if called at the
same point in the code. Any command line options in
the argument any-string! should be ignored by the
new REBOL process.

This hole is such a major issue that I have Bcc'd
this message to Feedback. Fortunately the launch
native is only implemented in the experimental
releases. Until this is fixed, don't ever run any
untrusted code with an experimental REBOL if it
has a working launch native (only /View so far)!

Don't kill the messenger, please! :(

Brian Hawley

[REBOL] context of a function Re:(2)

[brian . hawley]

I wrote:
>During the REBOL 2 development process REBOL was changed to
>specifically prohibit that kind of access. This was done to
>keep the interpreter from crashing. It's a bad idea to do
>this kind of thing, as it leads to completely unstable code.

[EMAIL PROTECTED] wrote:
> >> f: func [a] [a]
> >> aa: first second :f
>== a
> >> clear second :f
>== []
> >> append second :f 'print
>== [print]
> >> append second :f aa
>== [print a]
> >> source f
>f: func [a][print a]
> >> f 3
>3

Well Galt, that shows me :)

Looking back, I must have remembered the change to the behavior
of first and second as applied to object! values. Before, you
could get at the actual word and value blocks of the objects by
using those functions, and changing those blocks crashed REBOL.
Those functions were changed to return copies of the blocks so
the crashes wouldn't happen.

For some reason, I assumed that first, second and third were
changed similarly for function! values, for the same reasons.
After testing, it appears that only the first function returns
a copy of the argument block, keeping you from being able to
modify the number of arguments the function actually takes.
This leads me to believe it likely that object! and function!
contexts are implemented with the same data structure inside
REBOL, and that the first function as applied to functions is
passed on to the internal object context.

What does interest me is that the second and third functions
applied to function values return the _actual_ code and spec
blocks of the function!

This allows you to all sorts of evil tricks, such as self-
modifying code, functions that take a different number of
parameters than the help says they do, etc. Evil stuff. :)

On the more practical side, you could use the parse function
of the code and spec blocks to patch function code and help
bugs in place. Otherwise you would have to worry about loose
references to the old version of the function, possibly making
the system unstable.

Being able to modify the original code block of a function
without reassigning the function word is a security hole
though, as I'll explain in my next message.

Brian Hawley

[REBOL] error when processing multiple web pages!!

[akhar]

I am currently rying to do my own version of a web crawler it gets the list
of sites to crawl from a separate text file and attenmps to visit them but
after a few sites I get th following error and it quits to the console and
even there afterwards I can open up any other web site:

cannot find it
connecting to: www.multimania.com
connecting to: www.multimania.com
** Access Error: Cannot connect to www.multimania.com.
** Where: as: read join http:// [url]
>>

does rebol have a buffer?? here is my code

REBOL [
Title:   "e-mail finder"
Date:13-May-2000
Author:  "Stephane Jolicoeur"
File:%octo.r
Email:   [EMAIL PROTECTED]
Purpose: {
To find urls within a file!!!
}
Comments: {
do not use for SPAM
}
]
urls: make block!
text: make string! 0
html-code: [
 thru "http://" copy url to newline (append urls url) |
 copy txt to "http:" (append text txt)
]
page: read %urls.txt
parse page [to "http://" some html-code]
foreach url urls

 if exists? join http:// [url] [
  as: read join http:// [url]
   ;print url
   if find as "@" [
print ["@" "fut trouver sur" url]
newline
print " "
   ] print "cannot find it"
  clear as
  ][print ["je ne peux acceder ce site:" url]]
];
as: ask "done??"

thanks for any help
Akhar

[REBOL] problems with local vars??? Re:(7)

[bhandley]

> second :f is different. It returns a "live" block of code (the body) with
> the contained words bound to the local frame of the function f.  This
block
> of code can be modified with and extended (with append etc. using 'bind if
> necessary) after the function is created.

> It seems clear that the
> interpreter executes the function by 'do-ing this body block.

The original reason I originally questioned the relationship between
functions and dialects in this thread was due to this "'do-ing the body
block" concept.  To make the question specific define a function f like
this:

>> f: func[/local x][x: {} append x "a" print x]

My question then is, how are the first two values (x: {}) of the body block
treated when the interpreter executes the function? In terms of purely
executing the block, logically it seems, the first two values could be
considered redundant, correct?

A related issue (maybe), I don't know if it is been asked before.

If I now use f, I get:

>> f
a
>> f
aa

Compare this with another function g and its results:

>> g: func[/local x][x: 0 x: add x 1 print x]
>> g
1
>> g
1

Are these results related to the execution of a function or the
interpretation of datatypes?
Any enlightenment please?

Brett.

[REBOL] context of a function Re:(2)

[ptretter]

Your killin me.  Just when I started to think I was getting this stuff down.
:)
I need a beer and then I will get to thinking about this one.  Time for
REBtris.


Paul Tretter


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 18, 2000 8:55 PM
To: [EMAIL PROTECTED]
Subject: [REBOL] context of a function Re:


Frank Sievert ([EMAIL PROTECTED]) wrote:
>Is there a way to get the words of the context of a function?

Not directly.

>Example:
>f: func [a] []
>g: func [a] [print a]
>
>Does anyone know a way to change function f AFTER its definition
>in that way, that it will work like function g?

f: :g

>The following does not work:
>   insert second :f reduce ['print first first :f]
>
>Because the first (and third) of a function is not bound to
>the functions context.
>
>I think there is no direct way to get the word with binding,
>I could only get the words out of functions body :(

During the REBOL 2 development process REBOL was changed to
specifically prohibit that kind of access. This was done to
keep the interpreter from crashing. It's a bad idea to do
this kind of thing, as it leads to completely unstable code.

>I am working at a serialize script, which also serializes
>contexts etc.

The contexts of functions are not properly persistent. While
REBOL does save a context for each function, it only does so
for the purpose of reuse. The values of the words in that
context are trounced with every call to the function.

If you want to write solid code in REBOL, you should pretend
that the function contexts are completely volatile between
calls, even if the current implementation makes this not so
on some occasions. The only persistent contexts you need to
concern yourself with are object contexts. If you serialize
any more contexts than that, people who use your code might
try to depend on persistence of contexts between sessions
that aren't even persistent within the same session.

If you want to use persistent values within the context of
a function (like static variables in C), use the technique
of embedding series or object values in the code block of
the function.

Do you remember the recurring discussions that begin with
someone new to REBOL getting tripped up because they did
   a: []
in function code, expecting it to behave like
   a: copy []
instead? Someone always calls this a bug in the language
design, but used properly it can be one of REBOL's most
powerful features.

For example, try this:

 f: func [x /local a] [
 a: [] append/only a x foreach x a [print x]
 ]

This code depends on the block embedded in the function
being modified by the function, and having those changes
be persistent. All you would need to save here would be
the spec and code blocks of the function to be saved -
it doesn't depend on the context being persistent, which
is good because function contexts effectively aren't.

This same technique can be used with values that aren't
directly representable as literals, such as hashes, lists,
bitsets, functions and objects, if you create the function
code block with some function like compose.

For example, in this function:

 alphanum?: func [s /local alphanum] compose [
 alphanum: (
 charset [#"a" - #"z" #"A" - #"Z" #"0" - #"9"]
 ) parse/all s [some alphanum]
 ]

..., the function charset is only called once, before the
function alphanum? is created. The local variable alphanum
is assigned to the now literal bitset value embedded in the
code of the function, rather than being recreated every time
the function is called, an expensive process.

You can use this technique to speed up functions that parse
using local character sets, to index using local hashes, to
create local functions without having to recreate them at
each call - basically anywhere you need to hide persistent
values from uncontrolled modification. If you are used to
programming in the functional style, with closures, this is
how to have persistent data.

Of course, none of this will be needed when Carl gets done
with REBOL modules. When that happens you will be able to
use modules for all of your information-control needs and
you won't need to do these more arcane closure-type hacks.

Brian Hawley

[REBOL] context of a function Re:

[brian . hawley]

Frank Sievert ([EMAIL PROTECTED]) wrote:
>Is there a way to get the words of the context of a function?

Not directly.

>Example:
>f: func [a] []
>g: func [a] [print a]
>
>Does anyone know a way to change function f AFTER its definition
>in that way, that it will work like function g?

f: :g

>The following does not work:
>   insert second :f reduce ['print first first :f]
>
>Because the first (and third) of a function is not bound to
>the functions context.
>
>I think there is no direct way to get the word with binding,
>I could only get the words out of functions body :(

During the REBOL 2 development process REBOL was changed to
specifically prohibit that kind of access. This was done to
keep the interpreter from crashing. It's a bad idea to do
this kind of thing, as it leads to completely unstable code.

>I am working at a serialize script, which also serializes
>contexts etc.

The contexts of functions are not properly persistent. While
REBOL does save a context for each function, it only does so
for the purpose of reuse. The values of the words in that
context are trounced with every call to the function.

If you want to write solid code in REBOL, you should pretend
that the function contexts are completely volatile between
calls, even if the current implementation makes this not so
on some occasions. The only persistent contexts you need to
concern yourself with are object contexts. If you serialize
any more contexts than that, people who use your code might
try to depend on persistence of contexts between sessions
that aren't even persistent within the same session.

If you want to use persistent values within the context of
a function (like static variables in C), use the technique
of embedding series or object values in the code block of
the function.

Do you remember the recurring discussions that begin with
someone new to REBOL getting tripped up because they did
   a: []
in function code, expecting it to behave like
   a: copy []
instead? Someone always calls this a bug in the language
design, but used properly it can be one of REBOL's most
powerful features.

For example, try this:

 f: func [x /local a] [
 a: [] append/only a x foreach x a [print x]
 ]

This code depends on the block embedded in the function
being modified by the function, and having those changes
be persistent. All you would need to save here would be
the spec and code blocks of the function to be saved -
it doesn't depend on the context being persistent, which
is good because function contexts effectively aren't.

This same technique can be used with values that aren't
directly representable as literals, such as hashes, lists,
bitsets, functions and objects, if you create the function
code block with some function like compose.

For example, in this function:

 alphanum?: func [s /local alphanum] compose [
 alphanum: (
 charset [#"a" - #"z" #"A" - #"Z" #"0" - #"9"]
 ) parse/all s [some alphanum]
 ]

..., the function charset is only called once, before the
function alphanum? is created. The local variable alphanum
is assigned to the now literal bitset value embedded in the
code of the function, rather than being recreated every time
the function is called, an expensive process.

You can use this technique to speed up functions that parse
using local character sets, to index using local hashes, to
create local functions without having to recreate them at
each call - basically anywhere you need to hide persistent
values from uncontrolled modification. If you are used to
programming in the functional style, with closures, this is
how to have persistent data.

Of course, none of this will be needed when Carl gets done
with REBOL modules. When that happens you will be able to
use modules for all of your information-control needs and
you won't need to do these more arcane closure-type hacks.

Brian Hawley

[REBOL] problems with local vars??? Re:(6)

[larry]

Hi Galt

You raise some interesting questions. I don't have time right now to go into
much detail on this, so just a couple of quick comments.

> p.s. although Rebol may be "interpreted",
> the body and params and etc. have been fully
> "load"-ed and that means they are like typed
> tokens and bound words that are ready to roll.

make function! which can be used directly and is called by 'func and
'function takes two block args: spec and body.  The spec block contains a
spec which is a REBOL dialect.  It is parsed (internally) with the spec
dialect rules to determine the meaning. make function! creates a local
enviroment or frame with bindings for the local words. The local words
include each arg, each refinement (as a word!), each refinement arg, as well
as each local specified with /local.  These are all bound locally and have
the value unset!.

When the function is executed, the interpreter evaluates the refinements to
true or false, and evaluates the args and refinement args and binds the
local words in the local frame to those values or, as appropriate to none.
The interpreter then simply evaluates 'do body-block.

third :f gives the original spec and first :f gives the word list including
/local to separate those values specified with local.  In both cases, the
words in the returned block are not bound to the local context of the
function. These are "dead" blocks, the original versions in the function
cannot be modified by appending something to the "dead" blocks. In other
words, the spec cannot be modified after the function is created, it is used
during the function creation process (i.e. by make). After creation, these
blocks provide reflective info about the function. Of course, they *can* be
used to create a new function with the same spec or with a modification of
the spec.

second :f is different. It returns a "live" block of code (the body) with
the contained words bound to the local frame of the function f.  This block
of code can be modified with and extended (with append etc. using 'bind if
necessary) after the function is created.  It seems clear that the
interpreter executes the function by 'do-ing this body block.

> It's not like a lot of simple interpreters which are converting
> straight from source as just a string of characters
> for each and every line.

Well, it is not a string, it is a block defined within a context.

> when the function definition is executed
> that baby creates the function! value and
> assigns it to the function's name word,
> and that value sure isnt just a string! of code.

As above, I think the body is a block of code with words bound in a private
frame, which *is* actually evaluated by the interpreter each time the
function is called. Of course, the arg values are bound to the local words
first. Recursion requires more explanation.  See some of the recent posts on
contexts by Ladislav.

> so that makes sense and the interpreter can run
> pretty fast.  I am sure that it is the same
> with Logo, Lisp, Scheme, etc...  I think the
> series type is also something that helps make
> Rebol fast.  I don't recall seeing its like
> in those other cousins of Rebol.

REBOL blocks and more generally series combine the access and modification
features of Scheme lists (head, tail, next, first) and Scheme vectors (pick,
poke, at).

Most of the above is just my current best guess about how function creation
works.

Cheers
-Larry

snip

[REBOL] A very basic question, I hope...

[carl]

How do you start a second View script running (meaning from within a
View script) without the first one closing its window/s and ending? 
I've spent a long time looking for info or an example on this and
failing to find anything...

Carl Read.

[REBOL] problems with local vars??? Re:(6)

[Al . Bri]

Galt wrote:
> why do you say that rebol functions are a kind of rebol dialect?

Because they are a kind of rebol dialect. They are blocks with special
meaning.

> I thought they were more of a built-in type function! There are some
special things that happen in a function that are all about binding params
and locals, but I would be surprised if functions worked internally like the
dialect that is in parse or view. If it works that way, it's a sheer
revelation to me. In fact, how could you define a dialect without referring
to other functions? Is that a chicken and egg kind of thing?

>> first :MyFunc
== [Arg]
>> second :MyFunc
== [print Arg]
>> third :MyFunc
== [Arg [string!]]

The:
make function!
that appears in the source for 'func and 'function is where any dialect
pre-processing occurs, and MyFunc is where the function dialect gets
executed. This is where the "magic" happens. 'Func, 'function and 'does are
simply built on top of these.

I hope that helps!

Andrew Martin
ICQ: 26227169
http://members.xoom.com/AndrewMartin/
-><-

[REBOL] FAQ: When is View B5?

[carl]

FAQ: When is View Beta 5?

ANS: To be determined.  However, you can download experimental versions of View at any 
time to get a better idea for its features and start using them.

Note: experimental releases are not fully tested.

-Carl

[REBOL] problems with local vars??? Re:(6)

[Al . Bri]

Brett wrote:
> Rebol functions are a dialect which is interpreted...

Yes. Rebol functions are merely words and blocks. For example:
[
Rebol[]

ArgBlock: [Arg]
BodyBlock: [print Arg]

append/only ArgBlock [string!]

MyFunc: func ArgBlock BodyBlock

MyFunc "This is my Arg."
]

See that 'ArgBlock and 'BodyBlock are just Rebol blocks. Look at the
reflection:

>> source MyFunc
MyFunc: func [Arg [string!]][print Arg]

It really is as simple as that.

I hope that helps.

Andrew Martin
See Rebol, do Rebol, know Rebol...
ICQ: 26227169
http://members.xoom.com/AndrewMartin/
-><-

[REBOL] context of a function Re:

[galtbarber]

>> f: func [a] [a]
>> aa: first second :f
== a
>> clear second :f
== []
>> append second :f 'print
== [print]
>> append second :f aa
== [print a]
>> source f
f: func [a][print a]
>> f 3
3

-Galt

>= Original Message From [EMAIL PROTECTED] =
>Hi!
>
>Is there a way to get the words of the context of a function?
>
>Example:
>   f: func [a] []
>   g: func [a] [print a]
>
>Does anyone know a way to change function f AFTER its definition in that
>way, that it will work like function g?
>
>The following does not work:
>  insert second :f reduce ['print first first :f]
>
>Because the first (and third) of a function is not bound to the functions
>context.
>
>I think there is no direct way to get the word with binding, I could only
>get the words out of functions body :(
>
>I am working at a serialize script, which also serializes contexts etc.
>
>CU,
>Frank

[REBOL] Notice: Prepare for VID B5 Changes

[carl]

Dear REBOL/View/VID Users:

A change to VID for REBOL/View Beta 5.0 will break some of your VID scripts.

The change is in the stylize function.

Rather than using a unique dialect for style specification, stylize will take style 
names and facets in the same format as a layout. This will make it easier to remember 
how to create styles, since they will be done in the same way as layouts.  For example:

sheet: stylize [
btxt: text bold
rtxt: text bold right red
gbar:  box effect [gradient 200.0.0 0.0.0]
btn32: button 100x40 font [size: 32]
btn2: button with [feel: new-feel]
]

This will create the btxt, rtxt, gbar, and btn32 styles for use in any layout.  Note 
the general face spec in the last example using the WITH word.  This is the same as a 
layout.

An experimental version of View will be posted on Monday, giving you the chance to 
test and change your scripts before B5 is released.

There are many other improvements to VID B5.

The full set of predefined face styles will be:

Text Styles 
text - text (white with shadow) 
label - text labels 
title - title text 
subtitle - subtitle text 
norm - text (black, no shadow) 
H1 - heading 1
H2 - heading 2 
H3 - heading 3 
H4 - heading 4 
sample - example code 
field - text entry field 
area - text entry area 
Graphical Styles 
image - jpeg, bmp, or gif image 
backdrop - scale image to fit page 
backtile - tile image over page 
box - rectangular box 
anim - animated image 
icon - image with text caption 
sensor - image map 
Gadget Styles 
button - click for action 
toggle - up and down button 
rotary - multiple value button 
choice - pop-up button 
check - check box 
radio - radio button 
arrow - arrow button 
progress - progress bar 
slider - slider bar 
Panel Styles 
panel - subpanel layout 
list - text and image lists 

In addition there will be these requestor pop-ups:

request - simple requests
resuest-color - color picker
request-date - calendar picker
request-file - file picker

Also, you will be able to specify multiple facets for a face:

text "Hello" yellow blue  - yellow text, blue background
rotary "Breakfast" "Lunch" "Dinner"  - choices

And, finally, there will be a new set of welcome/install windows,
including one to help with content selection.

NOT ALL OF THESE CHANGES WILL BE AVAILABLE IN MONDAY's EXPERIMENTAL.
[Sorry to shout, but I want to make it clear so I don't get swamped with emails.]

There is an entirely new document for VID that will accompany this release.

-Carl

[REBOL] protect-system caveat Re:

[larry]

Hi Grant

This looks like a bug in 'help.  You should send it to feedback.  The
problem is caused by doing the

>> help protect-system

before doing protect-system.

Done in the other order, everything works OK.
snip
Script: "User Preferences" (31-Oct-1999/18:54:30-8:00)
>> protect-system
>> help protect-system
USAGE:
PROTECT-SYSTEM

DESCRIPTION:
 Protects all system functions and the system object from redefinition.
 PROTECT-SYSTEM is a function value.
>> first: 5
** Script Error: Word first is protected, cannot modify.
** Where: first: 5
>>

BTW You can use 'source to look at the code for both 'help and
'protect-system.  If you do

>>source protect-system

before doing 'protect-system, it does not cause this problem, which is one
reason I think the bug is in 'help.

HTH
-Larry


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 12:01 PM
Subject: [REBOL] protect-system caveat


> Setting protect-system seems to incapacitate 'help':
>
> >> help protect-system
> USAGE:
> PROTECT-SYSTEM
>
> DESCRIPTION:
>  Protects all system functions and the system
> object from redefinition.
>  PROTECT-SYSTEM is a function value.
> >> protect-system
> >> help protect-system
> ** Script Error: Word type-name is protected, cannot
> modify.
> ** Where: type-name: func [value] [
> value: mold type? :value
> clear back tail value
> join either find "aeiou" first value ["an "] ["a
> "] value
> ]
> if
> >>
>
> Bummer, huh?
>
> __
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
>

[REBOL] context of a function Re:

[rebol]

Hi Frank,

1. The Problem:
To associate the word a with the context of the f function's body, you
would have to use bind. The bind function requires a sample word that is
boudn to the target as its second argument. Because your body block of the
function is empty, there is no sample word, and therefore there is nothing
to bind to.

2. The Solution:
1. If REBOL Technologies added the following ability to the fourth
function, the problem would be solved: 

a) Like an object has a default word self defined, which is the object
itself, there should be a default word self defined for a function, and
that word self should be a sample word for the function's context.
b) If fourth receives a function argument, it should return the default
word self that is defined for the function's context.
c) We don't need to worry about people defining a local word self for the
function, since that word self can take over the rule of the default word
self. The fourth function will return the user defined word self instead of
the default word self, and that word is just as much sample word for the
local context of the function, as the default word self is.
d) A problem arises if the function is intended to manipulate a  global
word self, since the default local word self will hide the global version
of self. I haven't seen anyone complain about not being able to use a
global word self from within the context of an object, and therefore I
doubt that anyone will complain, if the same is true for a function.

e) Another solution would be to provide a default refinement /self for
every function that returns a sample word for the function's context.

3. An immediate solution
We can use this approach to implement our own solution. We define a cfunc
function, which emulates the func function and adds a /local word self like
this:

cfunc: func [spec body /local found] [
  either found? found: find/tail spec /local [
insert found self
  ][
insert tail spec [/local self]
  ]
  insert body [self]
  throw-on-error [make function! spec body]
]

Now we can create f as a cfunc:

>> f: cfunc [a] []
>> insert tail second :f compose [print (bind 'a first second :f)]
== []
>> f 3
3

Hope this helps,

At 06:31 PM 8/18/00 +0200, you wrote:
>Hi!
>
>Is there a way to get the words of the context of a function?
>
>Example:
>   f: func [a] []
>   g: func [a] [print a]
>
>Does anyone know a way to change function f AFTER its definition in that
>way, that it will work like function g?
>
>The following does not work:
>  insert second :f reduce ['print first first :f]
>
>Because the first (and third) of a function is not bound to the functions
>context.
>
>I think there is no direct way to get the word with binding, I could only
>get the words out of functions body :(
>
>I am working at a serialize script, which also serializes contexts etc.
>
>CU,
>Frank
>
>
>

;- Elan [ : - ) ]
author of REBOL: THE OFFICIAL GUIDE
REBOL Press: The Official Source for REBOL Books
http://www.REBOLpress.com
visit me at http://www.TechScribe.com

[REBOL] Sherman Re:(2)

[carlos]

So once existed a REBOL compiler. This is good to know.

Who knows at this very moment someone has  a new version "on the oven"?

Lorenz



- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sexta-feira, 18 de Agosto de 2000 13:38
Subject: [REBOL] Sherman Re:


>
>
> [EMAIL PROTECTED] wrote:
>
> > Does anyone on the list have knowledge on faith of Sherman the
> > Compiler?
> >
> > I tried to find it yesterday, but it has moved from it's old location.
> > I would also be happy if someone has the source on his harddrive, so
> > maybe he could mail it to me.
> >
>
> Sherman was private project of Joe Marshal, former emplyee of RT. It was
> REBOL 1.x compatible, so will not be of any use to current REBOL versions.
>
> It would be interested though, if something like the compiler is planned
by
> RT folks in some future ...
>
> Cheers,
> -pekr-
>
> >
> > Yours,
> > Jussi
> >
> > P.S. I'll be away for the weekend I'll be able to respond on Monday.
> >
> > --
> > Jussi HagmanCS in Åbo Akademi University
> > Studentbyn 4 D 33   [EMAIL PROTECTED]
> > 20540 Åbo   [EMAIL PROTECTED]
> > Finland
>

[REBOL] problems with local vars??? Re:(5)

[galtbarber]

To Andrew:
 why do you say that rebol functions 
are a kind of rebol dialect?

I thought they were more of a built-in type function!
There are some special things that happen in a function
that are all about binding params and locals,
but I would be surprised if functions worked internally 
like the dialect that is in parse or view.
If it works that way, it's a sheer revelation
to me.  In fact, how could you define a dialect 
without referring to other functions?
Is that a chicken and egg kind of thing?

To Everybody:
 in the examples given in this thread, 
there is none showing this obvious one using /local with func:

somefunc: func [
 n [integer!]
 /local tmp
][
 tmp: n * n
 ;;; snipped rest of code ...
]

I believe that internally 'function will just 
end up calling 'func and passing the block of 
locals as /local.  If you make yourself a function f
with 'function and then look at first :f, second :f
and third :f, you will see that in first :f there 
is the param list with the locals defined with /local.

I think this change appeared with Rebol2.

-Galt

p.s. although Rebol may be "interpreted",
the body and params and etc. have been fully 
"load"-ed and that means they are like typed 
tokens and bound words that are ready to roll.

It's not like a lot of simple interpreters which are converting 
straight from source as just a string of characters
for each and every line.

when the function definition is executed 
that baby creates the function! value and 
assigns it to the function's name word,
and that value sure isnt just a string! of code.

so that makes sense and the interpreter can run 
pretty fast.  I am sure that it is the same 
with Logo, Lisp, Scheme, etc...  I think the 
series type is also something that helps make 
Rebol fast.  I don't recall seeing its like 
in those other cousins of Rebol.

-Galt

>= Original Message From [EMAIL PROTECTED] =
>Brett wrote:
>> But I wonder if Rebol necessarily sees functions like this? Are they
>perhaps a dialect that is interpreted?
>
>Rebol functions are a dialect and they are interpreted.
>
>Andrew Martin
>ICQ: 26227169
>http://members.xoom.com/AndrewMartin/
>-><-

[REBOL] protect-system caveat

[grantwparks]

Setting protect-system seems to incapacitate 'help':

>> help protect-system
USAGE:
PROTECT-SYSTEM

DESCRIPTION:
 Protects all system functions and the system
object from redefinition.
 PROTECT-SYSTEM is a function value.
>> protect-system
>> help protect-system
** Script Error: Word type-name is protected, cannot
modify.
** Where: type-name: func [value] [
value: mold type? :value
clear back tail value
join either find "aeiou" first value ["an "] ["a
"] value
]
if
>>

Bummer, huh?

__
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

[REBOL] Sherman Re:

[Petr . Krenzelok]

[EMAIL PROTECTED] wrote:

> Does anyone on the list have knowledge on faith of Sherman the
> Compiler?
>
> I tried to find it yesterday, but it has moved from it's old location.
> I would also be happy if someone has the source on his harddrive, so
> maybe he could mail it to me.
>

Sherman was private project of Joe Marshal, former emplyee of RT. It was
REBOL 1.x compatible, so will not be of any use to current REBOL versions.

It would be interested though, if something like the compiler is planned by
RT folks in some future ...

Cheers,
-pekr-

>
> Yours,
> Jussi
>
> P.S. I'll be away for the weekend I'll be able to respond on Monday.
>
> --
> Jussi HagmanCS in Åbo Akademi University
> Studentbyn 4 D 33   [EMAIL PROTECTED]
> 20540 Åbo   [EMAIL PROTECTED]
> Finland

[REBOL] context of a function

[fsievert]

Hi!

Is there a way to get the words of the context of a function?

Example:
   f: func [a] []
   g: func [a] [print a]

Does anyone know a way to change function f AFTER its definition in that
way, that it will work like function g?

The following does not work:
  insert second :f reduce ['print first first :f]

Because the first (and third) of a function is not bound to the functions
context.

I think there is no direct way to get the word with binding, I could only
get the words out of functions body :(

I am working at a serialize script, which also serializes contexts etc.

CU,
Frank

[REBOL] problems with local vars??? Re:(5)

[bhandley]

Guru question.

Rebol functions are a dialect which is interpreted...
[ ]  At load time.
[ ]  After being loaded.
[ ]  Both of the above.
[ ]  The question is irrelevent and can be ignored without harm.
[ ]  Not enough information to say.
[ ]  Other (please specify). 

;)
Brett


- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 3:43 PM
Subject: [REBOL] problems with local vars??? Re:(4)


> Brett wrote:
> > But I wonder if Rebol necessarily sees functions like this? Are they
> perhaps a dialect that is interpreted?
> 
> Rebol functions are a dialect and they are interpreted.
> 
> Andrew Martin
> ICQ: 26227169
> http://members.xoom.com/AndrewMartin/
> -><-
> 

[REBOL] Sherman

[jhagman]

Does anyone on the list have knowledge on faith of Sherman the
Compiler? 

I tried to find it yesterday, but it has moved from it's old location.
I would also be happy if someone has the source on his harddrive, so
maybe he could mail it to me.

Yours,
Jussi

P.S. I'll be away for the weekend I'll be able to respond on Monday.


-- 
Jussi HagmanCS in Åbo Akademi University
Studentbyn 4 D 33   [EMAIL PROTECTED]
20540 Åbo   [EMAIL PROTECTED]
Finland

[REBOL] problems with local vars??? Re:(5)

[agem]

--- [EMAIL PROTECTED] wrote on 18-Aug-2000/13:37:06+1:00
> 
> i add my description too hope its new :)
> ...

> >> repeat i 10 [append [] i]
> == [1 2 3 4 5 6 7 8 9 10]
> 
> ( do copy [repeat i 10 [append [] i] ] ; in a function ..)
> 

do copy/deep [repeat i 10 [append [] i] ] ; in a function ..

copy/deep of course..

Volker

[REBOL] problems with local vars??? Re:(4)

[agem]

i add my description too hope its new :)

REBOL makes no destinction beetween data and program.
not to the user: you can edit text and you can load (do) text.
not to the program: it can edit blocks and load (do) blocks.

the "a:" should be seen as a "bookmark" in a block.
nothing more. in a functions it bookmarks into a part
of the function. if it changes its content, it changes
the function too. if you want to avoid it, you have
to tell the system "i need a new block". which can
be done by

copy "this string (or block or other series)"
or 
make string! 1000 ;empty string with 1000 char preallocated

when it comes to do code, the system can not decide
if a block is only read or changed to:

if something [some code]
print "this string"
change [datas here] 'code
yes-way: [some code] if something yes-way ...

and maybe one wishes to really change the function?
simply like c's "statics" or because of clever meta-hacks or
to keep scripts shorter? would need new sytax otherwise.

>> repeat i 10 [append [] i]
== [1 2 3 4 5 6 7 8 9 10]

( do copy [repeat i 10 [append [] i] ] ; in a function ..)

or
repeat i 10 [append list: [] i]   probe list

you can collect scripts output with

>> &: func[s][append append "" s ", "]
>> & "this" & "that" third second :&
== "this, that, "

short :)

>> &: func[s][append append "" s ", "]
>> get-res: third second :& 3 ;change if '& changes!
== 3
>> & "this" & "that" res ;use it
== "this, that, "

safer. i remember to change 'get-res if you change  '& ..

>> &: func[s][append append res: "" s ", "]
>> & "this" & "that" res
== "this, that, "

better. should have thought before :)

other ways like auto-copy may break concepts i not
know yet.., and may be slower..

--
Volker

--- [EMAIL PROTECTED] wrote on 18-Aug-2000/10:09:43+10:00

> > > Here's your function slightly edited
> > >
> > > local-func: function [input][my-local-string][
> > > my-local-string:  ; This says make it so that my-local-string
> refers
> > > to the next value. (1)
> > > "that is local " ; This says create a string value. (2)
> > > print append my-local-string input; (3)
> > > ]
> > >
> >
> > I think it's slightly confusing to say in (2) that the literal string
> > "says to create a string value".  Instead, I suggest that in (2) the
> > literal string IS a string value.  (If I had my geek hat on, I'd say
> > something more complicated like "serves as a reference to the string
> > that was created when this source code was loaded", bit I left my geek
> > hat at home today... ;-)
> 
> Yeah, it probably is a bit confusing. I confused my contexts. I intended to
> to convey the sense that Rebol "does it differently", especially compared to
> a compiled language (which was the example), rather than attempting to
> explain the deepest truths behind Rebol (which I'm not entirely confident
> on). I should have made that clear. I sould have also made clear that my
> meaning referred to what happens at load - distinguishing between might
> happen when Rebol script is parsed as opposed to when Rebol values are
> evaluated.
> 
> > Every time the function referred to by to local-func is evaluated,
> > my-local-string is set to refer to THE SAME STRING, rather than a
> > newly-created one.
> 
> This sounds like a nice description when you have the expectation that
> functions always do something (their definitions) when they are evaluated.
> That they carry out all the parts of their definition when evaluated. A way
> of thinking that says "this function now has program control" so it has to
> do something (which is quite reasonable to imagine). But I wonder if Rebol
> necessarily sees functions like this? Are they perhaps a dialect that is
> interepreted? I only ask this because I'm trying to shake of my normal
> assumptions of what Rebol is doing when it evaluates a "function" which is
> after all a Rebol value not something like machine instructions (another
> guess!).
> 
> >  Therefore, mutations on the value of my-local-string
> > (e.g., append, insert, remove, replace ) are continuing to operate
> > on the same string which ORIGINALLY (at load time) contained
> > "that is local ", but which has subsequently been modified with every
> > evaluation of the function.
> >
> > I don't want to sound hypercritical here!  I'm really just thinking
> > out loud about how to describe the behavior of literal series values
> > in REBOL, as this sort of thing keeps coming up on the list.
> 
> Yes, I know. I've collected three useful descriptions of it on my tips page.
> But I feel that at least two levels of description (absolute beginner/ not
> an absolute beginner) could be useful - differentiated perhaps by one using
> metaphor and the other describing "the truth"...
> 
> > You certainly described the correct solution in the remainder of your
> > note, but I'm wondering if making a more explicit distinction between
> > load time and evaluation time will help us explain this.
> 
> Well, I think Elan can t

[REBOL] Problems with remove/part refinement Re:

[allen]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 4:15 PM
Subject: [REBOL] Problems with remove/part refinement


>
> Hi all,
>
> i got following script to clean up and modify a file:
>
> REBOL [
> Title:  "Tsbewout - Cleaner"
> Date:   16-Aug-2000
> File:   %tsbewout.r
> Author: "Thorsten Moeller"
> Purpose: {   Cleans tsbewout-file  }
> ]
>
>
> remove: func [act] [
> script2: read %tsbewout2
> parse script2 [some[to act mark: (remove/part mark 1)]]
> ]
>

You redefined the 'remove function, and when you call 'remove/part that
refinement is not part of the new 'remove function you wrote. Give your
function another name, that is the easiest thing to do.

REBOL allows us to redefine functions and that can be very powerful, and a
little dangerous.
To help prevent you accidentally doing this you can put protect-system in
your user.r
? protect-system
USAGE:
PROTECT-SYSTEM

DESCRIPTION:
 Protects all system functions and the system object from redefinition.
 PROTECT-SYSTEM is a function value.'

Cheers,

Allen K