r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Pekr
21-Apr-2010
[2341]
it does not make them low level anymore. those functions were about 
reading stream of bytes, not strings ...
Steeve
21-Apr-2010
[2342]
because of some complaints with file operations
BrianH
21-Apr-2010
[2343]
Because they were needed for the main uses of READ and WRITE: Text 
processing.
Pekr
21-Apr-2010
[2344x2]
hahaha :-)
so you talk x hours to me, trying to explain, that R3 broke with 
R2 almost-everything-is-string attitude, to later on admit, that 
we gave up on strictly deviding, what 'read/write are supposed to 
do
BrianH
21-Apr-2010
[2346]
Hey, we added support for Unicode text processing right into the 
language, even including two datatypes specificly for that purpose: 
string! and char!.
Pekr
21-Apr-2010
[2347x2]
when was /lines added? I even did not notice it ... even the blog 
which was supposed to resolve it did not mention anything like that 
...
I thought we got 'split to simulate read/lines?
Steeve
21-Apr-2010
[2349]
It's not an exception Pekr, there were changes made in the past without 
any commercials
BrianH
21-Apr-2010
[2350]
Alpha 78.
Pekr
21-Apr-2010
[2351x2]
I think this is all under-engineered - not finished in design. There 
was never any resolution posted to the topic. And the topic is deep. 
It reaches even continuous reading and parsing (streaming) and codecs 
...
Current codecs are totally unusable
BrianH
21-Apr-2010
[2353]
Agreed.
Pekr
21-Apr-2010
[2354x2]
I think that Carl will have to think about this single topic for 
quite some time, to get the design right ...
The truth is, that while I prefer things being conceptually correct/consistent, 
I also miss, if we miss on easiness of use of R2 (read/lines, simple 
tcp open/insert/copy/close sync mode)
Steeve
21-Apr-2010
[2356]
probably we need a new FSM dialect, parse is not suited to do that 
job. We have to do too much hack to simulate a fast and clean state 
machine.
BrianH
21-Apr-2010
[2357]
Sounds like a good community project.
Pekr
21-Apr-2010
[2358x2]
wasn't DELECT meant to be that? Maybe not ...
btw - will DELECT have any use, when commands will replace it?
Henrik
21-Apr-2010
[2360]
could use an FSM dialect. in fact we could use a library of various 
dialects.
BrianH
21-Apr-2010
[2361]
You will need to have some way for a block of dialect to be passed 
to a command-based dialect processor. So some function to take the 
place of DELECT will be required, even though it won't be compatible 
with DELECT.
Pekr
21-Apr-2010
[2362]
so DELECT will become mostly useless, correct?
BrianH
21-Apr-2010
[2363]
No, fully replaced by something completely different. Which doesn't 
yet have a name, but might be called DELECT. The existing DELECT 
will be gone.
Pekr
21-Apr-2010
[2364]
OK, thanks ...
Maxim
21-Apr-2010
[2365]
sometimes you have to do stuff to think about even better stuff  
;-)
Gregg
22-Apr-2010
[2366]
Steeve, Gabriele and I (and perhaps others) have written FSM dialects. 
I think it's a great idea.
Pekr
26-Apr-2010
[2367]
First bugfixes appearing in CureCode  for A98 ....
Pekr
27-Apr-2010
[2368x2]
Self reflection - http://www.rebol.net/r3blogs/0312.html
I wonder how the 'self discussion resolves. Brian - Carl just pointed, 
that the description to #1549 ticket is not clear to him .... there 
is also new Doc page to it - http://www.rebol.com/r3/docs/concepts/objects-self.html
BrianH
27-Apr-2010
[2370]
I'm reading the page. So far it reflects the surface behavior of 
my proposal, but is less detailed so I can't say for sure.
Maxim
27-Apr-2010
[2371]
it seems pretty straight forward to me.
Pekr
28-Apr-2010
[2372]
I would like to more understand the 'self topic :-) (well, maybe 
I will never be able, but ...) .... what is the difference between:

- field
- flag (eventually)
- and - keyword?


Is that the field is a real variable (word), flag would require some 
internal storage, but is not an user level value/attribute of the 
context, and keyword is just something like flag known in runtime 
during execution? But 'self, being a keyword, has to be somewhere 
stored too, no? :-)
BrianH
28-Apr-2010
[2373x2]
The word 'self, when a keyword, only has the storage for the word 
value itself; it doesn't have any associated value slot in the object. 
A field of an obhect has a value slot in the object. And a flag is 
internal, probably just one bit somewhere.
So a keyword only takes up as much space as an unbound word.
Pekr
28-Apr-2010
[2375]
so the word 'self keeps pointer to context it is bound to?
BrianH
28-Apr-2010
[2376x2]
Yeah, but it's a special binding, with just a reference to the context, 
not to a field. The object doesn't have a 'self field. The 'self 
keyword is currently just a side-effect of the BIND and IN functions, 
not something that is really in the object.
That's why the previous debate about this was so confused - that 
info wasn't known back then.
Pekr
28-Apr-2010
[2378]
why the change from R2 model, where it was a field? Was it troublesome 
for iterators, which counted 'self as a regular object word?
BrianH
28-Apr-2010
[2379x3]
Yes, plus it took a lot of space (it adds up). Plus the objects that 
didn't have that field behaved badly - such objects were created 
to serve as function contexts, or by functions like USE and FOREACH. 
Since all of the code that worked on objects had to skip past the 
first field ('self), if the first field wasn't 'self it was still 
skipped. Plus the 'self field was writeable, which made code injection 
attacks possible when running untrusted code - not really a concern 
for R2 with its known insecurity in such situations, but for R3 it's 
a design criterium to be able to sandbox code. It is really better 
to not have the field at all, and just make it a keyword in certain 
limited circumstances (imo).
This wasn't really much of a problem for experienced R2 developers 
because they learned the workarounds and checks necessary to add 
to their code to make it work. Or in the case of things that work 
badly or not at all, they got used to not doing those activities, 
no matter how useful they would be. It was a "good enough is good 
enough" situation, with noone asking whether it really was good enough 
until the R3 project started.
This is why arguments like "We never needed to do that before!" break 
down. The reality is that we *didn't* do these things before because 
we couldn't, or because it wasn't safe, not because we didn't need 
to.
Pekr
28-Apr-2010
[2382x3]
Does the situation also change because on some new models to R3, 
as e.g. separated user/script/module contexts etc.?
I don't undersand all the fuss about the 'self :-) Is your and Ladislav's 
point of view really so different here? :-)
... and also - does Carl's new doc provide you with some explanation, 
how actually 'self is handled in various situations?
BrianH
28-Apr-2010
[2385x2]
Not really. But the change in function evaluation affects it somewhat.
Carl's doc is too high-level to be helpful here. His list of tests 
is better, but still incomplete.
Pekr
28-Apr-2010
[2387]
Carl put temporary decision to the 'self case ... we are probably 
very close to A98 release ...
BrianH
28-Apr-2010
[2388]
Looks like the argument has been settled. Good for us :)
Pekr
28-Apr-2010
[2389x2]
A98 released - see R3 Chat ...
sorry, marked as A97, Core only, for the purpose of 'self testing 
...