AltME groups: search

But why not make the /into default behavior?  And then use /copy 
for the alternative?

Because the series creatiion builder model is easier for less advanced 
REBOL programmers to use. Buffers need management (as #1789 explains). 
This new model is for more advanced programming, such as mezzanine 
and library code.

Well, right now i need discussion and consensus. I have CureCode 
wishes, mezzanine modifications, new functions, and massive optimizations 
all waiting on this. I'm really blocked until this is decided on.

I guess, I don't follow.  Maybe, I'm jumping to conclusions about 
what /into actually implies.  To me, /into implies that the original 
series passed to the function is what is modified and not a copy 
of it.

Please read #1789 before you make that decision. The difference between 
/no-copy and /into is important.

Yes. But not for (RE)JOIN because JOIN or REJOIN /into is exactly 
the same as INSERT and INSERT REDUCE. What we *do* need to add /into 
to is (RE)MOLD, (RE)FORM, REDUCE, COMPOSE, READ, COLLECT (needs changes), 
MAP and EXTRACT.

Brian, I read it and the option I believe should be default behavior 
is for the original series to be modified.

BrianH: I'm 100% for /into and, if possible, it would be one of my 
top features to backport to R2.

No, those are modifier functions. We already have those, and the 
algorithm for implementing a modifier is completely different than 
a builder. Some functions (like DELINE) could be changed into modifiers 
with /no-copy and that wouuld make sense. It doesn't make sense when 
the builder is creating something based on a spec or template, which 
often has a completely different datatype than the result. For these 
functions an output buffer makes more sense.

Modifiers and builders are completely different classes of functions, 
with some overlap (see DELINE or REPLACE vs. REWORD). When the function 
is making a copy of the spec with some tweaks, a /no-copy option 
makes sense, or a completely separate function with complex mezzanines. 
When the builder function creates something really different than 
the spec (like ARRAY or READ), there is no point to a /no-copy refinement 
since there is no eqivalent modifier even in theory.

That is the difference between /no-copy (which turns a builder into 
a modifier), /copy (which turns a modifier into a builder), and /into 
(which makes a builder insert into a provided buffer instead of creating 
its own series).

Brian, now you say it inserts. Does it clear the series and inserts, 
just inserts or overwrites the existing content?

Henrik: Inserts and *doesn't* overwrite the existing content. Paul: 
Yes.

The functions for which /into would give us the absolutely biggest 
bang-for-the-buck are REDUCE and COMPOSE. Have you ever done chained 
calls to INSERT or APPEND of intermediate blocks created by REDUCE 
or COMPOSE? All that code goes away.

Henrik, the trick is that it would work *exactly* like INSERT. If 
you want to replace the contents, CLEAR or REMOVE/part it yourself. 
If you want it on the end, use TAIL. If you want to chain, go for 
it. The calling code can manage their buffers however they want, 
and we can provide buffer management helper functions if we need 
to. I did extensive testing and INSERT is the most general function 
to model after.

Give me a moment and I'll show you an example, using variants of 
the COLLECT function.

; Here's a version of COLLECT without /into, a typical example of 
a builder.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/local output
][
	output: make block! 16
	do func [keep] body func [value /only] [
		apply :append [output :value none none only]
		:value
	]
	output
]

; Here's COLLECT with the /into option.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/into "Collect into a given series, rather than a new block"
	output [series!] "The series to output to"
][
	unless output [output: make block! 16]
	do func [keep] body func [value /only] [
		output: apply :insert [output :value none none only]
		:value
	]
	either into [output] [head output]
]


Note that the version with /into also lets you use other series types 
than just block!. This option added to REDUCE and COMPOSE would let 
you create parens and paths as well, even though REDUCE and COMPOSE 
can only take block! specs.

The overhead of /into is two comparisons per function, and one assignment 
per insert in the function. Really low.

There aren't many applicable mezzanine builders right now - just 
COLLECT, EXTRACT and REWORD (proposed) - so the REBOL /into overhead 
will be small. And when more REBOL builder functions get made, we'll 
be able to make them more efficiently.

