AltME groups: search

If you want a free OID, you can apply for one from IANA http://pen.iana.org/pen/PenApplication.page

I am able to bind a block to a function even when the function is 
not running, so pretending that it is impossible is just that: pretending.

Anybody can pretend whatever he likes to pretend, but I do not understand, 
why a blind faith is required from me.

You can't have the words in functions lose their bindings once the 
function returns

 - aha, sorry, I misunderstood, the fact, that I am not a native speaker 
 applied

What I wanted to demonstrate was, that:

block: [a]
g: closure [a] ['a]
f: func [a] ['a]
; this works
bind block g
; this does not work
bind block f
; but it can be replaced by this, doing what was requested:
change block f


, i.e. there is no reason why the operation should not work, except 
for the fact that somebody does not want me to do it (ineffectively, 
since I demonstrated, that it can be done anyway

Thus, a malicious user can do it, while, for a "good intent" it is 
"dead" because the workaround is slower than the native way

I'm sure it was all a misunderstanding :)

It was a misunderstanding. Everything I said derived from something 
you said that sounded like you wanted function words to be unbound 
after the function ends. It is now clear that you don't. Ignore the 
rest.

It's a Core-only script, so the changes to create a version that 
runs under R3 (or even runs under R2 and R3) may be fairly simple.

Ladislav and I have both documented our early efforts to convert 
scripts. If someone does convert JSON.r, that may uncover other useful 
conversion guidelines.
   http://www.rebol.org/art-display-index.r?a=R3

Hmm, I think I have a json.r adapted for R3 somewhere.

map! with string keys, mind you. But map! won't show values assigned 
to none, so if you use map! you might want to use a 'null keyword 
instead of none for the null value. You could use object! instead, 
but then you would have problems with some keys not getting through 
TO-WORD's character restrictions.

One thing will definitely be easier though: JSON and Javascript define 
that they have Unicode source, but don't have a way to specify the 
encoding (they are text standards, not binary). They can be handled 
easily in R3 once the source is converted to a string though, since 
that conversion will handle the encoding issues. In R2 you'd have 
to either stick to ASCII data or use Gabriele's text codecs and then 
parse the UTF-8.

Hm, does that differ from hash!? I can do a find/case on a hash!

That's a problem

I'm using hashes to cache directory contents. They need to be case 
sensitive to support Unix file systems. Now I have a problem with 
porting to R3

The map! type is not a direct replacement for hash!, it is a different 
type that serves the standard purposes that hash! usually served 
in R2, where it was mostly used in the way that map! can be used 
now. As a related benefit, object! can also be used in ways that 
hash! used to be used: SELECT and APPEND work with object! and map!.

I consider not having a key/value datatype which can store external 
(non-REBOL) data using a sensible internal (REBOL) type a major annoyance.

Case-insensitive key-value stores are not uncommon. And we do have 
a workaround.

It's not that big a deal to use binary keys for map! because most 
data is binary when it comes into R3, so it's just a matter of *not* 
converting it *from* binary.

Btw, in a comment to #1494 Andreas brings up the possiblilty of another 
map type with a different, case-sensitive hash function. That would 
be a possibility, whereas #1315 would not, not would #1437 where 
it was suggested that case-sensitivity be an option.

That sounds a likely explanation, thanks.

From a quick look, it doesn't seem that it should be too hard to 
convert the JS to R3 on Big Endian systems.

Are there are practical differences between these two R3 ways of 
extending an object?
    obj: make object! []
    extend obj 'a 1
    bind/new 'b obj obj/b: 2
    probe  obj
     == make object! [
              a: 1
              b: 2
        ]

Extend is a mezz, so that much be slower.

And I always try to avoid GC overheads due to excessive  usage of 
'reduce


Thats why I think bind/new is more capable especially, this form:
>set bin/new 'b obj 2
instead of:
>>bind/new 'b obj obj/b: 2

Besides the readability/performance trade-off, things also start 
to differ when non-true? values are involved:
    obj: make object! []
    extend obj 'a none
    extend obj 'b false
    set bind/new 'c obj none
    set bind/new 'd obj false
    print mold obj
==>
    make object! [
        c: none
        d: false
    ]

(Which probably is a bug in EXTEND.)

Hum...
Seems not a bug, but deliberate.

EXTEND is a wrapper for APPEND....So are there any practical advantages 
in using BIND/NEW rather than APPEND ?
    append obj [c: 3]
    == make object! [
        a: 1
        b: 2
        c: 3
    ]


I know right  now there are some differences when messing with PROTECT/HIDE, 
but there are many  CureCodes to go before we'll know if those differences 
are for real.

I like the SET BIND/new trick. There has already been code in the 
mezzanines where such a trick would come in handy, but it had never 
occurred to me. Thanks Steeve!

The practical advantages of the SET BIND/new trick as opposed to 
APPEND is that you don't have to REDUCE a block to be appended. The 
point to the IF :val guard in EXTEND was to screen out false and 
none in GUI code, but that is likely no longer necessary. There was 
a blog where it was suggested that EXTEND be rewritten to work differently, 
but I think that various natives were enhanced instead. EXTEND is 
now a little anachronistic.

Real
 natives should be a bit faster still.

Thanks for the EXTEND vs APPEND vs BIND discussion, guys. It can 
be useful to have different mechanisms that have their own default 
behaviours.


One use of BIND/NEW is that it allows words to be unset when an object 
is created:


    obj: context [bind/new 'word self]   ;; this works, and WORD is UNSET!

    obj: context [word: #[unset!]]       ;; this does not work
    * Script error: word: needs a value
    * Where: make context
    * Near: make object! blk

I just feel you're overdoing it a bit. If you were to follow that 
reasoning through, the conclusion would have to be that REBOL has 
negligable overhead over C. Indeed, that's what some people claim 
on the web because they heard it somewhere in the community, and 
that's how REBOL people become known to the outside world as lying 
or delusional

Among dynamic languages, REBOL is slow. Not the slowest, but slow. 
Not that this matters in practice, but that's a whole other set of 
myths

Perl can also have the same speed as C under similar circumstances. 
It all depends on how heavy the native functions that you are calling 
are. But unlike most dynamic languages, REBOL is optimized for hand-optimization 
and doesn't have a semantic model that even vaguely resembles that 
of C code, so you can't just transliterate code from another language 
to REBOL and expect to get the same performance. REBOL is *really* 
slow for the type of code that requires a compiler to be efficient, 
but it can be *really* fast at the kind of code that other languages 
have a lot of trouble dealing with at all because they have to manually 
implement a lot of stuff that REBOL has built-in in native code.

It is not a myth that REBOL is fast. It can sometimes be misunderstood 
though, because people who are familiar with other languages will 
try to write code in the style of those other languages and expect 
it to be fast. REBOL code written in REBOL style for tasks that REBOL 
is suited for can be very fast.

I think that the outside world would consider me delusional for choosing 
a language that isn't compiled, or (worst sin of all) doesn't have 
a C-like syntax. Most people think hand-optimization is insane in 
the modern world. And in some circumstances (and for many programmers) 
it is a bit crazy. But when you already can hand-optimize and understand 
the semantic model of the language you are using, and how it is different 
from other languages, then it's not so crazy. Differences matter. 
And I only use REBOL where it is appropriate, at least in comparison 
to the overhead of learning another tool.

Rather than focusing on the details and claiming REBOL is fast in 
details, I would typify REBOL as a slow language that allows you 
to write fast algorithms

It goes the other way too: If you try to write REBOL-like code in 
most other languages then you will run into a wall. For most you 
will need to reimplement most of the natives before you can start, 
if it is possible to do REBOL-like code at all (often not with parsers). 
And when you do manage to get that code running it is often slower 
than REBOL code because of the optimization its natives have gone 
through.

There are tricks that you can do with dynamic rules that are provably 
impossible for static rules to do (patterns that static rules can't 
recognize). PARSE is a superset of the PEG model, while Perl 6 rules 
are a superset of recursive descent (LL), and there are patterns 
that LL can't handle that PEG can.

There's a lot in this world that is kept from Wikipedia...

There are a lot of tricks that you can do in REBOL's DO dialect as 
well that can't be replicated in a compiled language without using 
self-modifying code. And vice-versa as well. Tradeoffs. But once 
you choose interpretation then you can optimize the language semantics 
to make that really efficient. That is why half of what a compiler 
does is done by LOAD, and optimized REBOL code looks a lot like what 
the other half of a compiler does. That is why REBOL DO is more comparable 
to one of Scheme's macro systems than it is to Scheme itself.

Exactly: REBOL's tradeoff is that it's a slow language that allows 
you to write fast programs

R3's DO dialect can be slower than compiled code for certain code 
patterns, but faster for others, depending on the compiler and language 
you are comparing it to (many dynamic languages were slower for a 
lot of code until recently). But you can make things a lot faster 
if you stop thinking of REBOL as being a language, and start thinking 
of it as being a library of native functions and datatypes, with 
a variety of high-level scripting languges built in to script that 
library, and some built-in functions written in those scripting languages. 
Plus you can add your own libraries and scripting languages if you 
like. Looking at things that way is the first step to becoming good 
at hand-optimizing REBOL.

R3 had to drastically update PARSE to catch up with Perl 6's rules.
 - that is not an objective, that is a statement, as I see it

That's true, "drastic" is a bit of an overstatement. Almost(?) everything 
you can do in R3's PARSE you could do in R2 with dynamic parse tricks, 
DO dialect tricks or a preprocessor. But for the average PARSE user 
who can't understand the advanced workarounds the new capabilities 
are just that: new. If you look at idiomatic R3 rules compared to 
their R2 equivalents then the changes at least *look* drastic. Certainly 
different enough that for most people PARSE is quite a bit more powerful.

I'm sure that you had other objectives as well when you got involved 
in the most recent parse project 6 or 7 months after it started. 
Were you involved in the first round of parse proposals about 6 years 
ago? I remember Gabriele making a page for them after they had been 
discussed for a while, but not whether the initial discussions were 
here or on the mailing list.

When I look at the parse project, I see these changes as very useful:


1) the FAIL keyword - has been used as an idiom and proposed before 
the parse project started

2) the NOT keyword - has been used as an idiom and proposed before 
the parse project started
3) the AND keyword - a new and useful addition

4) the QUOTE keyword - used as an idiom and proposed before the parse 
project started

5) the REJECT keyword - a new and useful addition allowing to stop 
a parse cycle with a failure

