AltME groups: search

A server-side scripting language which cannot handle literal strings 
- and especially one that claims to be Unicode - has to be excluded 
from consideration for templating web content which is expressed 
in any other langauge which uses curly braces.  I told BrianH that 
the red flag here should be Tcl as Rebol shares this with Tcl.  Literal 
string are literal strings.  Period.  No if's and's or "that might 
be my curly brace in there" ...  Unless you dream of a Rebol-only 
world - and that fantasy should have passed some years back.    This 
falls under the heading of folly - a topic too often neglected.  
Folly in a meritocracy usually requires some individual to speak 
up.  But the folly of meritocracies is that  to be heard taht individual 
would already have to be playing within those constraints.  We see 
this in schools which graduate top people distinguished for inidividual 
effort who then do not fit well into teams.  They did group work 
in college by being the one who saved the group from failure by ... 
their individual effort.  For me this will be what makes or breaks 
my involvement with REBOL.  I could not wait for REBOL4 and hope 
for change then by getting into the merit circle.  My outside voice 
would have to be heard before it is too late. Tcl as the do-all is 
folly.  As nuch as I admire OOTcl, the XOTcl IDE and Expect.  I cannot 
use Tcl with "balanced brace" foolishness.  Of course if we all adopt 
XML and abandon scripting in non-XML languages ... So  We have comment 
{  }  and that was a mistake: it should have been symmetrical as 
in c{ comment here as literal with } or whatever }c   And that is 
water under the bridge.  We cannot be UNICODE and claim that  we 
must escape a certain pair  of characters if ithey are in a literal 
string.  That is silly. Ludicrous. Folly.  A literal string is a 
data value where you do not get to peek.  Imagine a proxy object 
that said: "I will be your proxy only if you promise that when the 
real object appears it does not contain [ folly happens here ] " 
  Many forms of "catch-22" in the world of beaurocratic regulation 
have a similar pattern.  I am no expert on unintended consequences, 
but requiring that some pair of characters be escaped in otherwise 
literal content has consequences for TEMPLATE value TEMPLATE  There 
should be a lesson there: some markup must be arbitrary and the choice 
will matter.  { and } are the wrong choice.  At least the terminal 
markup must be "sacrificed (it will always have to be escaped so 
pick carefully.   [{ is a bad combo for JSON so #[{ looks worrisome 
to me.  I propose lit |ls# and_content_then  #ls|    Someone shoots 
that down and we inch towards a suitable result.  Not perfect.  But 
usable.  { and } are not useable in the real world on the server-side 
if rebol is to play a role with other languages.  Play nice.  Please.

RobertS: not much into that topic, but -  your note that #[{ is worrisome 
for JSON sounds strange. So we should use obscure syntax to support 
some JSON or what? Then comes someone next who uses something else, 
and we will give-up the option too?

excuse me, but what is wrong by escaping by ^{  and ^} ? In R2, left 
curly brace escaping does not work in console only, but script being 
run from file (which is case on the server anyway) is OK. In R3, 
which soon will be ready to replace R2 for such scenarios, it works 
even in console. But probably I am too dumb to understand the issue 
involved :-)


Could someone please give me a snipped of some quoted JS or other 
code, in order to get the issue? Would like to try the headache myself 
:-)

Pekr: take any peice of template code that ends with curly braces 
unbalance, then insert a value through templating and then clsoe 
off the curly braces.

Now try assigning those opening and closing pieces to variables so 
as to generate code.  If you try to use Rebol then there is an immediate 
problem because a great deal of real world code uses quoted strings. 
 So now you need a literal string.  But in Rebol that will be in 
curly braces. Sunk.  Now you are escaping chartacters when you are 
tyring to generate code.  No problem if code genrated by Rebol is 
consuked by Rebol.  But that is not realistic.  So now you are generating 
code with Rebol but then preporcessing hte code with Perl to strip 
out the escaping carets on the ^{ and ^} ???

JavaScript and ActionScript enjoy "psuedo-popularity" ?!?  And white 
wine - say Chablis - with seafood ... pseudo popular as well?  Someone 
who thinks the latter drinks too much beer or too much whiskey or 
no wine or what?