It's already done for REWORD, which is blocked because of critical 
map! bugs. An easy addition to EXTRACT and tweak to COLLECT.

EXTRACT and COLLECT enhancements submitted.

New discovery: You can assign an op! to another word and it still 
works as an op!, infix style. Want to rename your ops? Now you can 
:)
>> &: :and
== op!
>> false & true
== false

New discovery: APPLY treats 'a and :a parameters like a, ignoring 
the special treatment that specifying parameters that way would otherwise 
give you. This is a great thing: Now you can write functions that 
function values without the code injection risk that those special 
parameters have.

Janko, to reanswer your question: "will R3 have a way to define custom 
infix words?"

Yes, at least custom words to refer to existing infix functions for 
now. In theory this new behavior could be used to make new op! functions, 
but there will likely not be a facility to do so until the plugin 
model is finalized, and the redirect-to-an-action functionality may 
remain even then.

Yup. And then are they still infix?

APPLY is good for wrapper functions, and now for using function values. 
From COLLECT:
    output: apply :insert [output :value none none only]
From USE:
    apply make closure! reduce [to block! vars copy/deep body] []
From ACCUMULATE:
    value: apply :fn [:value series/1]

huh.... I see rebol has many intereting words that I haven't even 
known about what even thought what they alow me to do .. like these 
that you mention apply and collect

But you don't pass the function spec, you pass the function value. 
The function spec is the block with the parameters, types and doc 
strings. The function value is the value that gets assigned to the 
word that is used as the name of the function, it any.

Brian .. some most certanly a crazy question ... is there a way you 
could walk/execute a block of code in steps ... this is probably 
possible (if they take no arguments)  [ func-1 func-2 func-3 ] ... 
but is there some "magic" way to execute make func consume their 
arguments, like this >> b: [ print "hello" add 4 6 ]<< and >>do get-expr 
b 1<< would print "hello" and >>do get-expr b 2<< would calcualate 
10 ... I know this is probably not even remotely possible

DO was rewritten in R3, and not all of the old behavior is implemented 
yet. Though there are some intentional differences.

LOAD was rewritten too, as a mezzanine, by me. There is still some 
missing functionality, and some fixes to bugs in R2's LOAD.

so code is a code block and value is something that has a result 
that code block would return if I do it at the end ?

it works here too.. one strange thing is that at the last do/next 
I get right value for the end of the block and if I do/next again 
that value get's unset (I didn't know that is even possible) >>>value
** Script Error: value has no value
** Near: value<<<

I thought I will ask a very very stupid question and it turns out 
this is very nicely possible already

yes, it looks like that .. I will try to make a simple step-blocks 
function and see what it does

if you would want to switch you could also step until you hit a certain 
word probably and then switch to other funct

With DO/next and pseudothreads you could do full fake cooperative 
multithreading.

Sorry, meant Protothreads: fake threading done with macros and special 
tricks. A C version: http://www.sics.se/~adam/pt/

Contiki is used by smart sensor arrays and such. Pretty hard-core 
stuff.

Well, I mostly play with mezzanine and library code and backports, 
then generate a *ton* of bugs and wishes in CureCode about fixes 
for or enhancements of natives. Because I tend to be public with 
my work, that's what you see. Carl is mostly working on the new DevBase 
right now (and possibly articles and interviews). Once the new DevBase 
is up and running the source will be posted to it, then we can all 
work on stuff.

Add file management to RebDev and you have the new DevBase. "RebDev" 
was always a codeword - the real name is DevBase.

Or it will be when Carl finishes with the file stuff, and some stability 
fixes.

There may be, and it could be useful with /skip.

That's REFLECT and its associated *-OF functions. Yes, gradually, 
as R3 gets fuurther along. The backports can be used with existing 
releases though - I'm bundling them all into %r2-forward.r.

Also the proposed QUOTE and ACCUMULATE.

and ACCU ?

Yes. Reason: To simplify and speed up MAKE, and REBOL, and to make 
code generation easier.

No, it's not, but not by much and it's necessary for the /into option.