6) the IF keyword - used as an idiom and proposed before the parse 
project started


As far as other improvements are concerned, I do not find them useful, 
and do not plan to use them, in fact. (YMMV)

I agree Steeve, and use PARSE RETURN a lot in adhoc code. I use all 
of the new addidions quite a bit, except for REJECT, which I had 
forgotten existed (don't remember the proposal for it).

rebol.net is up again, at the moment. In case it is done when you 
try to follow the "copy semantics" link, Yahoo has a copy cached.

I ran out of memory using R3 because of a huge map!. I was doing 
a Chinese social-network-graph analysis. If R3 supports 64-bit OS, 
I will have the 64-bit HW, 64-bit OS, and 8 GB RAM  ready. Too much 
data to analysize, too less memory.

Nevertheless, there may be a problem with a map! hash limit, so, 
I am not sure, that just a simple solution would suffice

We already resolved that problem earlier - maps rehash with a bigger 
limit when they run out of room now. All we need to do is provide 
Carl with an appropriate number of items to hash, where Ladislav 
would know what I mean by appropriate.

Sunanda: RANDOM of a series in R3 modifies the series and returns 
a reference to the modified series.

And yes, that is an incompatible change in R3 over R2. RANDOM in 
R2 was not modifying a series argument.

I expect that it was because we are trying to make R3 more efficient, 
so it is left up to the developer to decide whether a copy is appropriate 
rather than just assuming it is. But yes, incompatible, and without 
a change in function name, just like we rejected for UNIQUE and the 
other set functions. Oh well.

Actually a good example of how arbitrary those "efficiency" decisions 
can become.

It's not so bad when they are documented, at least in CureCode, but 
that particular change seems to predate CureCode by at least a year. 
And predate PROTECT, hence the bug with that.

I understand that there are limits to how efficient you can make 
copies. Making a copy is itself an inefficiency, since efficiency 
isn't just a CPU thing, memory usage matters too. However, this might 
not work as well when we are making a lot of series non-modifiable 
not just for protection, but in theory to make them sharable without 
conflicts. I'll put my concerns in the ticket.

Of course his speed claims are relative. I added some reaction to 
show how to extend objects, but studying JS prototype documentation, 
I wonder if something like that would be possible to simulate using 
REBOL? I know that we can have sub-objects shared/referenced. But 
JS Prototype is not just that - it is not about classes. It is more 
about the ability to have linked objects, and when querying a value, 
it is being looked-up down the road:

obj/value 


If 'value is not found in the object, then JS looks down to obj/prototype/value. 
And 'prototype here can be referenced from different constructor. 
I think, that it is similar to find/deep, but with simple/single 
accessor.

Why do you bother to try to help Tutorial translate a non-working 
code example?

OK, but then it is a trivial example, as I see it

Where in his original code did he do such a thing?

It looks like a question, based on the object model of JavaScript. 
REBOL objects don't have "children" in that way, as we don't do delegation, 
just prototyping.

WhatIsYourSex has a function that is bound to the object *before* 
the word 'sex is added to it, so the 'sex it is getting is not person/sex. 
It only works for objects derived from it. Unless I missed Oldes' 
point, and only working in derived objects was intended.

OK, so, generally - a nonsense, that actually works the way he wants 
it to, so what?

I make a distinction between "doesn't" and "can't" when it comes 
to understanding. Only close-minded people "can't".

That can be done in REBOL, but it requires planning for it ahead 
of time and a bit of explicit redirection. This is done in the R3 
GUI.

Although I use above from time to time, I don't like heavy class 
based code as I consider it very unreadable.. I've seen many such 
a (ActionScript) projects.

GUI frameworks tend to be a good place to use class-based or delegation-based 
OOP, as we do in the R3 GUI.

And to a lesser extent in VID as well.

The above is wrong, the 'proto must be a pointer to the parent which 
you used to make the object.. in my REBOL code above it's the person 
object.

I really wish that JS had done a better job with its prototype model. 
Self and NewtonScript were better.

we could have something like:
new: func[obj /local newObj][
	newObj: make obj []
	extend newObj '__proto__ obj
	newObj
]
p: new person


but as a native so as Pekr said, if value is not found in the object 
itself, it would look in the parent.

One could simulate a simple delagation behavior if Rebol had an intrinsic 
mezz when and error is processed.

So that, in the intrinsic do-error, one could discard some errors 
and return a useful computed value in replacement.
See what I mean ?

However - I see it nearly as a coiccidence, that obj/nonexistant 
does not return none. IIRC, in some other cases, for the R2->R3 transition, 
we decided to return none instead an error ...

Basically, you want message-not-defined from Smalltalk and Self (I 
know it's got a different name, bear with me).

Pekr, It's strange only because it"s a new paradigm ;-)

we are now apparently close to the object redefinition, maybe we 
could change a semantic, but not sure we want that :-)

We don't have to make everything act like OOP languages. If you are 
looking to other languages for ideas for REBOL, OOP languages are 
generally a bad choice (says the guy who wrote FUNCT based on ideas 
from Ruby).

Steeve, it's not a new paradigm, it's a paradigm from 70's-80's OOP 
languages. And it works for them :)

