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

World: r3wp

[!REBOL3-OLD1]

Maarten
3-Jun-2009
[15116x2]
You need first-class functions to have continuations.
But, if you want them to have reasonable speed... some native support 
helps...
BrianH
3-Jun-2009
[15118x2]
If you want continuations supported well you need to build on a continuation-passing-style 
runtime. As far as I know, the only practical one with good performance 
is Parrot.
That is, unless you switch to a compiled language.
Janko
3-Jun-2009
[15120]
brian, you seem to really know what's happening at various languages 
scene.. cool .. I was just looking a talk (video) about parrot VM 
where it presented these things few weeks back where a woman was 
presenting these features (and I consider myself a language nutcase 
;) )
BrianH
3-Jun-2009
[15121x3]
I haven't really followed Parrot for a couple years - lost interest. 
Suppose I should take another look.
I'm not sure what model Stackless Python uses - in theory if could 
use CPS, but I haven't checked yet.
Strangely enough, the intermediate codes of many compiled dynamic 
languages are switching to SSE, which is procedural CPS.
Janko
3-Jun-2009
[15124]
CPS is cont. passing system... what is SSE ? :)
BrianH
3-Jun-2009
[15125x2]
Static Single Assignment.
CPS = Continuation-Passing Style.
Janko
3-Jun-2009
[15127]
aha.. like in functional languages?
BrianH
3-Jun-2009
[15128x2]
Sorry, SSA
The functional language equivaalent is CPS. SSA is for languages 
with assignment and/or modification.
Janko
3-Jun-2009
[15130]
sorry, my lack of proper CS education shows here :)
BrianH
3-Jun-2009
[15131]
Well, the equivalency of SSA and CPS had not yet been demonstrated 
when I had my CS education (years ago).
Maarten
3-Jun-2009
[15132]
Stackless moved away from CPS towards coroutines. I think Gambit-Scheme 
(even without compiling) does a decent job. 


I don't want to go the CPS route, but I find it intriguing that the 
Elephant in the room of re-entrant data blocks is .... an ELEPHANT. 
The fact that a problem is hard is no reason not to solve it.
BrianH
3-Jun-2009
[15133x6]
It's not that it's hard, it's *why* it's hard. And that why is why 
R2 was so much faster than R1. Making the system resumable slows 
it down by orders of magnitude unless you design the semantics of 
the language around it.
And we're talking about reentrant code blocks. You don't exit data 
blocks.
It's not the AT series path request that's the problem.
Sorry, the code-vs-data distinction I made above isn't really a code-vs-data 
distinction, it's a path-vs-stack-referencing one. Janko and I have 
been talking about something other than your AT series path request.
Oldes: "How stable is the R3 networking? For example what is the 
cause of HTTP issues?"


R3's low-level networking is pretty stable, but the HTTP scheme is 
only partially done. And no other high-level schemes are there.
The HTTP scheme currently doesn't handle network errors very well 
- that includes server issues.
Oldes
3-Jun-2009
[15139x2]
And what is the best place with info where to start?
http://www.rebol.net/wiki/Ports?
BrianH
3-Jun-2009
[15141]
Yup, and read the source.
Pekr
4-Jun-2009
[15142]
Oldes - don't forget to study the link in above article, especially 
- http://www.rebol.net/wiki/Port_Examples
Pekr
5-Jun-2009
[15143]
BrianH: what will be the equivalent for read/lines in R3? I kind 
of can't live without that function :-) Should I create mezzanine 
for it?
BrianH
5-Jun-2009
[15144]
DELINE.
Pekr
5-Jun-2009
[15145]
and to get it back we should use write enline output?
BrianH
5-Jun-2009
[15146x6]
Yeah, except deline/lines and enline of block doesn't work yet (tickets 
#648 and #647, respectively).
Of course to get the text in the first place you need READ/text (ticket 
#622), or TO-STRING.
Paul, I am taking a look at a good suggestion for a function that 
is similar to one of your mezzanine proposals. Could you take a look?
http://curecode.org/rebol3/ticket.rsp?id=637
Sample usage:
>> any-of x [-1 4 10] [x > 0]
== 4
>> any-of [x y] [1 4 10 8 5 -3] [(x - 2) = y]
== [10 8]
>> all-of x [33 -1 24] [x > 0]
== none
>> all-of [x y] [1 2 3 4] [x < y]
== true
If we do these as mezzanine with the full R3 *EACH word and set-word 
syntax these become big functions, similar in scope to my R2-Forward 
MAP function. If we limit the words to the word! type it becomes 
much easier, but still with more overhead than ANY and ALL. I had 
put off working on these for months because I thought DO/next was 
needed to implement them, but I've just realized that it isn't.
Paul
5-Jun-2009
[15152x2]
I think they are great ideas.  A bit more extended then my any+ function.
Probably a bit more practical also.
BrianH
5-Jun-2009
[15154]
Yeah, I really liked your ANY+, but it wasn't very REBOL-like. However, 
I couldn't come up with anything better. Then this guy did :)
Izkata
5-Jun-2009
[15155x2]
For the second all-of example, 1 and 2 got checked, as did 3 and 
4, but did 2 and 3?  Same question to the second any-of example.
(Mostly curiosity, but with all-of, would be a simple way to see 
if data is already sorted)
BrianH
5-Jun-2009
[15157]
If you provide multiple words, they get treated like a record, just 
like *EACH.
Izkata
5-Jun-2009
[15158]
Ah, never noticed remove-each could do that, although I've used foreach 
that way
BrianH
5-Jun-2009
[15159x3]
If you want to check for sorted, try this (if we support full *EACH 
syntax):
>> all-of [x y:] [1 2 3 4] [any [tail? y x < first y]]
== true
(Soon-to-be) MAP-EACH also supports the record and set-word tricks 
:)
Here's a better check for sorted:
>> all-of [x y:] [1 2 3 4] [x <= any [first y x]]
== true
Paul
5-Jun-2009
[15162x2]
I would change the any-of syntax up a bit myself.
any-of [x [1 2 3] y [4 5 6]][....]
BrianH
5-Jun-2009
[15164x2]
That would require a REDUCE or DO/next to use referenced data, and 
this function is too inefficient to use with inline data, as compared 
to the ANY and ALL equivalent code. These functions would only be 
worth using for large datasets, or otherwise their overhead would 
be too much. That is the problem ANY+ had :(
The *EACH syntax is what makes these functions worth using, rather 
than refactoring away.