real world code

 ... then why using REBOL, if there is plenty of  real world much 
 better code much better languages around. I can accept anything, 
 maybe the fix is easy, and then we should just submit a ticket, or 
 - the worse case, it could affect REBOL internal parser, making it 
 more complicated, slower. Dunno ...

Ok fine.  But R3 also rejects  comment  {this is my silly test { 
}   and whatever could explain that could not justify that in the 
real world.  Back to Tcl we go.

our literal string is "content" {content}, and if you want to use 
quotes or curly braces, you have to escape them ...

So what you are asking for is to use some really weird combination 
of chars, which could not by accident happen inside your string (unless 
someone is crazy), and use them as a string delimiter?

A literal string has an indiated start and an indicated end and between 
you do not hiccup - how could we break comment on another forward 
curly brace?

Escaping characters in comments is pure Tcl to my mind.  I love Tcl. 
 But it should be used as Expect for what it is good at.  Rebol is 
far more powerful and flexible and on one point exceedinly silly.

The Tcl community has had some very high-level discussions among 
serious Tcl experts on their comment and brace balancing  issues. 
 The result is that their problems are there to stay.

What about using a word which requires three paramaters the first 
and third of which must be those delimiters ( smart might be to have 
3 sets of delimiters which need not even be paired - or to have what 
counts as a delimiter set for the user context with one pair of system 
defaults.

I thinkt he answer is to have Carl open a post on his R3 blog and 
get some comments - somefeedfack can get us to toptimal choices - 
maybe the anser is to have 3 pairs avaialbe - I don't know ( I'm 
just a Rebol user, not a Rebol guru )  Okay, Okay, I'm also a pain-in-the-neck 
 ( I really do have cervical osteop. in real life - not usually funny, 
but that's life ;-)

I am hoping this is on BrianH radar ...  I thought at one time you 
were kinda the guy who spoke for the community ?  Gab is aware of 
this and Oldes - doesn't he generate FLASH or PDF or something ? 
 At the moment my own option is to take shelter in PHP and PHPTemplate. 
 I wanted to fall back on Smalltalk but all the web frameworks from 
the MVC gurus seem to miss the point that the View was supposed to 
be de-coupled.  Go figure.

Personally I could not just wait for R4 and hope to see it fixed 
there. Any langauge which cannot tolerate literal string I cannot 
use.  Any of the alternatives are nowhere as suitable as rebol to 
server-side scriping.  I love Rebol.  It's not personal.

R4? We are working on R3 for 3-4 years and still not finished. Before 
we get to R4, I will retire :-)

I think that in UNICODE raw string is now meaningless to end users; 
Americans ignore that European languages often have variant opening 
quote from closing quote ( as did British English in my youth, as 
I recall )  this is a new phenomenon in America: educated Americans 
spoke French, read French and if they were mean, had often spent 
time at a German university,  The North American shool system was 
of Prussian insoiration, as I recall.  But atleast Carl is learning 
French ... but does he use << and >>  ... that I woulldn\'tt know 
\"  ;-)   So that leave literal strings  such as @"  "@  I still 
use a language with a character count delimiter pair

some string literals should be un-preprocessed and un-processed verbatim 
content.  "Verbatim string" might be less confusing than "literal 
string" which sould like "string literal".  "pristine string" has 
a nice ring.   vs{  virgin string  }sv

RobertS, you said that similarity with TCL is a red flag, but that 
is not the case. TCL, like Ruby, is known to be bad because of its 
internals and semantics, not its syntax. XML and Perl are the ones 
with bad syntax.

So now you are generating code with Rebol but then preporcessing 
hte code with Perl to strip out the escaping carets on the ^{ and 
^}

Completely unnecessary. REBOL escaping is only a REBOL syntax trick 
- in memory the escaping carets don't exist. If you don't want carets 
in your output use PRINT, FORM, WRITE, or anything but MOLD. There 
is no interoperability argument for heredocs whatsoever.

REBOL can generate JSON just fine, and there are no carets in the 
generated output.

I am not saying that heredocs are a bad idea (and have given some 
advice on them in the CureCode ticket). However, they are not *needed* 
for any of the reasons that you have stated. The only reason we would 
want them is for minor ease-of-use improvements, and because several 
other languages in roughly the same category as REBOL has something 
similar.

RobertS, this means that you can do server-side processing of JavaScript 
using R3 right now, without heredocs. All you need to do is escape 
unbalanced { and } in your REBOL syntax { } delimited strings. The 
escaping is resolved at LOAD time, so the resulting strings don't 
have escape sequences in them. Then you can combine and generate 
the resulting string data without concerning yourself with escaping.

A server-side scripting language which cannot handle literal strings...
 (the long message)

I had a little difficulty finding any criticisms of REBOL or its 
string literals in this message that actually apply to REBOL 3 even 
now.


- { } balancing exists make generation of brace languages like JS 
and CSS easier. You only have to escape { and } if they are unbalanced 
in the syntax; most of the time they aren't. R3 already fixed the 
^{ console bug, so that isn't a problem. And the escaping only applies 
to REBOL syntax, and is resolved by LOAD - there is no escaping in 
the data once loaded.

- COMMENT is a function, not syntax, and that function doesn't even 
need to be there most of the time. REBOL doesn't have block comments 
at all. And doesn't need them for the most part - COMMENT works when 
they are needed.
- The meritocracy argument doesn't apply here (or make sense).

- Unicode is supported just fine (at least within the BMP). String 
escaping doesn't affect Unicode support.

- String escaping doesn't affect string data - it's just a syntax 
thing.

- JSON is supported just fine in R3, better than in R2 since the 
R3 data model is a better match. String escaping doesn't affect JSON.


The one part that made sense is that #[{ }]# would be bad for specifying 
JSON data - true that. Something starting with # for the start delimiter 
would be good, but not starting with #",  #{ or #[  since those would 
conflict.


I suggested in the CureCode ticket that the last character of the 
start delimiter and the first character of the end delimiter be newline 
- this would make the heredocs really distinct. There would not be 
a need for single-line heredocs because there could only be a small 
number of characters in them, small enough to escape. Just a suggestion 
though.

I'm seeing a bad conversion for alpha-77 under Windows Vista 32-bit:

    system/version
    == 2.100.77.3.1
    9200000000000000000
    == 9200000000000000000   ;; good
    9300000000000000000
    == 9223372036854775807   ;; bad  
    9999999999999999999
    == 9223372036854775807   ;; stays bad up to here 

Brian is not seeing this problem under a different Windows.

Could you try it on your rig and see what happens?
Thanks. That'll help narrow down the problem area.

Anyone running 7 32bit? I only have 7 64bit and XP 32bit here.

Some of my module changes involve shuffling code from one function 
to another. It's possible that Carl's added code in IMPORT should 
be moved to LOAD, for stability and flexibility. I also integrated 
extensions into the module checking and override model, but need 
to know whether there will be problems with doing LOAD-EXTENSION 
more than once with the same extension (necessary to see if it is 
already loaded).

You can also statically link SQLite into your extension DLL, and 
just export your extension wrapper code, or the whole of SQLite if 
you want to do the trick like tclsqlite or System.Data.SQLite. The 
real trick is making a proper database access model that fits into 
R3. This might be tricky with extensions v1 because we don't have 
device support yet.

If you look into R2 SQLite driver, then it is scheme around few calls 
to wrapped DLL functions. I am not looking for something more. Lack 
of DB drivers is what imo holds guys back from turning into R3. There 
is less and less reasons, to use R2.

I thought I'd need user-defined function types to make a JIT compiler, 
and those are much further down the road than devices. It turns out 
tthat the command! type is sufficient, today. I could start adapting 
a JIT next week.

The problem is, that both Device and RXI models are not much practically 
tested, no? Or does R3 uses Devices internally already for IO?

I'm not sure how devices will be integrated, but know they must be, 
and soon. R3 uses devices internally and  they work great. The trick 
is integrating devices with plugins.

I've traced through the RX code (there isn't much of it - extensions 
are *simple*). It's a great model. I have a few low-level questions 
and one or two requests, but the overall model is pretty solid. There 
are GC considerations that still need addressing though.

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

Henrik, yeah, XP seems to do the right thing, throwing an error - 
it's only Vista and 7 that fail and return the wrong number.

Gabriele, I probably worded my last comment a bit strongly. (I don't 
want to enflame the situation..) Of course I highly value your judgement, 
opinions and suggestions. I should say, though, that I read your 
previous comment as somewhat dismissive of RobertS concerns / problem.

With your #[{ ... }]# suggestion, I think it looks pretty good, and 
could be extended with specification of an end delimiter. With so 
many computer languages of all different syntaxes, having a way to 
specify the delimiter allows it to flex to any situation. 
We could add a second string to the block, eg.
The end delimiter is END:
	#[{END} {... END}]#
or a simple newline char:
	#[{^/} {... ^/}]#
or a secure hash:
	#[{92838929838} {...92838929838}]#

I see that the en wikipedia has an article on verbatim strings in 
PHP under "here document" which in PHP documents for print and echo 
is acalled the "here document" syntax (of course PHP calls print 
and echo constructs and not functions or procedures ... ) http://en.wikipedia.org/wiki/Here_document

My PHP page has no escaped characters becuase I can use the so-called 
"here document syntax".  That is critcal for my templating needs. 
 If your templating will only be done by rebol developers, it is 
of course a moot point: Rebol developers do not need heredocs/  But 
are all users of rebol going to be rebol developers?  That is the 
dialect issue.  And in the case of PHP (jsut an example) many PHP 
users are not PHP developers.  The wiki page has examples from python 
or ruby if the mention of PHP offends purists .. ;-)