It's not hard to implement, but it's *slow*. There was more than 
a decade of research before they figured out how to compile and optimize 
languages to make messageNotUnderstood efficient, but it is still 
not that fast. And we don't even have compilation. Optimization of 
Smalltalk-like languages requires static analysis to determine when 
the message *will be* understood, in order to remove calls to the 
dynamic dispatcher.

(I wrote an implementation of a Smalltalk-like language back in the 
90s)

I don't know if the "slowish" argument is applicable in the Rebol's 
world.

I would limit the use cases to objects construction only, so that 
the "slowness" whould not be that much a burden.

We don't have the option of using compilation or static analysis 
(except in dialects with more overhead). REBOL's speed depends on 
direct binding. We could (and can now) use path-based dynamic lookup, 
even if it's slower, and can refer to fields that weren't there when 
our functions were created through that notation. We can even do 
a version of messageNotUnderstood using IN tests and accessor methods. 
But remember that this:
    a
is faster than this:
    self/a
which is faster than this:
    either in self 'a [self/a] [something-else]


And "something is better than nothing" is not a factor, because REBOL 
is the way it is for really good reasons, and because the "nothing" 
is something we can do easily already.

DO of string! can be slow, but DO of block! is much faster. It was 
a tradeoff to increase the overall speed.

We do miss typical OOP facilities as being able to hook into init, 
pre-init, post-init, access phases ... E.g. Visual Objects I used 
in the past define:


