World: r3wp

So you will make executing slower, because now the interpreter needs 
to keep track of the whole tree to see which values changed and which 
are a violation of contract.

Options are debug-mode, or pointing out that other things are checked 
too.

Or a compilable-function! , which would be a little bit slower until 
the jit kicks in.

compilable-function! is possible.

That is what rewrite rules and rebcode accomplish.

rebcode would be the cross-platform-target. could be still 10* faster.

Yes. I like that. But this was may point the CFG of rebol is great 
it allows for very neat tricks. But the expense is you can not compile 
easily.

IMHO its main advantage is in creating code and readability. Not 
in kind of self-modifying code.which you do when you turn calls in 
arguments by changing the  arglist-len.

BTW, compilabe- function shares some of the traits of closure. closure 
are a separte function in rebol because they are expensive. In Orca 
we made all funcs to behave like closures, but we decided to factor 
it out like in Rebol to keep the speed gains.

varargs are not the reason for not having a compilable language. 
Both Lisp and C support varargs, and both are compilable languages. 
The culprit is CFG.

From the poing of view of the compiler developer he can't make any 
assumption on how to compila a rebol expression, while in C and Lisp 
he knows that the forms are fixed.

Both enforce parens. its not the varargs which make problems, its 
the number of expressions. The compiler must know where the expression 
starts and ends.

He can not make assumptions from the sourcecode. But he can when 
the function has run and supports some ways of reflections.

Exactly what I said "the forms are fixed".

Yes. In rebol too, when a function has run.

No true. The example I show you ( test: does [foo bar]) has two different 
executions.

And this function has fixed arity.

IMHO that example is artificial. Out of my head i can not see where 
that is usefull. So i would simply forbid it.

Jaime, just had a look at 'migrations' and it's not the same at all.. 
 here's the pseudo code just to change the db with rails..

    * Step 1: Create a migration with script/generate migration WhatImChanging
    * Step 2: Modify your generated migration file in db/migrate
    * Step 3: Run rake migrate

    * Step 4: Revel in the fact that your database is converted to the 
    newest schema!


With Framewerks you never alter the DB.. it's a black box where data 
goes in and out.

How can you say you don't need to alter the db.. when the second 
step needs code like this?.. 
class AddUserTable < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.column :first_name, :string
      t.column :last_name, :string
      t.column :birthday, :date
    end
  end

  def self.down
    drop_table :users
  end
end

with Framewerks, you could copy a form from any web page, change 
the 'action' of the submit button.. and it will work perfectly.  
Rails cannot do that.

From "usining Ruby on  Rails for Web Development" article

<quote>

If you try to submit the form, Rails complains that it can't find 
the record action to handle the form post. We need to define that 
action in the ExpensesController. Add the following action method 
to the app/controllers/expenses_controller.rb file:

def record
 
 Account.find(params[:id]).expenses.create(params[:expense])
  redirect_to 
:action => 'show', :id => params[:id]
end

</quote>

So rails DOES require the DB schema to be modified AND the server-side 
processing to be modified as well.

And not only does it need to be modified.. the syntax to do so is 
archaic.

Volker, You can not forbid it. That is just a simple function. It 
will be the same than this test: does [append s v]. The body of test 
is not compilable because the block [append s v] execution depends 
on the environment.

Terry you are right, but you don't need to drop the table to alter 
it. The have add_column and remove_column methods within others.

Regarding how the controller is addapted, it depends on the way you 
are generating your code. They have very good generators.

And finally I can't really be fair to framewerks becuase I have not 
play with it or see its code, and how it handles and/or store information.

Volker, I meant you can not forget it. [foo bar] is the simples example 
that illustrate the problem of CFG.

Volker here is another example,



anyF: does [f g h
]

f: func[x][print "f third" 2 * x]

g: func[y][print "g second" y + 1
]
h: func[][print "h first" 1]


anyF ;; == f(g(h()))

;; 

now lets change 


g: does [print "g second" 5

]

anyF ;; == produces something like f(g()) h()


  anyF is compilable only if the order of evalutation 
doesn't change 
  at runtime. 

Rebol permits for the order of evalution to be determined 
  
by the context in which anyF is run, and the interpreter is 
smart 
  enough to GC the unconsumed values.


   This is a feature of Rebol because with the same expression 
