AltME groups: search

In the posted build, functions are fixed, but closures and loops 
aren't yet.

If my last tests are more understandable, then I am able to simplify 
the #1549 wording by removing older text, etc. keeping and explaining 
only the newer tests

BTW, I wanted to edit the TO-BINARY function description in R3 documentation 
to explain the "network bit order", but did not succeed; while I 
edited some parts of the documentation, now I am unable to log in, 
and have no idea why (posted a private MSG to Carl in R3 chat, but 
he may have missed the message?)

Sure. Btw, your philosophical tests pass now, at the expense of other 
bugs continuing, including the return of #447. The practical tests 
show the errors in question. Basically, #447, #1528 (for closures), 
#1529 and #1552 are still problematic.

(From chat #7216) Some tests pass, others fail. It's a good start.

- The tests in the example code of bug#1549 pass (Ladislav's philosophicals)

- The practical tests don't. In particular, bug#447, bug#1528 (for 
closures), bug#1529 and bug#1552 are still problematic.

- We need a SELFLESS? function (or whatever it should be called) 
to resolve the main downside of the #1549 approach, and we need it 
for the a98 release.

Here are the practical tests that need to pass:

; Objects
ob: object []
print same? ob do bind [self] ob
print same? ob do in ob [self]

; Functions
ob: object [f: func [/x] [do bind/copy [self] 'x]]
print same? ob ob/f
; Can't use the context after the function returns.
; This is not a side effect of Ladislav's proposal.

; Functions with a 'self parameter (#1528)
ob: object [f: func [/self] [do bind/copy [self] 'self]]
print not same? ob ob/f

; Closures (#447)
ob: do closure [x] [bind? 'x] 1
print 1 = ob/x
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Closures with a 'self parameter (#1528)
ob: do attempt [closure [self] [bind? 'self]] 1
print 1 = attempt [ob/self]
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Closures shouldn't bind 'self unless it is a parameter (#447)
print same? self do closure [x] [self] 1
print not same? self do attempt [closure [self] [self]] 1

; Loops (#1529)
ob: repeat x 1 [bind? 'x]
print 1 = ob/x
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Loops with a 'self variable (#1529)
ob: repeat self 1 [bind? 'self]
print 1 = attempt [ob/self]
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Loops shouldn't bind 'self unless it's a variable (#1529)
print same? self repeat x 1 [self]
print not same? self repeat self 1 [self]


See also #1552: There needs to be a way to distinguish selfless contexts 
from selfish contexts at runtime (a SELFLESS? function), and selfless 
contexts need to MOLD into DOable syntax (perhaps a different datatype, 
or a flag).

New test build, all of Ladislav's and my tests pass. Success, and 
agreement, yay!

And your version is more secure than mine, which used DO rather than 
FIRST.

No, that absolutely matters, because this is a mezzanine that won't 
be turned into a native unless it gets used a *lot*. Carl is convinced 
that the function isn't critical, so we have to make due with a mezzanine, 
if he puts it in at all. And I will insist.

(still not working here, and I downloaded again to make sure

It only works in the test builds. And that was one of my tests, so 
if it doesn't pass I will be surprised.

There is no special context! or selfless! type, selfless contexts 
are just regular objects with an internal flag (that you can't set 
at all) switched. They display like normal objects, don't survive 
a DO MOLD conversion, and are otherwise undetectable. It's a hack. 
Congratulations!

See, I told you that we can live with the limitations :)  But only 
if there is a built-in way to detect the difference. Because I write 
code that has to be secure from attack, and 'self not binding every 
once in a while is a major attack vector that I can't accept, so 
we need a way to test contexts to see if they are safe.

The SELFLESS? function would be even more useful in R2, though it 
would need to be rewritten in it. The optional 'self field is even 
less secure in R2, and causes a lot more problems. The SELFLESS? 
function would be needed there to make conditional code for formatting, 
iterating, reflection, ...

A great discussion with an even greater outcome. I'm hardly able 
to follow, but I love the pure elegance of the proposed solution 
with selfish objects and selfless functions and alike. I'm deeply 
impressed by the security implications your drawing and in general 
all the situations both of you, Ladislav, Brian, with the help of 
Carl and Gabriele, are considering when it comes to answer a question 
which is easy to ask but hard to answer in a satisfying way. So, 
first of all, this is just a note to let you know how much your work 
is appreciated. 


On the other - off topic - hand, it has made me curious especially 
for the security concerns one has to deal with in REBOL. Not the 
kind of security issues you always have to deal with like SQL injections, 
everything related to proper encryption and proper password handling, 
but the kind of rebolish security you have to deal with when, let's 
say, executing arbirtray code. What are the appropiate measures you 
have to take in order to protect yourself from harm, that kind of 
stuff. Are there any documents on this subjects somewhere beyond 
Ladislav's articles?

And R2 has a host of security problems that R3 doesn't:

- Ordinal functions overloaded as reflectors, which makes R2 impractical 
to sandbox.

- Reflectors return the original body of a function rather than an 
unbound copy like R3, which lets people hotpatch code.

- Typespecs for functions have runtime overhead, so people don't 
use them as often as they should. They are free in R3.
...

Oh, and don't get me started (again) on R2's self field :)

Thanks, Brian, all very good points. I hadn't even realized how BODY-OF 
now returns an unbound copy, and of course I patched functions in 
R2 here and there. Half of the points I probably wouldn't have come 
up with, especially the get-word argument is interesting. I've never 
been comfortable with not beeing sure why guru code looks very different 
from the naive approach without being able to say for sure *why* 
it looks different ... I once learned a lot about BINDing issues, 
THROW and CATCH when writing some specialized loop functions, but 
I've never considered them "done" in the sense that they don't break 
on the slightest misbehaving client code.

Brian: I'm pretty sure that Carl is right and noone will ever need 
selfless?

It may be hard to get that perspective after 10 years of R2 though 
- it is an inherently insecure language in many ways. Most of the 
core changes of R3 relative to R2 are for security, and specifically 
to make running of untrusted code a possibility.

Maxim, the mezzanine will be fast enough, and secure enough. It doesn't 
need to be native in R3 to be fast and secure.

It's just one line of code, and not even a complex line :)

Is it by design that "set" functions like UNIQUE, UNION, INTERSECT 
and others don't allow blocks containing values of type NONE!, UNSET!, 
PAREN! and maybe others (all of which R2 happily works on)? It's 
not that the docstrings or docbase did tell that it is intended behaviour, 
but at least they show some consistency in their behaviour, so I 
wasn't sure if this is something to curecode?

Struct! in R2 is great, especially to optimize (memory and speed) 
data conversions.
I give my consent :)

About remove-each in R3, I dislike the new given output (numbers 
of values removed).
What the point to discard the most powerful feature of Rebol ? 
- Chaining operations on series.

Besides, To count how much values have been removed is trivial to 
do and a very rare use case.

Pekr, note that he said "I think we need to add back to R3 a struct-like 
datatype (or function.)". I think that the function option would 
be more powerful and less awkward to use.

Either way you are discarding a feature. The question is whether 
the remove count or the chaining is more important. You and I seem 
to prefer the chaining, Carl seems to need the remove count (for 
reasons not given). Between the two, the chaning is easier to work 
around not having than the remove count is.

Yes, protect bugs, but not for a98. It's actually been good to put 
them off: It's given us more time to really think about them. Security 
is a hard topic. Unfortunately, my proposed changes are flexible 
enough, but will need a lot of chaining to get the right pattern 
and recommended chaining patterns will need documenting.

Graham, you would need to either refine the code or the typespec. 
That's not right for most types, and not safe for function types.

It's good that you have that function then. I prefer to think that 
an empty series or a series full of spaces is something, and that 
none is nothing.

and a series of spaces is not something

I wonder what the effect will be on function! and closure! functions, 
whether there is body copying. It seems like a really interesting 
way to do optional arguments to commands though.

And add more datatypes to the spec as testing determines them to 
be safe.

If I understand new proposed syntax correctly with my very limited 
REBOL brain :-), we will be probably able to "reassign" functions 
(not only), providing shortened argument block, hence dissallowing 
rest of arguments, and binding such new function to the body of the 
original one, so creating some kind of wrapper around the original 
one?

Pekr, that's almost it, but not quite:

- All functions are a wrapper around a spec and a body, though the 
body of natives is internal.

- You will be able to make a new function derived from an old one, 
with a new spec, body or both, or just the same.

- When the spec isn't changed in the derived function, it will likely 
get a copy of the old spec, not the original.

- When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.

- When you make a new native function (action!, native!, command!, 
maybe op!) it will call the same code, not a copy.


We'll have to see what changes we can safely make to specs without 
breaking functions. Right now we know we can change doc strings and 
typespecs, but we'll have to see if we can change argument ordering, 
naming and number. I expect that more changes will be possible with 
REBOL functions than there are with natives, due to the new function 
getting and rebinding its own copy of the code block. And natives 
might need some more internal type screening in order for this to 
not be a problem.

is es5 you can derive functions and manipulate them...

Ah, I must look into this. I knew they were first-order types from 
the beginning, but not that the code and specs had themselves become 
data.

one thing that ES5 does which I still long for in REBOL is how they 
have opened up the accessors, for everything as well as management 
of object keys, and member attributes like writeable, replaceable, 
public, etc.

Because it has to be rebound, and because inline series data is modifiable.

And you have an optional mechanism: You can derive a new function 
and replace the references to the original. If those references aren't 
protected.

Pekr: "when is A98 going to be released?"

I don't know. I thought soon, but then Carl went wild with fixes 
and core semantic changes like the 'self stuff. It may still be soon, 
since those are done. It depends on how many more magic tricks Carl 
wants to pack into this release.

There is an ongoing discussion about REBOL3 objects and accessors 
ongoing into the "Other Languages" section. BrianH and Maxim have 
discussed and a proposal has been made at http://www.rebol.net/wiki/Objects_enhancements.

This proposal is only of their side and we request the other GURUs 
to partecipate to build up other POV.
Then the proposals will be submitted to Carl.

Please partecipate ! The object  heart is open right now and in the 
hands of Carl ! :-)

I see it as a matter of priorities, and declare, that it is not my 
priority.

Ladislav,  we see Carl focusing on some or some other part of REBOL. 
This time he is working on the object part of the language. It would 
be good to have your (and the other) respected opinion about this 
topic now. Maybe we will be able to close this topic which has been 
opened in the blog in the distant year of 2006.
However, no one is forcing anyone to do anything...

I would especially like to see is the problem of Throw, Break, etc. 
solved, and the problem of function Return (comprising other issues) 
solved.

Don't worry Ladislav, the Parse project took a few months to sort 
out before there was a need to involve Carl. It should take some 
time to just search through the blog and comments for ideas (minus 
the inappropriate ones of course).

And, maybe surprisingly, I really do not feel an urgent need to solve 
this, being pretty content with the current state of affairs

And that few months was with just two main participants, some historical 
suggestions and a few helpful souls. The object debate would affect 
more people.

I don't mind the current state of affairs either, as the current 
(post 'self debate) object model (including the PROTECT tickets) 
works great, and is more general than object models with explicit 
support for classes and properties. It would help if you could look 
over the PROTECT tickets though, Ladislav.

I admit that i participated only a little in the PARSE debate cause 
brian did such a great job at doing all the PR about it, and because 
I was mostly in agreement with all proposals.

I still wish we could use functions as dynamic rules.

The PROTECT tickets to look over are #1014, #1015, #1141, #1142, 
#1143 and #1148. Though in theory SECURE 'protect (#1143) was implemented 
already, the actual setting that it is meant to secure (#1141 and 
#1142) has not been implemented, so there's no way to test it.

BTW, although I had the access to the R3 docs, and having edited 
some parts (Random e.g.), now I cannot log in. Even though I posted 
Carl a msg in R3 chat, the situation looks unchanged, so I cannot 
edit the TO-BINARY to finish the #1539

Keep in mind that accessors aren't the onlt thing under discussion. 
I can recall at least a dozen proposals made in the blog, and all 
of the interesting ones will need to be considered.

init and destructor accessors too.

might be nice to support print accessors... what do you think?

I woudn't mind if accessors where reserved for classed based OOP. 
 the controler and model are separate so its a logical match.

As for Maxim's suggestions above: init and destructor methods (use 
the right terms, Maxim), maybe; print accessors, no. REBOL is not 
an OOP language, so we don't need the workarounds that OOP languages 
need.

but I'm just being devil's advocate I agree that most OOP languages 
consider constructor and destructors specific method types.

The SET-FACE and GET-FACE functions are procedural accessors without 
the syntax support.

liquid and by extension glass use function accessors exclusively. 
 but i would like the syntax within the language... it would allow 
one to use many liquids as ordinary objects and make lazy dataflow 
much more palatable for the casual user.

So the main thing that the property feature does (from my extensive 
experience using that feature in other languages) is to hide complexity. 
Which is great, until you actually need to know what the heck is 
going on - something that happens almost immediately. At that point, 
hiding the complexity means destroying your ability to understand 
your own code by looking at it, even a simple assignment statement, 
and forcing you into a particular model of operation that may or 
may not be appropriate. So it's great for Delphi, which comes with 
a built-in GUI framework and is supposed to be easy for VB-level 
programmers to use; it's not so good for REBOL, where the GUI is 
swappable and our users are in some cases some of the smartest people 
I've ever met.

still, 

my-face/text: "this"

is more transparent and reusable than

set-face  my-face 'text "this"
or
set-face my-face [text "this"]


ironically glass supports both of the above (using its own set of 
accessors)

set-aspect/get-aspect  and specify

brian, api builders might be smart, but end-users might not (within 
a specific field of programming), and its not their place to have 
to try and resolve much of that.


if your api works, then it shouldn't cause side-effects break... 
using accessors or not.


accessors are for users of APIs which have a lot to manage which 
isn't going to be delt by the user anyways.  

my two cents.

brianh exactly... it would actually make sure the draw-block 'my-face 
 to is up-to date and make sure:

my-face/text: :delete-your-hd  

is refused

Darn, Steeve, you just deleted my hard drive and bombed Cambodia!

for example, liquid, uses processed fields.   most of my liquids 
will normalize input, and make sure the output conforms to the spec.


the value might even be converted to a default or a generally accepted 
unknown value like an error! or none!

sure, but then you have two references to the same attribute and 
setting the field doesn't use the rebol syntax for setting the field.


I do agree that in R3, since we can protect fields, at least we can 
now enforce the use of set-a and be sure its not replaced as-well.

Currently I use 'resolve a lot, to swap contexts so that I can use 
a light syntax in every functions because they are all bound to the 
same context.

I try to eradicate paths the most I can, It's uggly and slower than 
swapping contexts at some points.

yes, 'resolve will be extensively used in liquid R3, especially in 
my graphic kernel which uses labeled inputs exclusively.


but it still needs to use class based path access for simple speed 
and memory requirements.  each class currently gobgles up about 20k 
of ram once bound.  rebinding on the fly would be excessively slow.


liquid's lazy provides vastly supperior optimization in any case. 
 functions aren't even called in the first place ;-)

and glass even uses the liquid (trans)mutation feature where you 
swap classes on the fly based on oranisation of GUI

also unlabeled inputs use up MUCH less ram.  its just a block containing 
references to subordinates.  if we use an object, we add an extra 
overhead of obejct and binding space for each input.

with the A98 release I will be porting liquid over to R3 for sure 
(at least I'll try and see how it goes).

not sure, It has to be confirmed but in R3, objects sharings the 
same parent objects  have the same specs (in memory) and have only 
their data copied in a distinct frame.
BrianH could confirm that point.

I'll definitely run my liquid unit tests and see how R3 compares 
to R2 under heavy load ( a few hundred MBs of nodes)

(Sorry, phone calls) Processed fields are great, and accessors are 
a great, but there are at least 3 different ways of doing accessors 
(method, procedural, functional) and syntax support would only support 
the method-style accessors. And because of REBOL's object model, 
method-style accessors have a lot of memory overhead, whether they 
are supported by syntax or not. This is why R3's GUI uses procedural/functional 
accessors.

So my biggest practical beef with syntax-supported accessors for 
REBOL is that we are actively trying to get away from the style of 
programming that they require. My only other complaints about syntax 
support comes from many years of actually using a language with such 
support, and seeing the many downsides.

and actually, labeled inputs might link to several other nodes.  
so even there, we couldn't use expanding objects.

Steeve, REBOL in general and R3 in particular doesn't have direct 
support for parent objects; we support prototype objects instead, 
which is a completely different thing. So the body of an object isn't 
stored at all, let alone shared; instead, BODY-OF an object creates 
a brand-new block every time from a collection of the key and value 
pairs. There might be some data sharing of the words collection between 
a prototype of an object and derived objects (which might be what 
you meant) to save memory, iirc, but the values are BIND/copy'd.

In my experience it will always be worth it.   because object use 
is very heavy RAM wise and it quickly becomes slower because the 
GC can't cope with big lists of things to manage.  so although it 
might be slower in a small app (where the difference probably won't 
really show anyways) in a large application the ram savings will 
mean the GC stays agile and doesn't bog the actual processsing.


but again, new explicit tests required with R3.   everything changed 
so its up for grabs as to how a few hundred thousand object will 
crap out.

Strangely enough, one of the things that needs to go on Guiseppe's 
object enhancements page is Carl's proposal to actually add a spec 
(in the SPEC-OF sense) to objects. That is the spec that he was talking 
about sharing. And that would be required to implement class-like 
behavior, syntax support for set accessors (which Carl called set-functions), 
init and destruct methods, etc.

And it will make objects act a little more like modules, which have 
such a spec already.

Steeve, that sharing requires some kind of copy-on-write to work 
properly, and maybe hashing to really save on space. The overhead 
of those two may exceed the payoff.

Hiding blocks new bindings, and path access creates a new binding. 
Only words bound before the hiding (or words derived from them) will 
still work.

On the other hand, there could be a new function type - perhaps called 
method! - that uses object-relative bindings, including binding 'self 
to the object and prohibiting 'self from being an explicit parameter. 
Object path evaluation would have to be modified to provide the implicit 
'self parameter, and all object bindings at the point of creation 
would be made relative to 'self. Not sure how that would work with 
hidden fields - it probably would have to not see them. And it would 
have to stack walk up the call chain at definition time to find the 
appropriate object to rebind to the dynamic object binding, and perhaps 
again at method start time to find out which object to be relative 
to. All in all a complex proposal, but that kind of thing might not 
be avoidable in REBOL's binding model.

And I mean that they work *now* :)

yes, but you coudn't change the accessor since you'd need to rebind 
it, and in many cases, expanding objects, is about modifying how 
the internals are managed.

and this doesn't require any special tricks.

I would think that *designing* objects is about managing how their 
internals are managed, and *expanding* them is about using them as 
data structures.

Although expanding and providing access to the old stuff from the 
expansion does require *one* special trick: Explicitly binding the 
expanded stuff to the old object, likely before you use the block 
for the expansion.

So three people want change, but there's no agreement and everybody 
else doesn't care, am I right?

The only overhead added to objects would be for fields to assign 
the method! values to. The method! values themselves would just have 
their references transferred on MAKE object! - they wouldn't be BIND/copy'd. 
And if you implement them right, they wouldn't even need to be defined 
as part of the object body, or bound to the object explicitly before 
being appended.

Bolek, I'm not really one of the three people who want change - I'm 
just trying to make potential changes better and more cohesive. Carl 
is though: He made most of these proposals.

Sorry Brian, so two people want change, you're commenting and everybody 
else gives a fu...doesn't care. Does that represent current situation 
better?

and very few people participate in fundamental language design in 
general.    especially this one, since this is aimed at more structured 
code development and very few REBOLers now and historically do larger 
apps, where these details are most usefull.

Also, very few REBOLers try to migrate large apps written in a class-based 
OOP style, instead preferring to use REBOL semantics and only emulating 
classes where appropriate. REBOL is not an OOP language, by design; 
it is optimized for a different semantic model. You can structure 
large-scale applications based on non-OOP models if you like. You 
can't easily convert them to class-based languages though. I don't 
envy your task.

I were in my bed when some strange smell has appeared.
I told myself: "it's me, nothing is happening..."
The smell continued...

I went to the lower part of myt house when the slave PC is located.
The PC turned on and the AGP card BURNING ON FIRE !

Nothing to do with REBOL3 but I told you GoodNight and I want to 
inform the community it is not a good night !

I find REBOL very well suited to large app dev.


you can tailor every aspect of your system to the exact requirements 
and your not forced down a path which makes no sense.


you just have to think for yourself a little more, cause you've actually 
got much more options

This is the first time that I've taken a look at gob!s (an unpleasant 
thought for a genuine native English speaker), it seems that once 
you've inserted a gob! into a gob! you lose the ability to directly 
address the gob! and have to use "DOM-type" crawling to get at them. 


I'm sure I've overlooked something and would be happy to learn what.

Scrolling a pane with hundred of gobs, that's what i call intensive. 
And it 's not rare use case to my mind.

It's possible that it was delayed already because of some host kit 
blockage, and we got all of the 'self and bug fix goodness while 
Carl was thinking it through. I'm not worried yet.

the hostkit extraction is a pretty huge endeavour, because he has 
to change the core model and open it up much more.


the GUI pokes at just about every level into the core things like 
actions (callbacks into the core), devices, object access, these 
can't be side-stepped IMHO.


yes the A98 (or whichever release fully extracts view from the core 
as an extension), will be the mother of all releases.   The only 
REBOL release I have been waiting for... for over a decade.