AltME groups: search

I was a little surprised that it cased the problem. I thought catch-or-try 
blocks were nested, their contexts stacked.

Each time I see someone mention Erlang model I want to post my last 
"actor-ish" rebol samples I made like 3 weeks ago and still haven't 
found time to post .. it's nothing special, but it can give a little 
feeling and future ideas how it would look in rebol

does rebol 3 have a fast function which converts  [[1][2][3]]  into 
[ 1 2 3] ?

just blocks... cause its a recurring "problem" thru the years.

obviously, I know how to write one... but its a pretty recurring 
need for inclusion in the /plus pack... no?

Yeah, it's a good candidate for /Plus. The problem is that whenever 
the need occurs, what it needs to do is slightly different. Flexible 
semantics like that lead to a slow function - which is a bad thing 
for a mezzanine or library func.

That is so true: "everyone wanted the function to do something [a 
little] different".


So, the question always becomes: what is the most common pattern, 
and how common is it really?  Difficult to know, especially when 
you start thinking about adding reduce or compose into it.

R3 Chat #4395:
  

Re #1890: Question on DO/next: currently, it returns a block as a 
result. That means it must allocate a new block each time. An alternative 
would be to provide a variable name as an argument, and it would 
not need to allocate a new block each time.

   result: do/next block1 'block2

It would also be possible to:

   result: do/next block 'block

Something to think about.

Tomc needs it for a homework assignment, unknown due date.

BTW, BrianH is a co-author of it

Carl, there are at least a half-dozen mezzanine/library function 
requests that are waiting for DO/next. Your continuation word idea 
is good though :)

overhead: yes, I found a test showing really huge diff when not generating 
blocks every now and then

It would matter to me. If DO/next were more efficient, I would not 
consider use of it to be a sign of a bad function :)

thanks, Carl. BTW, I am using www.rebol.org as a truly random source, 
since it is so easy in REBOL

I just lost my connection to rebol.net -- quite odd -- as if a router 
along the way just stopped working.

Carl, btw, something in liquid is causing a  prior versio of R3 to 
crash.  I'll try next week with the latest version, there might be 
some new tickets coming as part of the R3 conversion of liquid.

BTW, there is a bug in objects related to a copy loop if the object 
references itself (directly or via a block).

I can't wait to convert liquid  to a datatype, its going to be soooo 
much more sexy, and easy for everyone to "get".

the only thing is that the inner object (the shared class) gets a 
reference to the outer object (the instance) as its first parameter, 
just like the R2 face/feel

Please, a new June plan that also recaps the May accomplishments 
:)

No, the /into option doesn't work like that. The /next word could 
be named cont, since it is a kind of continuation :)

'do/next - I use it in a function as a subverted version of 'case. 
 Perhaps if that's a bad function, there is an alternate way to implement 
it?

Carl > Have you seen wave.google.com ? 

why isn't that kind of project  made with  Rebol ?
 

I mean most of the technologies involved in wave could be done using 
rebol and even in a better way if  instead of jave/python xml and 
html you can design a wave oriented dialect . Your clever than me 
so I think you already got the point.

next ask is do you think  somthing like colaborative "at the same 
time" could be possible to do with R3  for example hum lets be crazy 
in futur viva-rebol IDE offers a way to make several ppl working 
on the same project at the same time use the viva-rebol IDE and sharing 
in real time information

for example you and me works on the same file at the same time using 
viva-rebol ide and you fill a part of the file i fill another part 
of the file and we both see in real time what the other is doing. 

(for example you do the parse parse rules and i write the GUI  of 
an applicaton things like that)

well that's not a new thing Moon edit propose that kind of collaboration 
real time since some years already. what i like in wave is the modular 
aspect  you are not limited to a conversation you can create  "wavelets" 
to anykind of  use and extrapolating that system to the already existing 
rebol tools (rebol.org, view/desktop, ios etc...) would be really 
a big thing

