World: r3wp

Which exposes a nice bug in A110. There is no longer an issue! type 
which can be used for arbitrary base literal numbers.

So to-hex is actually rather misleading.

(And should probably be removed.)

First of all, we never had a type that could be used for arbitrary 
base literal numbers, except the string types.

Next, TO-HEX should probably not be removed, but it should return 
a string! instead.

how would that differ from to-binary?

A binary is only formatted with hex characters (if the binary-base 
is 16). A string would actually containthe hex characters themselves.

So to-hex would be shortcut for enbase/base to-binary num 16. Rather 
useless.

But my, why not.

I expect that TO-HEX is a formatting function that is definitely 
not useless for web work, for example.

That usage would require that we keep the issue-generating feature 
though, even if we couldn't convert back easily.

Or you stop being lazy and add the # manually.

TO-HEX is a convenience function. Being lazy in a common situation 
is the whole point to convenience functions.

Being lazy means that there's no point to this discussion.

a nice bug in A110
 - And which bug is that, exactly? Has it been reported?

Nevermind.

Trying to find out the bug is why I spoke up in the first place. 
I am trying to get the bugs reported so they can be fixed, as appropriate. 
It's amazing how often bugs go unreported and thus unfixed.

No bug. TO-HEX works as designed. Nothing to see here, move on people.

Ah, OK then. The change in issue! has brought up a lot of issues, 
so to speak. We are hoping to collect them all and come up with a 
set of tweaks and enhancements that can make things work. It should 
be possible to make them work a lot like they did before, with only 
minor changes (like being non-modifiable). You can replicate a lot 
of the behavior of a series type in a non-series type by simply having 
the series functions also work on the other type, as closely as appropriate. 
Good examples of these are SELECT and APPEND on objects and maps.

I should have given the example:
    to-binary 33333333

As the above discussion suggests, creating an issue! is a bit of 
a dead end in this case. A binary! is much more usable.....That is 
true in R2 as well as R3.

A function like:                                                 
                              

                                                                                               

[code]                                                           
                              

func [x] [subtract 6 x]                                          
                              

[/code]                                                          
                              

                                                                                               

strikes me as being a lot like an anonymous function or lambda   
                              

expression. Is that correct?                                     
                              

                                                                                               

How would I execute the above function from Rebol CLI? I keep getting 
                         
error messages, so I'm not getting a piece of the puzzle.

>> do func [x] [subtract 6 x] 1 
== 5
>> apply func [x] [6 - x] [1] 
== 5

I'd say, yes, those are anonymous functions - in the sense that they 
aren't assigned to a word. But in the stricter sense of a "named" 
function, REBOL doesn't have that concept at all. You can assign 
a function to one word, some words, or no words at all.

Easy to see for example in code so simple as

>> a: b: c: func [ ] [print "What's my name?"]
>> do [a b c]

I consider them to be the same as anonymous functions/lambdas, due 
to how I was introduced to that concept in Scheme - and a similar 
ability to have multiple words/names reference the same function, 
as ChristianE shows in Rebol:
(define foo (lambda () (print "Hi"))
(define bar foo)

@Christian E. Thanks for the examples! In the first one, it just 
dawned on me that perhaps Rebol is a stack-based language - a bit 
like Forth et al. Didn't you just put "5" on the stack, then the 
"apply func" simply pops the the stack for its parameters?

@Izkata Ithought that I smelled a lambda - maybe a la Rebol - but 
close enough :)

REBOL has a stack, like most programming languages, but no explicit 
manipulation of it. DO function! just evaluates the arguments. One 
of the many gifts of using an interpreted language.

@Brian So Rebol is not a stack-based language like Forth, or concatenative 
languages, like Joy, Cat etc?

Nope. I haven't used the others but like Cat a lot. Too bad the author 
has (temporarily?) abandoned the project.

@Brian OK! I can get rid of _that_ mindset in trying to understand 
Rebol :)

REBOL is more like an interpreted Lisp, with a Forth-like direct 
binding model.

@Brian kinda like newLisp, then - which I have dabbled in, and liked

newLisp is more compiled than REBOL, and has dynamic binding, which 
is a completely different concept.

Unfortunately, it is a bit hard to explain direct binding to people 
already familiar with lexical or dynamic binding.

@Brian I hear you! Please don't try ;) now now. I'm still in the 
KISS mode as far as Rebol is concerned

BTW, KISS refering to _me_  NOT you

We all have our moments :)

In the simple phase of your REBOL education, all you need to know 
is that we have something called "direct binding", where words have 
direct references to their values, but that in most cases it acts 
like lexical binding because we fake it. So write your code as if 
it's lexically bound until you run into problems, then come back 
and be new again for the next level :)

Cool! :)

I run into these next levels pretty often, usually after a conversation 
with Carl or Ladislav. It's no problem to be new again :)

This looks simple enough to be readable just finely:

http://blog.revolucent.net/2009/07/deep-rebol-bindology.html

One thing that attracted my attention in the article:


...interesting fact about REBOL blocks: By default, their evaluation 
is deferred.

 - not being a native speaker, I do not know, whether it means the 
 same as:


...interesting fact about REBOL blocks: They are not evaluated (i.e. 
understood as 'data', not as 'code'), unless an evaluation is explicitly 
requested.

(but that is just nitpicking from me, the text is fine)

It's that terminology bug all over again. Good point, and good article.

Well, about binding in Rebol,  it's not that hard to understand.
The context of any word is a hidden property.
Meaning it can be changed at any time.

It is very hard to find the best terminology to describe the properties 
(like "evaluation"), exactly because they differ from the common 
cases in other languages.

yes to "The context of any word is a hidden property.", but "it can 
be changed at any time" is a bit complicated by the fact, that it 
is "immutable", meaning, that you create a new word with a different 
context, when you want it, instead of changing the original

if its an internal (silent) reconstruction we don't bother.
the behavior acts like a change.
a: [obj]
bind a context [obj: 1]
do a
== 1

From my point a view the serie A has bit been modified.

*From my point a view the serie A has not been modified.