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

World: r3wp

[!REBOL3-OLD1]

Janko
3-Jun-2009
[14994]
Brian .. is there a way to get current local state inside function 
as a block and store it somewhere?
Maarten
3-Jun-2009
[14995]
Besides, we have sped up hardware more than that since then ;-)
Janko
3-Jun-2009
[14996]
I mean list of variables / words defined in a function and their 
values?
Maarten
3-Jun-2009
[14997]
I would be happy with just breaking out of a nested block and having 
a "deep" reference instead of only the one from the lastly traversed 
inner block
BrianH
3-Jun-2009
[14998]
Janko, store it, yes, more or less with the STACK function. Restore 
it, no.
Maarten
3-Jun-2009
[14999]
Rebuild it?
Janko
3-Jun-2009
[15000]
there is stack function? .. is it R3 only?
BrianH
3-Jun-2009
[15001]
Yes, and restricted by PROTECT.
Janko
3-Jun-2009
[15002x2]
aha interesting
can you also somehow access your current position in the block of 
code like as if it's a serries? *B*: none a: does [ 1 + 2 *B*: get-current-pos 
5 + 3 ] ?
Maarten
3-Jun-2009
[15004]
Brian, when you get to tasks, pleae look at the queue/multiprocessing 
module in Python 2.6 I can help you on that. I think they have done 
it right, and it feels very REBOLish.
Pekr
3-Jun-2009
[15005]
Maarten - you should be instead ready with your proposal for R3 tasking 
:-) Then no continuation is needed, no?
BrianH
3-Jun-2009
[15006x2]
If you want to resume continuations you have to build your runtime 
around the concept, which basically turns your language into Scheme 
with a different syntax - that's R1. Like R1 and early Schemes, your 
language will be slow. Scheme solved this by compiling the code and 
letting the optimization phase remove the continuations, where possible 
- where not possible, Scheme is still slow.


REBOL doesn't have this option because code is data *at runtime*, 
rather than having the input syntax be data, but the runtime code 
the result of compilation. Code that relies on this (and there is 
a lot of that) is not compilable in any direct sense.
The days of hardware getting faster is going away - now the hardware 
is staying the same speed, but more hardware (more cores) are being 
added. You get more speed through parallelism. Slow langages are 
getting made faster or dying out.
Maarten
3-Jun-2009
[15008x2]
Brian, I only want to exit a deep block and get a position back, 
like [ 1 5 7 ]  which would mean:
 

at position 1 there is a block, inside at position 5 another, move 
to position 7 now.

Think at/deep [ [ [ ]]]  [1 2 3]   - that would be all.
There is no continuation involved there.
BrianH
3-Jun-2009
[15010x2]
Just data? You threw me with the "exit", which doesn't really apply 
to data.
Maybe AT with a path! indexer?
Maarten
3-Jun-2009
[15012x2]
Let me be more specific:

at with a path indexer!  at [ ] 1/2/3


And inside parse break providing a path indexer. That would do many 
tricks
a: parse [ ..... break .... ]
>> a
1/2/3
BrianH
3-Jun-2009
[15014]
The parse break op means something else, though that should be extended 
to breaking to the next loop op out. I'm not sure what the value 
of the parse one would be if you can't resume the parse where you 
left off. You can set the position in the data, but not the rules 
or any nested parse blocks.
Janko
3-Jun-2009
[15015]
brian .. I am looking at stack in R3 .. do you have any idea how 
you could return arguments names and their values? I get the values 
..


>> a: func [ b ] [ probe stack/args 0 probe stack/args 1 probe stack/args 
2 ]
>> a 123
[0 none none none true none none none]
[123]
none
== none
Steeve
3-Jun-2009
[15016]
>> words-of :copy
== [value /part length /deep]
Janko
3-Jun-2009
[15017]
interesting, didn't know for words-of .. could a function somehow 
reference itself .. 
>> myfunc1: func [ b /local a ] [ words-of :myfunc1 ] myfunc1 123
== [b /local a]

(maybe I am wondering in stupid directions without much use here)
BrianH
3-Jun-2009
[15018]
It looks like you have to know the function, since STACK/func doesn't 
seem to work for > 0 right now.
Gregg
3-Jun-2009
[15019]
Unit! would be a great type, but it opens a lot of questions. If 
you treat it like money! works in R2, where the denomination is basically 
a tag, you get a lot of expressive power, and defer behavior to the 
user. 