not to vex, I hope, but I just saw that PHP 5.3.0 added so-called 
"now docs" which are what I call literal strings or verbaibm strings 
in that no substitiutions occur so no escaping is done.  I believe 
this how at least comment {should behave in R3 if I use a { as in 
just print {this} { to get the effect you want }  which comment is 
not the same which has to explain that you do whis without the escapes 
- which is fine if thosei are the only and very  escapes in question 
...

The PHP restriction on HEREDOC and NOWDOC is that the closing identifier 
( a label, if you like) must appear after a nl and there must be 
ONLY a nl immediatly after its ; terminator  - a restriction  which 
seems not at all onerous in practice now that I am using them

In Firebird's sql language, we can specify the delimiter and then 
restore it  after dealing with a bunch of code/text.

hehe, interesting - I run call "cmd.exe" and now I seem to get the 
mixture of windows shell and rebol one or so? :-) REBOL history is 
gone, when I try print "ahoy", it returns czech message, telling 
me PRN can't be initialised :-)

cmd  invaded
 - is that correct and/or desired behaviour?

the strange thing, that once being in cmd console, dir c:\ did not 
worked and returned "dir has no value" message ...

Press Windows key + R, then type "cmd" and enter.

and to get and set the current directory. CD ?

Anton: my comment may be dismissive, but the point I'm making is 
that that is just my opinion, I'm not sure why I should be forced 
to "like" a heredoc syntax :) I understand that it is very handy 
on occasions, but the price is a ugly script, which I'd rather not 
pay if I can avoid it easily enough (for example, if I were generating 
a lot of PHP or JS, I would just build a dialect to do that, instead 
of using strings). Again, though it's funny for me to have to repeat 
it again and again, this is just IMHO, Robert should be free to do 
things his own way, and if REBOL can provide a syntax for heredocs 
without creating other problems I'm fine - I'll just avoid it (and 
I'll hope not many people start using it ;)

Gabriele, I had a look at a few of the heredoc formats and some of 
them do look quite ugly. I admit that I actually haven't used heredocs 
myself yet, only come across a few snippets here and there recently, 
so I guess I don't have much experience with them yet, and can't 
tell what problems they may cause. My initial thought was that they 
would be a good idea, since you could just paste foreign code straight 
into your script.

Pekr, commands like dir and path are built into cmd.exe - they aren't 
separate programs. So CALL "cmd.exe /c dir" should work.

At a command prompt, call cmd /? to get help on cmd.exe and its commands.

Brian - what's the mess with intermixing cmd shell, and rebol one? 
See above output. And why do I need to hit enter to get back to rebol 
console?

Call is pretty unusable with R3. I have to say, that some ppl could 
already move to R3, but we have few showstoppers:

- call - really bad situation ....
- missing networking protocol 
- missing CGI mode

- DB access ... now we can proceed with extensions for SQLite, but 
not sure. If call would work at least, we could at least call sqlite.exe 
;-)