you 
   can have two very different meanings, the disambiguation 
of the 
   grammar is provided by the context (or environment). 
This allow 
   Rebol to support easy Dialecting. That is each 
DSL may need specific 
   evaluation orders, aka semantics, 
while they share the same code 
   expression. In this case [f g h].



In the example above two different branches of the AST three 
were 
followed. But by just looking at [f g h] is impossible
to know which 
branch will be taken. 


  Other compilable languages enforce the order of evaluation by 
using 
  specific syntax forms to determine what is an expression. 
 Lisp 
  uses  parens, while  C semicolons and others markers.

 


So in order to make anyF compilable we need to  enforce the 
order 
of evaluation.  One possibilty  is to use Rebol parens.



anyF: does [(f) (g) (h)] ] *** see note


  The cost is evaluation speed for the interpreter, and now 
we are 
  back at using parens at each step. Which is what 
lisp uses. Should 
  we go back to 1967?


  The alternative of JIT is possible, but  it requires hinting and 
  
a sofisticated runtime environment. The translation of Rebol 
code 
  to some an  internal VM like rebcode  is simpler and maybe 
sufficient, 
  otherwise extending rebol via DLLs  is the way to 
get closer to 
  the metal. However, I don't see an easy path 
to having a Metacircular 
  Rebol. If you do, I hope you write
 a Rebol compiler and share it 
  with us ;-)

*Note:  For the first set of definitions of f, g, h and anyF the 

block [(f) (g) (h)] is not enough to enforce the order of 
evaluation 
(f(g(h))). That is h first, g second, f third, 
with each function 
applying to the result returned by the 
previous one.



anyF: has [r][
   
	 r: h
   
	 r: g r
   
	 f r

]


  Does the trick
.  However the original definition  was shorter and 
  prettier, even though ambiguous.

I always code with parens in mind. I understand that rebol can do 
this f g h - things, but i cant imagine code where i change the length 
of the argument-list and both versions have  usefull meaning. (except 
of shortening the list and relying on the "nop"-effect for the other 
args, but even that is risky.

parentese-once: func [code "at function-start" /local arglist pos 
out paren] [
    arglist: first get first code 
    pos: next code 
    out: reduce [first code] 
    loop length? arglist [
        either all [
            word? first pos 
            any-function? get/any first pos
        ] [
            set [paren pos] parentese-once pos 
            append/only out paren
        ] [
            append/only out first pos 
            pos: next pos
        ]
    ] 
    reduce [to-paren out pos]
] 
parentese: func [code /local paren out] [
    out: copy [] 
    while [not tail? code] [
        set [paren code] parentese-once code 
        append/only out paren
    ] 
    out
] 
ctx-tuneme: context [
    append: func [arg1] [arg1] 
    f: func [] [append 7 append add 5 6]
] 
ctx-tuneme/f ";run it once" 
probe parentese second get in ctx-tuneme 'f

I see no real problems with this

AGG 2.4 released - some things redesigned, it is major version update. 
It now allows to render Flash path curves data directly - http://www.antigrain.com/news/index.html

Does it mean we can use Flash IDE tools to do animations, save them 
as curves and then possibly render it using AGG 2.4 in View? :-)

why bother?

I guess there are svg->gflash-tools?

well, Terry - for those who like animations? We don't have any Authoring 
tools for view/draw yet ... so why not to be able to "play" some 
SVG or Flash vector data?

Because Terry uses flash directly, which can render flash too ;)

.... and as View does not allow for media integration (I have heard 
it can change), so no avi, flash, etc. integrated, you can't use 
3rd party technologies with View stand-alone apps ...

Flash can render Flash? Never thought about using it in such an easy 
and direct way :-)

But it could mean the other way around. 'draw -> flashcurves -> flash. 
The master of flash-dialect would be happy :)

hopefully Cyphre will bring 2.4 into View ......

He mustbe very busy if he can resist :)

how much of AGG does DRAW take advantage of currently?

full?

IMO old draw C code was all replaced by AGG equivalent ...

... and for new Rebol (but Cyphre or Carl could confirm), IIRC someone 
said, even compositing engine will be replaced, just dunno if by 
the one in AGG ...

it would make sense if it was. it would make View a little smaller, 
wouldn't it?