The big thing is the notation, no? A serialized format seems to ugly 
to me, but I don't know how hard other options might be. Assuming 
no spaces, what looks natural?

100`kg
100/kg
100/m/s
100·m
100·m/s
BrianH
3-Jun-2009
[15020x2]
I guess stack/func isn't used internally yet.
I don't think - or / will work very well with the lexer. Perhaps 
~ ?
Maarten
3-Jun-2009
[15022]
Brian,  parse uses tables (at least last time I checked on compiler 
construction ;-) so it shoud be a easy to do.


If I have at/deep or so, I can creat a new head and build a stack 
of traversed parse rules. Actually that would represent the table. 
Which means I could do this today. And I can wite at/deep by using 
some recursion.

Thanks!
BrianH
3-Jun-2009
[15023]
PARSE uses recursion - it's not a compiler generator.
Gregg
3-Jun-2009
[15024]
Does REBOL use a shift-reduce parser?
Steeve
3-Jun-2009
[15025]
hmmm, i have a security violation with A55 when using stack/args
BrianH
3-Jun-2009
[15026]
Gregg, no.
Gregg
3-Jun-2009
[15027]
I didn't think so.
BrianH
3-Jun-2009
[15028]
Steeve, you have to start R3 with security turned off - use -s.
Maxim
3-Jun-2009
[15029]
Gregg, 100kg 100%  85m/s 405km/h 100$  30s
BrianH
3-Jun-2009
[15030]
REBOL uses recursive descent with backtracking - basically a TDPL 
or PEG model.
Maxim
3-Jun-2009
[15031]
its sooo simple, a decimal with any alphanumeric combination glued 
on is a unit.
BrianH
3-Jun-2009
[15032]
Not bad, Maxim.
Maxim
3-Jun-2009
[15033x2]
the scientific notation being part of the decimal, you just append 
to that

1.0E-3m  == 1mm
and the current lexical specifically traps this error, so converting 
that error into a new BCD unit type is the logical step for me.  
this replaces money and any other special unit we want.
BrianH
3-Jun-2009
[15035]
You wouldn't be able to make a unit a number!, or even a scalar!, 
but otherwise doable. As long as the unit is on the left side of 
a equation it would work. You wouldn't be able to replace money (prefix 
vs. postfix), but otherwise good.
Maxim
3-Jun-2009
[15036x2]
with a few functions, we could even do unit conversions, very easily. 
 units would become some sort of sub-type.  poke a few units as part 
of the default distro and you've got a VERY usefull new functionality.
but with unit, you CAN throw away money.  when parsing, all you need 
is to verify the unit's "moniker" and compare it with "$" if that's 
what you need.
Janko
3-Jun-2009
[15038]
BrianH: I won't be able to make an example (and maybe it's not possible 
now) .. but I was asking because of this maybe stupid idea for "poor 
mans continuations" 


that are built on top of language as a lib (because of rebol powerfull 
treatng of itself): 


- you have a function >>myfunc: func [ a /local b ] [ b: 5  return-cont 
 a + b ] <<
- at runtime when function is called you reach return-cont which:

  - you collect all it's local words and their values into a block 
  (with stack/args etc)  for example [ a 1 b 5  ]

  - you also get current position of a running block (already seems 
  to be possible with stack/block + next )  [ a + b ]

  - you generate a function at runtime that has >>does [a: 1 b: 5 a 
  + b ]<<
  - you return taht function as a normal return value.
this means that this would be possible:
>> cont: myfunc 5
... do some stuff
>> cont 
== 6

any thoughts :) ?
BrianH
3-Jun-2009
[15039x3]
There is one programming language with unit such conversions built 
in, but the language needed to be built around them. We can only 
emulate that in REBOL with functions.
- you generate a function at runtime that has >>does [a: 1 b: 5 a 
+ b ]<<
That is the slow part, and for some code exponentially slow.
Continuations don't work too well in languages with modifiable state 
- look at Icon for the worst example of this.
Janko
3-Jun-2009
[15042x2]
yes, I know that this would not be anywhere near natively fast.. 
but do you think this would be theoretically possible?
I have to admit I don't know that much about continuations, just 
the surface stuff