Unless those issues are fixed, R3 will be in alpha stage, and my 
opinion is - absolutly unnecessarily ...

Yeah, we will have to wait and see if they develop 'call further.

The word "command" is more specific, and better expresses what you 
are referring to.

I have heard at least one other opinion, that name "command" might 
be too worthy to waste on simple and signle thing as wrapping merely 
a funciton call. Of course even Devices have commands, but those 
are not probably rebol level related and influence nothing ...

and to just describe meaning of wrapping a call, I though external!, 
extern!, ext!, wrap! could be used instead. Probably too late to 
try to convince anyone :-)

more interesting stuff on Chat :-) I expressed opinion, that we use 
assymetry for read and write with strings, Carl objected. His second 
post might be interesting for you, as he for few moments thought, 
where is the right place for such stuff. I think that you would enjoy 
putting your opinion there. Of course - my post was done just to 
provoke some discussion :-)

I just read it, and was about to reply to your counter-post, just 
to one point.
External

 is an adjective. When used as a noun, its subject is implied. Bad 
 form.

hardly to know (when using n, lm), what is your "original post" - 
is it the latest one? I simply have to go to particular message number, 
and then use 'p or 'r there .... I think that for 'lm, I would welcome 
message category/path being displayed on the first line ....

The "original post" you are replying to is displayed by n or nn with 
a > on the left of it. I usually enter the number for the post I 
want to reply to first, which displays in and sets the >. Then I 
use r. I wish there was an rp command...