B: does block if case is false.  Sort of like 'all, but with a reason 
for each failing case (provisionally called 'assert-all):

either assert-all [
	case-a [raise "Case A failed"]
	case-b [raise "Case B failed"]
	0 < 1 [raise "Something is very wrong"]
][
	print "Both Cases were true!"
][
	probe raised-val
]


Makes more sense when each case is dependent on the previous one, 
for validating input, etc.

Take a look at the ASSERT function in R3 - it might do what you need 
faster and safer. Or it might be off-topic :(

Never mind, I read a point above incorrectly.

Another attempt (I don't give up yet :-) - has anyone problem, if 
money! datatype would be renamed to unit! datatype? I think "money" 
is really a bad name for something being more general and precise...

Yes, I have a problem with it, due not being able to identify money 
during parsing, if we lose it. I think there should be more focus 
on having a generic BCD number type. As money is now, I think it 
should be left alone, but add other datatypes that are more appropriate 
to specific jobs.

also tieing a unit to a number directly might limit the applicability 
of unit calculations as used in physics and symbolic math.

I don't want to call it "unit!" because the type would be really 
poor for that, and we don't want to reserve the word "unit" for a 
poor implementation of the idea, especially when we have user-defined 
datatypes.

BrianH: then think of $ as a sign of measure (that was another name 
for money, but unit is shorter and more to the point). Why is file 
represented by % sign then? It has nothing in common with percentage 
= $ has nothing in common with money. Maybe in US.

Pekr, renaming a function is not the same as renaming a datatype. 
You lose functionality and gain something specifically different. 
When renaming a function, you don't lose anything.

$ is used as a sigil of money in many countries, not just the US.

IIRC there was a blog what to do with money! datatype, and if the 
datatype should be more "complex". That is still not resolved.

could a serialized item be considered its own datatype?, such as 
#[none]

There are a few serialized keywords, but the rest are constructors.

Pekr, yes, although [] directly, won't work. I'm assuming that we 
could basically do something like ![m / s] or &[m / s] and have that 
work as a datatype.

They are constructors internally, as you describe - try doing a bad 
one and read the error message.

the error message is: "** Syntax Error: Invalid construct -- #[**" 
how does that tell it is a method?

Between that and conversations with Carl, it has become apparent 
that deserialization is done on a type-specific basis, and that the 
supported types have internal chunks of code that handle the data 
in the representations. You are being too specific in your definition 
of "constructor" - even in the OOP languages it means "something 
that constructs".

Wikipedia: Constructor (computer science), a special method used 
in object oriented programming which puts the object's members into 
a valid state.

MAKE and TO: they can be called "methods", since they are functions, 
but #[...] is something totally different, and it surely isn't "a 
method"

there is nothing like "internal" from a user's POV, anything "internal" 
should be invisible, that is why I honestly don't understand, why 
the END! datatype is exposed

moreover, the #[...] constructs are actually executed by the LOAD 
function (or maybe Transcode,...) internally, which may call whatever 
functions it likes to construct any specific datatype represented 
by the discussed #[...] text, but this does not make the "#[...]" 
text a function, anyway

The text is not a function. The *handler* for the text is a function.

so, the distinction is, that "#[...]" actually is data (argument/arguments) 
for a constructor, not a constructor

yes, I understand, there is a constructor (there has to be one), 
but the "#[...]" text is not a constructor, just data for a constructor

Ladislav, if you think that I am saying that the lexical form #[...] 
is a function call, you are wrong. I am saying that the processing 
of that lexical form is handled by an internal function call that 
constructs a value of a particular datatype. That is what I have 
always beenn saying.

yes, that is correct, of course. What I mean by saying, that #[...] 
is not a constructor is, that the function is "somewhere else" (in 
C or internal Rebol code, I do not exactly mind in this case)

BTW, what do you think about the END! datatype? is there really a 
reason, why it has to be "exposed"?

There is a reason to reserve it, but not expose it per-se. It would 
need to be used by internal code and a lot of that internal code 
is written in REBOL in R3. From what I know about blocks (minimal), 
it seems like the nul character for C strings, but less required.

do/next matters to me, but, I don't count for language features (Carl 
put me in the 0.1% basket ;-)


What I would like is a "break out"of a block much like throw, that 
allows me to re-enter even in nested blocks.

I think a closure over the evaluation with an "into" would do it. 
It is easy to see parse with into do this.

That's a continuation.

Maarten, yes that jump out and back again into the same state would 
be very cool but it seems a very core thing that is either possible 
or not

We removed those from REBOL with the R1 to R2 rewrite. Sped up REBOL 
by around 30 times as a result.

It is possible at the data manipulation level. REBOL is a data language 
after all.

Brian .. is there a way to get current local state inside function 
as a block and store it somewhere?

I mean list of variables / words defined in a function and their 
values?

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

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 ] ?

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.

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.

Maybe AT with a path! indexer?

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

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

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)

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

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!