Strangely enough the REBOL overhead of the /into option (one UNLESS, 
one EITHER, and n assignments) is dwarfed by the overhead saved if 
the /into option is implemented pervasively.

and you say that foreach is slower than forall in this case ? (overhead 
with 3 path evaluations block/1 , no ?)

For GATHER? Should I just copy your code and credit it to myself? 
:-)

And 10 lines for signatures.

Would you need a /reverse option? ACCUMULATE is already almost as 
fast as we can make it in REBOL, and more options would slow it down. 
The only way we could speed it up more now is to fix an APPLY bug 
with op! functions.

I apologize, ACCUMULATE is whichever version of fold that starts 
at the beginning and ends at the end of series (left? right?).

Mostly Carl, though Gabriele and Cypher also work on the C-level 
stuff. I mostly know about the C stuff because I get involved with 
the discussions and remember them. Also many of the C-level changes 
to the core functions (not graphics or ports) were based on discussions 
I started.

If the data from users R3's command are correct, Gabriele last logged 
in 31 days and Cyphre 7 days ago. Both were here today.. so it was 
not good example:)

Yes, but they haven't been involved with the discussions that resulted 
in the core changes and new functions of the last year.

I was just wondering, it there is someone else "who know the internals"... 
I know that Cyphre is waiting for new sources from Carl to do something. 
And of course it's good to have a place where one can write message 
to Carl and with a feeling, that Carl will read it one day.

Right now Carl is busy getting things in place to get the source 
out. Then we can discuss native changes that *don't* affect core 
code. We have already been discussing native changes that *do* affect 
core code, here and in R3 chat, a lot lately :)

If you look inside devbase you can see kind of DB there, but finally 
it should be a Module with methods, or Protocol with functions both 
simple and for general use IMHO.

I've just been reading a little about something called Unobtrusive 
Javascript which aims to separate the behavior from the structure 
of html document.  


Doesn't VID suffer with the same problems where behavior is closely 
tied to the structure of the GUI?  And shouldn't we be looking at 
also solving this problem?

And the same for every other possible event?

But I know what you're saying. You probably want such a function 
built in and used in the examples, so it becomes commonplace.