It's my turn - I only had one unexpected factor, and it doesn't depend 
on Carl's work.

Is this a bug?
blk: [a: 23 b: 34]
to-object blk
** error - invalid argument
make object! blk
== make object! [a: 23 b: 34]

What's the difference between the make and to functions?

I will not use any system, where any of my files resides outside 
my current dir. I hate that, and imo this is fatal design error of 
last century :-)

I just discovered more reasons why you need to be careful with %rebol.r: 
It's more powerful than I thought. The %rebol.r script runs in the 
system context before the user context is created, and before the 
system object is protected. It's almost like having your own host 
code.

that is what I would expect it to do.  this way I can really use 
protect before any real code is run, and I can safely manipulate 
the global context... possibly having custom monitored versions of 
some low-level stuff like networking and I/O... so I could see what 
is going on, and even install safeguards against some external resources.

Does anyone know of any way to detect alt-down and alt-up events?

Regarding alt-up and alt-down, you just check for them in the ON-CLICK 
actor:

	on-click: [ ; arg: event
		if arg/type = 'alt-down [foo]

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

BrianH: re #1210 - "--import path" ... I almost everytime prefer 
the concept of "current directory". I hate systems, which pretends 
to be "installed somewhere", and then, working with stuff in different 
directory, still pretends the current directory is that of user profile 
or installed app. That sucks big time. I always prefer simplicity, 
or at least things to be settable ...

BrianH: thinking about submitting 'Call function for fixes. I gave 
it some thoughts, and I think I am not satisfied with answer, that 
'call will be part of Open Host code - we are waiting for host code 
for 2 years, and there is no guarantee, that we will see it anytime 
soon. I think call should be fixed, or it is big let-down in comparison 
to R2. It messes with console in such a way, that it looks inconsistent, 
and its output can't be trapped easily. It might be a show-stopper 
for some ppl, in regards to R3 deployment. What do you think? Maybe 
it can be improved a bit? We are seening good changes to many natives, 
so why to wait with call for host code release?

Speculating about set- and get- datatypes in relation to:
http://www.rebol.net/cgi-bin/r3blog.r?view=0229#comments


In R2, we have get-word!, set-word! and set-path!. R3 brought us 
get-path! too. Is it a good idea to have things like get-paren! and 
maybe even get-block! and set-block! ?

Carl's set-word! in a block problem could be solved with:

user: [name: "Steve" age: 38]
user/:(age:)


About get-block! and set-block!, today we can set many values with:

set [a b c] [1 2 3]

Why not just write:

[a b c]: [1 2 3]

And a get-block! like:

:[a b c]

should return a block with values like

reduce [a b c]

Just thoughts.

[a b c]: [1 2 3] and :[a b c] , very nice, very rebolish 8)