PARSE uses recursion - it's not a compiler generator.

Does REBOL use a shift-reduce parser?

hmmm, i have a security violation with A55 when using stack/args

REBOL uses recursive descent with backtracking - basically a TDPL 
or PEG model.

its sooo simple, a decimal with any alphanumeric combination glued 
on is a unit.

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.

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.

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.

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 :) ?

- 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.

The generation of a continuation function would only be possible 
with system support, including internal state of natives. Without 
system support it would only be possible for continuations at the 
top level of a function's code (no nested blocks).

aha yes.. you are right.. inside a loop or other nesting this all 
breaks ..

Janko, you can have cooperative scheduling of real threads - all 
they have to do is cooperate, as long as a thread can pause.

here is an example of how we could use the unit system if it where 
implemented.


ANY unit moniker could be used, and in fact the switch tables below, 
could be context-specific and dialect-configured, adding to the DSL 
power of  REBOL... 


ex: dm could be decimeter or deutchmark (the later should be DM anyways, 
no?) , based on context, the convertion units could mean either or... 
with a default convertion table explicitely defined.

a simple func could let us append or change the conversion tables 
used throughout the system.  


Imagine if the VID would use units directly.  you set your locale 
(or get it from OS) and see values as they should be for your locality.


unit-convert: func [
	in "unit value to convert"
	to-moniker "to what unit type to you want to convert to"
][
	; note: incompatible types set 'IN to value none
	in/value: switch to-moniker any [
		switch in/moniker [
			{mm} [
				[
					{m} [in / 1000]
					{dm} [in / 100]
					{cm} [ in / 10]
					{'} [in * 0.0032808399]
					{"} [in  * 0.0393700787]
				]
			]
			{"} [
				[
					{m} [ in * 0.0254]
				]
			]
		]
		; empty result set, switch on nothing
		[]
	]
	in/moniker: to-moniker
]


unit-convert 100mm "m"
== 0.1m

unit-convert 100" "m"
== 2.54m

unit-convert 2mm  {'}
== 0.0787401575'

just a label...  now find the more powerfull idea I added here  not 
readily obvious... but you should get it....  ;-)

It still wouldn't replace money!, because the international standard 
syntax for specifying money uses a prefix, not a suffix.

we can't just but-in parser rules.  its a core level of the interpreter.

you can just use load/next in a parser rule... I've done it often 
and it works.

it has nothing to do with the lexical analyser, we just need a new 
data type, to construct computed variables

but I would like a way to get invalid tokens loaded as invalid values... 
that way I'd use block parsing .  so far, I've been using string 
parsing about 90% of the time.  its a shame, since I'm loading stuff 
much more slowly than rebol could let me do it using its native loading.

i'ts the same thing, you just need a specific method (ie. dispalyed-as) 
for the computed vars

 those variables would be sort of objects with methods

  that is exactly WHAT an accessor-enabled variable IS  , also known 
  as a datatype   ;-)

the accessors are just events... you have to know WHEN and WHAT to 
do with a variable...   It would be fun if generic objects allowed 
us to set accessors per instance, just like python allows it, but 
alas, Carl doesn't realise just how often this could be used to simply 
a vast array of code.

i don't ask a new semantic for objects (with obvious drawbacks)
i ask for a new datatype, let the objects like they are

Petr < has anyone problem, if money! datatype would be renamed to 
unit!>

Agreed ---- It seems likely that if money! had not existed in R2, 
none of us would be expecting R3's BCD datatye to be called money!

Given that so much of R3 is a break from R2, Let's make the small 
change [deliberate currency pun] and give it a better name.
We could keep money as a subtype of that.

Since objects are the basis of all datatypes where words can be bound, 
we are focusing on the design of those other datatypes first so we 
get a better idea of the requirements for objects. Other datatypes 
like modules and tasks, for example.

I was answering to Sunanda, a new name to replace money!