You can prevent a runtime error from occurring when an
instance variable 
name is not found by defining methods called
NoIVarGet() and NoIVarPut(). 
These methods, if present, will
be automatically invoked whenever 
an instance variable cannot
be found. They are called with the instance 
variable name as a
parameter, in the form of a symbol and, in the 
case of
NoIVarPut(), with the value to be assigned as a second
parameter. 
This feature is useful in detecting and preventing a
runtime error 
and also for creating virtual variables
dynamically at runtime.

Fortunately we have a couple types that are good at creating variables 
dynamically ar runtime: map!, and with a little more work object!.

BrianH: if you don't have anything better to do, you could read one 
chapter from CA-VO language - chapter 25 - Classes, Objects, etc. 
I used it some 12 years ago, so I don't even properly remember it. 
But it allowed some nice tricks, as having access/asign methods, 
where you just used normal assignment operator, and if your child 
overrided the variable with virtual method, you still did not need 
to change the source code, you still used asignment.


What was also handy was various types of visibility - protect, hidden, 
export  .... in regards to class, inherited classes, and instantiated 
objects. I wonder if possible new object specs could work more like 
a modules, having exports too, etc. But maybe we don't need to complicated 
the stuff further ...


In case you would be interested - http://www.cavo.com/support/manuals/vo25pg.pdf

