World: r3wp

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?

not sure .... dunno how AGG is integrated, maybe AGG compositing 
is not used at all? Difficult to say ... but I expect radical redesign 
of View - at least we can be sure there is new event system placed 
inside, hopefully libevent .... so I expect even some compositing 
system changes and also face concept redesign ....

It would be nice if Carl would blog a bit about new View internals 
....

I hope there will be direct access to the buffer rather than going 
through SHOW. this would speed up operations immensly.

If Cyphre is in charge, I expect him to push Carl for more media 
features :-)

well, if he gets them through, it screams AmigaDE replacement, which 
can be a good thing right now

of course .... noone except few companies use AmigaDE ... AmigaDE 
(let's talk intent), has some powerfull media capabilities ...

.... but dunno, if today, being self-hosted, means an advantage - 
there is nowadays lot's of even small OSes Rebol can run on-top of. 
I prefer it being that way ....

Volker, parentese fails in this case. The 
body of f didn't change 
as matter of fac t
it runs and produces as result 6. But the
parentese 
func fail to produce an expression 
for it. 



ctx-tuneme2: context [
    
	append: func [arg1] [arg1] 
    
	add: func[][none]
   
	 f: func [] [append 7 append add 5 6]

]



ctx-tuneme2/f ";run it once" 

probe parentese second get in ctx-tuneme2 'f


  ** Script Error: get expected word argument of type: any-word object 
  none

** Where: parentese-once

** Near: arglist: first get first code

So ctx-tuneme and ctx-tuneme2 has the exact same body for F..  However 
they perform different evaluations, one compiles another not. This 
is the problem. Now you can keep tuning parentese, but I bet it is 
always possible to find a way to break it.  The larger the body of 
F, the more posibilities for evaluation exists.

No, that is a problem with an intentionally limited quick POC.
But i had to blink twice. :)

It currently expectes that all expressions start with a word. Now 
tuneme2 is  [(append 7) (append add) 5 6].
And it fails. As it should with this limited subset. 
Found it after adding a probe,
      arglist: first get probe first code 
which gave 5 on last run.

I do think  i can match rebol completely (means a rebol with small 
additions/restrictions).

Its as tricky as to compile, say 'c. There are lots of exceptions, 
but in the end it is possible.

Handling standalone values is one of the first thoughts of course. 
then there are operators and refinements. Then deciding if something 
is rebol-code or not (that needs an extension. 'do must flag it processed 
the block. So that parse-rules etc can be detected as data and the 
parens inside are detected as "run by do". Surely more small things, 
but should be doable.

Btw makes nice coverage-tests then)

http://www.cs.vu.nl/~ast/reliable-os/

volker, nice read. very easy to digest.

Yes, Tanenbaum can write:)

Fission: https://addons.mozilla.org/firefox/1951/

Puts the progression-bar below the url (at the top, where one looks). 
Interesting feedback.

below means bar is now the url-background.

Volker, I never say that compiling rebol is not possible, I said 
that is exponentially difficult.

So in practice compiling rebol is a pain in the arse.

Much more than other languages. Because there is no easy way to make 
assumptions. The moment you make an assumption you leave space for 
a compilation hole.

Now if the Rebol becomes a function first language like lisp you 
can get a bit further but still you will need some other markers.

No, exactly not. Without that "run first" yes. With it not. Or i 
miss something very stupid.