About set-block and get-block.

If it's only to save the use of SET and REDUCE, i think it's a little 
luxurious.

context [
	foo: fum: none
	set [foo fum] 3
]


'foo and 'fum stays in context with the NONE line. Without it, they 
don't.

To me EEBOL is about syntax, and the get block set block idea seems 
very interesting.

I'm not sure it is. :-) but many things don't seem very useful on 
the surface. I'm still thinking in terms of setting mulitple words 
with multiple values in one operation. I hate picking words out of 
a block, one at a time. It becomes more powerful when you replace 
the blocks with words. Then you can use the same program structure 
to set one-to-many, one-to-one, many-to-one and many-to-many words.

if z s a word, IT gets assigned [1 2]  if z is a get-word, its content 
is assigned to the content [1 2], so in the above, b and c would 
be 1 and 2 respectively.

and what is your :z: ?
a new datatype too, much more confusing to my mind

not, it should just do like in the path notation, get the value of 
the word, and set to that value .

I think I see what you mean when you say a new datatype...  yes, 
it would be a get-set word, but the path notation already makes it 
clear how that should work... and I've used it often

just as get-word and set-word are different datatypes.  this is just 
the combination of both actually, code wise, its probably a one hour 
affaire for Carl, maybe even less.

Geomol, I wrote MAP-EACH and APPLY functions for R2/Forward - both 
required code generation by the function.

Pekr, your disdain of install and user directories will fail on systems 
that are locked down for corporate or public use - too insecure.

I prefer to think that I deduce and induce, rather than lie :)

As long as you track (and preferably state) your assumptions, it's 
not even lying at all.

In a decade of REBOLing, Ive tried to use it exactly twice, and ended 
up having problems, so I created global words instead and forgot 
about it.

I've been mostly writing R3 itself. The projects I want to work on 
require capabilities that R2 don't have, and R3 didn't - until recently.

I've been trying to get R3 in shape to use for my projects, and it's 
been paying off recently (extensions, command!).

Haven't used R3 for anything serious yet.


but now that extensions are upon us, the OpenGL integration will 
allow me to use R3 for a *VERY* serious project.  still need Carl 
to fix the make/copy issue before I can convert most of my cool stuff 
over to R3 (like liquid and globs).

I hope extensions will be in the linux and mac ports shortly.

R2 still pays the bills and works very well for me.

Re ALIAS -- it has several security and other issues.

Enabling it via SECURE is a good way of limiting the inadvertent 
damage it can do....And of drawing attention to its dangers for any 
casual dabbler.

The set-block! datatype would make good sense with functions, that 
return more than one value. In Lua, a function returning 3 values 
can be defined as:

function f () return 1, 2, 3 end

and be called like:

a, b, c = f ()


Now a, b and c holds the values 1, 2 and 3. In REBOL we have to write:

set [a b c] f

It would maybe be nice to be able to write:

[a b c]: f

I'm working with a long time REBOL programmer these days. We discuss 
the language now and then. One thing, we discuss, is how the minimalistic 
syntax can make REBOL hard to read. We can use parenthesis for arguments 
to functions, but we rarely do it. We could write:

insert (back (tail (series))) value

but a REBOL programmer would just write:

insert back tail series value


Even if we use parenthesis, REBOL requre different parenthesis notation 
than other languages. The above code in C would look like:

insert (back (tail (series)), value);

And C programmers often don't write the code this way with functions 
within function calls. They use to write:

void *pointer = tail (series);
pointer = back (pointer);
insert (pointer, value);

or something.

This, I think, is one of the huge benefit of REBOL. To be able to 
combine words into sentences, that actually makes sense to read and 
understand. I don't know of any other language, that can do it this 
good.

steve, belive me... there is ABSOLUTELY nothing in common between 
relavance and all the db you are used to .  absolutely nothing.

guys, what is Relavance price level? Is it suitable for normal guy 
to play with? Or just for big and specific projects?