It's always amazing what people will do to avoid calling a function 
:)

I'm wary of adding mezzanine overhead to assignment, even set-path 
assignment, having seen the maintenance nightmare that such tricks 
cause (having worked for years as a developer using languages with 
"properties"). Still, more and more we need to integrate with APIs 
built for languages with "properties" (like Objective-C and .NET). 
Utypes would be helpful for that, and I have advocated their use 
for just that purpose; particularly .NET, where there is a theoretically 
compatible syntax and no efficient C equivalent API like there is 
for Objective-C dispatch.

I understand the desire to unify assignment and function calls, but 
it mostly leads to code that can't easily be understood. Having to 
read the entire source code of Delphi's VCL more than once just to 
understand what is supposed to be a simple assignment statement (this 
happened) is an inevitable consequence of this approach, eventually.

Objets language are a mess because of that.
We all know why we real programmer prefer C and hate C++ ;-)

And you can screen function calls for security (we do this a lot 
in the mezzanines). It is much more difficult to screen assignment 
statements with other side effects.

You'd be surprised at how easy it is to add a keyword to make module! 
syntax. Having done it once, doing it again was mostly copy-paste 
of the first keyword's code, and figuring out the interactions and 
priorities. And the code is (intentionally) small and simple.

Can someone tell me the current state of R3?  I'm a bit confused 
as I don't keep up with the news enough.  Can we do graphics yet? 
 What are we looking at from a performance perspective, etc..?

R3 Core is quite usable, but it still heavily depends on your needs 
(some areas are rougher than others). Basic graphics (draw) work 
on Win32 for hostkit builds. Performance on a script level was comparable 
to R2 (sometimes R3 a bit slower) for my uses, last time I did some 
measurements.

In many cases R3 is a lot faster. The whole balance of optimizations 
was shifted.

Automatic delegation: sorry, that is not a question for me. I never 
told automatic delegation was bad.

What is bad, though, is writing a code sample in a question, obtaining 
a translation in Rebol working the same way, and saying: "Your code 
doesn't reflect the same intent as my js code..." - it is enough 
that he obtained a working translation of his code, if his "intent" 
was different, he should have written the code in accordance with 
it, this is exactly how it should *not* be done.