Function name and arguments?
set-actions: func [window actions ...

and there's also passing the face correctly to the actions

I'd also like to have it so that we don't have to name objects and 
can point to them based upon order ...

I've spent some time thinking about that in the past, and it's difficult, 
if not impossible.

in case we wish to dynamically insert objects into the display and 
then remove them as they do in Javascript

Eg.  I like to create tables first as instant feedback, and then 
fill them with data from an async function.

So, above, during code maintenance any number of extra fields can 
be inserted before my-text-list and it won't affect the actions assignment.

we could just use order ... and not names

And lit-words ? Another idea might to use them to identify the name-references 
(not the element types). eg

For quick little layouts we can see that the separation, with all 
those extra nested brackets and interpretation requires extra effort. 
But for large, complex layouts, the separation must have some benefit.

The reason is that there is an extra name reference needed to associate 
the action to its element, because they are now separated. In large 
layouts, the separation of structure and behaviour puts these closely 
related aspects further apart, so it means more scrolling.

Well, I think it can pretty easily be done for your own forms, by 
making a function that accepts an action specification, as above. 
Apply it to your forms and that's that. Eg. if you could say:

	window: layout [ ...text-list ... ]
	set-behaviours window [ text-list [...] ]
	view window


Wouldn't that be almost as good (if not better) than any built-in 
inline action specification ?

I am sorry for my extreme oppinion on this subject but I think "unobtrusive 
javascript" was invented when web2.0 got hip and cool and when web 
designers started coding. To me as a user it meant that basecamp 
blocked my whole browser (even the mouse pointer didn't move) on 
every page reload for 1-2 seconds (while js was attaching events 
to all the nodes).

gmail / google calendar were the apps that pushed the edge of what 
client with js+html can do and look how unobtrusive are they

No problem , I said I have a little exptreme oppinion on this, and 
extreme opninons are usually not correct ;) . But I think "unobtrusive 
javascript" is an extreme option too, I believe that eingeeners have 
to find fastest, cheapest, most robust and mainainable solutions 
that *work the best* for their problem. But something like UJS is 
a label or an ideal that you can hold to in your work and more you 
hold to it better you are from this ideal's viewpoint, but I like 
to be more flexible. I will adhere to it or only so far as I think 
it get the best coctail from the 5 points I mentioned above.

I think the web is a special case though.  I don't think there is 
any other environment where language interpretation varies so widely, 
and where binding the language can have harmful effects.  Yes, heady 
concepts are not always pragmatic, but the short road to pragmatism 
on the web is fraught with pitfalls.

G&A: I'd like separation too - in the long run, it makes for code 
that is easier to adapt and maintain, and allows you to refine language 
around the individual components

First, I think JS is not something we should look at for models. 
It's new enought that it is just going to reinvent what's been done 
before, unless they come up with something truly revolutionary, and 
my gut feeling says that's not going to happen. It also depends on 
what kind of apps you're writing, and what you want the language 
to hide from you.


What's been done before that works, or not?  MVC has seen a resurgence 
with RoR and other frameworks being built on it. 


Now look at a low level approach, where you handle the main event 
loop yourself. Anyone remember writing C programs for Windows early 
on? Maybe some still do. You had a huge switch statement to dispatch. 
On the downside, that was hideous to read and maintain. A benefit, 
though, was that you could hook into it very easily, because it wasn't 
spread throughout the app.

Then there's the whole VB/event-driven model.


R2+VID is wonderful for very simple things, because you don't have 
much to do, actions are right there with their faces, etc. It starts 
getting in the way when you build larger apps that need to track 
relationships between faces and such. And it is not well-suited to 
large apps, just like REBOL itself. It doesn't provide the organization, 
tools, and features needed. Of course, we can build all that ourselves, 
if we have the inclination. RebGUI is the best example of that.

I like the idea of apps based on FSMs and message dispatch. That 
means simple apps aren't nearly as simple anymore, but it gives you 
the tools to build bigger things. It's also a different way of thinking, 
which can be hard to get people to accept. 


Anyway, rather than asking if UJS is the right model, we first need 
to ask what our goals are.

The "separation of form and function" principle has already been 
implemented with the separate style system.

But that is not the "Unobtrusive Javascript" metaphor, it is more 
like the separation of HTML and CSS.

(sorry, I was busy). Imagine if you took the structure/appearance 
separation of HTML/CSS to the extreme, and had *no* appearance code 
in your layouts, just behavior and structure. Put all appearance 
code in the styles. That's the R3 GUI. Oh, and the styles will be 
themable too.

Behavior and structure are together in the layout, yes, but in a 
way that is easily seperable. And that doesn't matter because the 
layout won't have appearance code in it.

( I keep switching between UK and US spellings ... )

Well, I've done that in my own VID extension kit (which I'm still 
contemplating whether I will release some day): Provide more styles 
with very specific purposes. This strongly reduces the need to be 
specific many times all over a layout and the layout becomes much 
smaller and cleaner. Also avoiding stylize inside the layout helps.

we have close buttons, and ok buttons etc.  Can we define them on 
the fly for the scope of the window?

and if you want both?

It's so tempting to set colors and styles directly in the layout, 
because it's quick to prototype with, like in R2 VID, but once your 
layouts grow, you really want to get rid of those appearance decisions.

you could describe in your layout code that it's a SAVE-BUTTON style 
and nothing else. then in your style code, you add logic to change 
the color depending on the state of your user's need to save content.

Might be interesting to build a little check box into buttons you 
have already pressed and completed (or something).

People liked it, and I plan to bring it back.  We got rid of it for 
another reason, but I did like it.

When I worked on airplane interfaces we did everything in BLACK and 
WHITE.

we will get sued, because people will be distracted by our pretty 
UI and spill hot coffee in their laps.

Make a button a shade of the BG colour, and do nothing.

Also, a way to view all buttons, and assign keys.  This should be 
system wide.

And I guess you change them for whatever language you use ...

shortcuts, and language need to be unified and solved...