World: r3wp

Example for which part?

Where changing argument-lists make sense.

APPLY

I can only imagine cases where that is a bug.

With a bit code around?

I can simulate lisp APPLY with a dialect. APPLY require variable 
number of args>

Same for lisp MAP.

In rebol i put those args in a block.

So some of the higher-order techniques.

Lisp does that too in a way, because it puts things always in parens.

Ah. But the point is not that you code in Rebol, the point is that 
if you implement a DIALECT that has different semantics and shares 
the value types! of rebol then you can compile such dialect.

So it would be 
  apply reduce[arg1 arg2]
istead of 
 (apply arg1 arg2)
Or do i miss something?

Yes. Lisp parens are its compilation unit.

And in lisp arg1 none of the args causes evauluation while in rebol 
the may.

I meant ".... value types! of rebol then you CAN'T compile such dialect."

And in rebol we have none when looking at sourcecode.

But actually, when a function runs, its "compilation-units" are always 
the same. Meanswhen a function is run, the lisp-parens can be inserted 
by reflection. (except of strange hacks)

Basically the eval form of lisp is fixed, it is part of syntax, and 
it is (func args ...)

And in rebol it is [func arg arg2 block-of-variable-args]

At least that would work for 95% of rebol.

Not to expensive to get a lot more speed. (interpreter would be always 
available too.)

In rebol the is not special *eval form*, evaluation depends on the 
specific  expression.

But the expression does not change. its "parens" are always on the 
same places, in each evaluation.

do [val1 val2 val3 val4] ?? What this program produce?

So that part can be compiled.

Run it once.

If the parens are different thenext time, there is usually a bug.

Not enough. It depends on the environment.

What if i enforce that, by keeping track and checking somehow? Do 
you have an example wherre that would hurt?

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>