AltME groups: search

I looked on rambo and saw no entries for encloak

sorry if I will propose a nonsense, or if the solution already exists, 
but - when using REBOL for data extraction (using parse) and forming 
a block or CSV as a result, I often come to the need of append-only-if-the-item-does-not-exist-already, 
so using following idiom:

if not found? find target value [append target value]


What about adding /not refinement (or other name), so that I could 
append only unique values?

Also - is there any way of how to easily find out, if the block is 
unique? Should I apply 'unique, and compare the length before and 
after? Pity 'unique has /skip refinement, but does not have /compare 
one (as 'sort has), so that I can't set, when I have e.g. record 
of 5 items, I want to 1) set the record size (/skip) 2) select fields, 
upon which we want to define uniquess - could be an integer offset, 
or a block of positions [1 3] ... 'sort allows at least the offset 
via /compare

And I have to think more than twice, when using combination of NOT 
ALL, NOT ANY :-)

Graham, you are not english native speaker? For me it's easy.. I 
learned that UNLESS = IF NOT and so I use it:) http://www.edufind.com/english/grammar/IF9.cfm

I remember UNLESS from extended basic of ZX Spectrum. And I lowed 
the word itself, dunno why :-)

no, sorry ... those are just structures, but blocks contain real 
data, hundreds and thousands of records ...

but never mind, I will use loop and look-up, no problem, just laziness 
:-)

I really think, again, that  'append-or-insert-only-if-the-item-does-not-exist-already 
 should be a native in R3.


its a function MOST of us would use on a frequent basis.  it would 
be very usefull and its very powerfull with a /skip refinement

we can start with a mezz... but because of the find and then insert/tail 
and all the possible refinements its needs to handle... overall, 
it will be faster as a native.

this function will often be used in loops, and the less functions 
and REBOL stack usage you have the bigger the speed gains.

yes and LCD fatique too

I would like to see a version of REBOL where only the bare minimum 
natives are implemented and everything else is a mezz. It's possible 
that REBOL would run many months faster if not preamturely optimized. 
;-)

I'd be interested in seeing how small an executable could be made, 
if utterly everything was stripped, even file and network access.

well, then you can say that you can fit your software on a floppy 
and wave a 5.25" floppy in people's faces :-)

Maybe I did at one time but at my age it's easy to forget! Real easy. 
I just took a look at the reb dictionary and aha! , there it is in 
black and white.

I need some help dealing with paths.

I have a block of sublocks and values refered by words.

I want to make a function that increment a value in a subblock based 
on a process number and a path. But adding subpath to a path seems 
to work only with file! type.

I hope that the code bellow obviously show what I want :

values: [

 1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [process path /local p] [
	p: select values process
	p/(path): 1 + p/(path)
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

Thanks Ladislav and sqlab -- I was having a blindspot about being 
able to directly access the parts of a path.


DideC -- if you need to go to any depth, this version may help (subject 
to optimisation by the gurus):

inc-counter: func [process path /local p] [
    p: select values process
    foreach pp copy/part path -1 + length? path [
        p: select p pp
        ]
    p: find p to-word last path
    p/2: p/2 + 1
]

It's true, I don't want to lose the current behavior.

And Anton gave an alternate solution that is good enough to my mind

but I think too, that SELECT and FIND should be able to process paths 
to look for nested structures.
via a refinement maybe.
Like select/path and find/path

My reasoning is that the effort to implement a lit-integer! type 
is not worth the value the notation provides, at least not right 
now. Once R3 is out, stable, and complete, ask me again. ;-)

In any case, write up a proposal, and RT will make the call. It's 
always good to write things down so we don't forget.

(And it's time to go to the chinese restaurant session of the week)

Cetera censeo, the "two in one" argument passing method is improper, 
and should not be used

when I have used forall (and its really rare, cause until is much 
better, usually) I never use litteral data directly, its always some 
data which is already setup elsewhere.

...and if not, why?

...and I don't think, that an argument "because that is how REPEAT 
differs from FORALL" makes any sense as an argument

remove-each is indeed much faster and it's a native.

not just because its native... its in the way it actually manages 
the removal... it only re-creates the series once, when its done.


using other methods, you are tampering with the series at each change, 
and it has to copy the series over and over.

what I have been explained is that it makes a new series and only 
copies when remove is false.  then replaces the pointer within the 
series to the new one.

Ladislav, one question I've always wondered and I'm sure you know.

Are you sure about that ?
I don't tink remove-each create any temporary buffer.

when I compare the footprint of foreach and remove-each, they are 
the same

(which means nothing, because i don't see why foreach need to create 
so much temporary blocks)

and to continue from that point

and as you say, its a simple added case in the run-time evaluation 
of paths, as well as an additional variation to add in the lexical 
parsing of paths.

Everyone using FORALL to remove more elements deserves what he gets 
(sloooow performance, and complications)

I disagree. Alternatives are not always better.

If I traverse a series and depending of the data, I change an element 
or remove it, then I regard forall as appropriate.

...and it already describes more variants, so it shows how one can 
adjust it

Something to consider:

blk/'a/b
is a valid path today:

>> blk: ['a [b 0]]
>> blk/'a/b
== 0


If ' is made to be an escape, when followed by an integer, then it 
might be a bit confusing. On the other hand, I see lit-paren! as 
an usable new datatype, and in that case, it's kinda like an escape, 
when used in path notation. Something like:

>> blk [(a b) 0]
>> blk/'(a b)

which isn't valid today.

The goal when constructing new languages must be to find the best 
simple ground rules and stick with them. Then new programmers don't 
have to learn all kinds of side-rules and "unless" behaviour.

I do agree with you, and introducing new quoted datatypes you would 
introduce too many such side rules into the language, which I disagree 
with.

you guys didn't solve the "how do we use an integer as a key instead 
of an index"


this is a GAPING hole in path evaluation.  using integers isn't some 
fancy side datatype.


we are not adding a new datatype, its not a complex system like using 
parens (which is also very slow) and it doesn't require advanced 
binding tricks.

no not irrelevent.  we are all users, and some of us agree that this 
is a hole in the design.

Carl isn't all knowing and he has seen the light on many user ideas 
too.

using integers is often the only way get access to huge datasets 
and being able to provide keys.

we are all users, and some of us agree that this is a hole in the 
design.
 - so what? some don't, which proves my point

And, your "integer problem" is easy to solve. I guess, that you are 
so experienced, that you actually *are* able to do it.

you don't like it so its irrelevant.  how can I even start to argue. 
 


All I can say is that I would have used it often in the past, and 
that I support Anton's idea.   


there might be other, better notations, but there should be something 
*native* in path evaluation which allows us to search for integers, 
just like we can search for other datatypes.


something like /a/:1/b  wouldn't be too bad either and it might match 
better the idea of getting the value of 1 but that doesn't work ATM.

I know, but I've never like that :xx is a time... its totally undefined 
...  reading  :1  I don't get any sense of time. 


my guess is that its just a side-effect of how the loader sees : 
and digits .  requiring a number before :  wouldn't invalidate any 
script or dataset that I can think of.

lexicall it realy doesn't make much sense... or does it?

I tend to agree with that. But then we need a new datatype for :1, 
the get-integer! datatype. All such examples points me to actually 
making get-paren! and lit-paren! datatypes, but some see those as 
maybe strange. With get-paren! the path problem could maybe be solved 
as:

blk/:(1)

but I don't see the problem with a lit integer.  how is it any strange. 
 its a label that represents one.  if you evaluate '1 you get 1. 
 


it just allows (programatic) differentiation between a value and 
a number.

when I talk to XML-minded people and tell them that we've got paths 
embeded in the language they always *really* like the idea... and 
I understand them.

I've had to handle datasets that where 10 levels deep.   having to 
stop mid-way... use a select and then start again, breaks the whole 
idea of using paths to begin with.

And it so usual in your datasets that you need integer keys?

it has also forced me to use unfeasible types like issues or tags 
to simulate keys.  but then it requires a *lot* more CPU and RAM.

anyway.. why you simply do add a wish to CC and see what Carl thinks 
about it.

and the parens around this are redundant, for maps:
>> m/2
== "a"
>> m/5
== "b"

I think, that solved the problem althogether. Use map! instead of 
block! for this behaviour. Makes sense to me too. block! is just 
an array, and blk/1, blk/2, ... means 1st, 2nd, ... item in the array. 
For key lookup behaviour, use map!. (Doesn't help in R2 though.)

Let me just make absolutely clear, once and for all; I did not propose 
to add any new datatypes (not lit-integer!, not get-integer! or anything 
else) to Rebol.

First, the only reason for such a new datatype would be for path 
evaluation.

Second, any new datatype with special meaning during path evaluation 
would then suffer the same problem that integer! currently has, ie. 
not being SELECTable; so this would solve a problem only to create 
an identical problem.


So what did I actually suggest? To extend the syntax of paths to 
allow a different evaluation for number values (actually to switch 
off the special treatment they currently get).

Oldes, "Why you just don't use SELECT where you need to select something?"


We can. Of course we can. However, it would be much more convenient 
to use a path in many cases.

Using SELECT:
- Requires temporary variables, breaking up the expression, or
- Requires the complexity of composing a path and evaluating it.
- Either of the above bloats out the code.

The map! behaviour looks like it would probably be good for many 
situations (and probably could have been used nicely in DideC's situation, 
were he not using R2).

However, it would not be convenient to create maps instead of blocks 
in other situations.

Instead of "[...]" you would need at least "make map! [...]", which 
means more code, something I would like to avoid.

btw.. in many case using temporaly variables is not so bad and may 
have better results than multiple deep path queries.

I'm not interested in all the possible cases where using temporary 
variables isn't so bad (or even where it's better). I'm interested 
in those cases, which do come up from time to time, where using temporary 
variables is uncomfortable, and using a path directly to get to what 
I want would be much better (indeed, smoother).

(and faster)

Anton, you may not have proposed a new datatype, but I think, the 
consequence of your proporsal would be a new datatype. I think so, 
because everything the REBOL parser knows, are datatypes. Some datatypes 
are series of datatypes, like blocks, parens and paths. I feel, it's 
a ground rule, that everything separated by slashes in a path, are 
by themselves datatypes.

Gabriele;

About the temporary variables; if you go back to 17-Sep, in DideC's 
original question, his inc-counter function took a path as argument, 
but he had to introduce a temporary variable 'p so he could SELECT 
the integer path member. (And a few other people suggested functions 
doing the same thing.)


Also, note once again -> I did not propose to change the way paths 
currently work with integers. I proposed to *add* a new way to process 
integer path members. This new way does not subtract from any current 
functionality of any significance (that I've yet noticed, anyway).

Geomol, you have not explained why you think the rule you mention 
is a "ground rule" (by which I suppose you mean a fixed rule). I 
read your comment simply as saying that you are resistent to changing 
a rule, but you don't explain why.

Of course, once you accept that the rule cannot be changed, the first 
part of your comment flows logically from it. That's not good enough 
for me, though.

The only argument that I can imagine you might be putting forward 
here is that it's better to keep things simple, rather than add any 
complexity. I am proposing to add some complexity to the language 
implementation which can simplify the use of the language, and, for 
me, it appears to be worth it.

Rebol internals have made themselves visible (eg. end! == first first 
system/words) which I think is used to terminate blocks or lists 
or some other container datatype (perhaps path!), and also there 
are the hidden new-line markers in blocks and lists (but not in hash!).

So, ok, a new "path-escape marker" datatype may need be created to 
implement my proposal, but it doesn't have to be exposed to user 
space.

Because you can easily COPY if you want, but it's hard to go the 
other way. That's the general thinking as I understand it (and agree 
with most of the time).

and 'unique is  .. ?

I think i'd prefer consistent behaviour and not have any modifying 
function of the ones discussed

I prefer the symmetry 

series: sort series

instead of one doing one , and not the other

If one could turn back time, I wonder if {!} for types would be better 
served by some other symbol like {^} , and Rebol could have UNIQUE! 
(modifying) vs. UNIQUE (make a copy) in the style of Ruby and company. 
 "Verbs modify" isn't consistent, since REDUCE or COMPOSE don't modify 
while SORT and REVERSE do.

(In my currently-still-very-limited Ruby tinkering, I have liked 
this convention--and in fact, sort of wished there were some way 
of it being more than just a convention, but reflected in a contract 
which generated both the modifying and non-modifying variant of an 
operation.)

The learnability of consistency vs. the beauty of making the common 
cases and idioms look elegant.   But are those looks deceiving?  
English sure is a mess... but people find it effective.

I think that Rebol already has the "i before e but not after q and 
sometimes z" philosophy, in that there are forces driving it that 
are something of the nature of what drives natural language design. 
 Purely consistent  languages which have no special adaptations to 
the "messy" world don't really need to be designed, they exist mathematically 
already.  They are more discovered than made.

so, modifying the original series is likely to be a convention and 
not an optimization

Anyway, the issue is about the program expressing the intent of the 
programmer and letting the system do the smartest thing under the 
hood given the understanding of what the programmer wanted, for the 
common cases.

and what happens for you?

actually the parentheses should be %28 and %29

Perhaps you want 'run and not 'call ?

I also would love more internal consistency between mutating and 
non-mutating versions (and I'd personally like to have non-mutating 
versions be the default for all functions). But realistically, this 
kind of simplification will never be really an option for future 
REBOL development, I fear.

I don't think the Ruby ! sigil is particularly meaningful, so I wouldn't 
vote for that.


While having complete consistency might make for a more pure and 
mathematically beautiful language, I don't think that is REBOL's 
goal. REBOL's design has elements that exist to make things simpler 
and more obvious. You could argue that complete consistency would 
do that, but if you look at history, that's not the case. 


the argument that sort modifies because you can always copy first 
is met by the retort that you can always assign afterwards

 - You can always assign, but if you have other references to that 
 series, they wouldn't see the change. This can also cause unintended 
 side effects of course, which is the risk of modifying, but that's 
 part of REBOL too. :-\


We'll never please everyone. I'm OK with the current SORT and set-operation 
behavior.

The /into option wasn't added to many applicable natives, just the 
two that generate the most data in REBOL: REDUCE and COMPOSE. That 
might be a "biggest bang for the buck" thing, or maybe we just haven't 
gotten around to it yet. Or it might be a big hassle to add /into 
to a native, so to get it done you need to justify it with use cases.

Time will tell. Like it or not, REBOL is primarily built around mutating 
functions, except for functions that work on immutable values like 
integers. Most of the non-mutating functions we have are either built 
on their mutating counterparts in mezzanine, or are options of those 
functions. In a language with mutable values, mutating functions 
are the base. Functional-language fans tend to not like this (and 
when we start really implementing task-safe code they can say "I 
told you so!"). However, mutability can have advantages too, mostly 
in memory usage and performance, so it's a tradeoff.

(((( I know you don't agree with me, but I want a VM level way to 
define pure functions (that are guaranteed they can't change anything 
outside itself). 

Big future deal in rebol to me is in runtime code generation to express 
things and *code mobility* and there can't be any real mobility if 
the code I get can "get over the wire" can do anything to my system 
))))

/INTO is kind of novel and catchy, in terms of some of the optimization 
scenarios it allows for.  Making variants like "/NO-COPY" winds up 
looking like Rebol is doing a bad job of conventions like REDUCE 
vs REDUCE! ... as opposed to playing a whole different game.

We could only add one behavior for the /into option, and the insert 
behavior was the most basic.

Fork, your method would add the additional series allocation to the 
series itself, temporarily doubling its size (at most). And then 
the reallocated series would stay that size in memory even after 
DEDUPLICATE returns. So overall, worse.

(May have misunderstand what you meant about the algorithm needing 
the original array and a temporary buffer the size of the output, 
as well as the output.)

{See UNIQUE. This function is not widely used in my apps, just because 
of that. Useless, because when we deals with huge series, we don't 
want to pay the COPY cost.} - while this looks like a reasonable 
argument at the first sight, it actually isn't. The reason why is 
based on the way how UNIQUE is (and has to be) implemented. You cannot 
gain any speed worth that name by allowing an implementation doing 
the "UNIQUE job" in place.

Regarding the above, is there a way to reassign and take exisiting 
references with you?   Or, is this a lack of pointer manipulation?

these reduce/into b b and unique/into b b make me wonder, whether 
the people suggesting it really find such crazy code useful?

Rebol looks crazy to most people regardless.  To my midn, if  Rebol 
has so far avoided a convention like /NO-COPY on these other routines 
in favor of /INTO, then consistent and learnable novelty trumps some 
organic evolution of refinements and wording in the core.

I've never had a need for reduce/into or unique/into. The optimizer 
in my brain says reduce/info could be useful, but the rest of my 
brain thinks the lure of possible optimizations will create internal 
strife with said optimizer. :-) I do have an /into refinment on my 
COLLECT func, and the standard COLLECT does as well, but my goal 
there was for convenience is building up results, not optimization.

but the most crazy is not that reduce/into b b "looks crazy", but 
that it is unneeded, and *very* inefficient, unless implemented using 
copying

Anton, I think, it's a "ground rule" in Carl's design of the language, 
that everything entered into the parser are datatypes (or series 
of datatypes). I can't think of anything with semantic meaning, that 
is not a datatype, when we talk REBOL. The language is recognized 
by it's minimalistic syntax. That's why I call it a "ground rule".


I think, it's legal to call REBOL a sequence of datatypes. It's maybe 
more precise than calling it a programming language (also because 
it's so different from traditional programming languages).


And then, yes, he has added newline markers to e.g. blocks. But they 
have no semantic consequence.

Geomol, I thought about it a bit more and realized what you said 
made good sense.

And here's an idea which may make the usage simpler:
Write a function USEPATH, used like this:

	values: [1 [dos [new 0]]]
	p: 'values/1/dos/new

 usepath p [p: p + 1]  ;=== (values/1/dos/new: values/1/dos/new + 
 1)
	values ;== [1 [dos [new 1]]
	
or perhaps, achieving the same result:

	usepath p 'v [v: v + 1]


where v is the value SELECTed by the last element in the path (so 
you can choose a different variable name).
  
or even:

	usepath p 4 'v [v: v + 1]


where 'v is set to refer to the value of the 4th element ('new) in 
the path.

so we can refer to any path element by its number, and so this would 
achieve the same:


 usepath p 3 'v [v/new: v/new + 1]  ;=== (values/1/dos/new: values/1/dos/new 
 + 1)
  
and even crazier:

	usepath p 'root/pid/fs/flag [flag: flag + 1]


where the second path elements (all word!s) reference the values 
actually SELECTed in p,
so these are all equivalent:
	usepath p 'values/pid/fs/flag [fs/dos: flag + 1]
	usepath p 'values/pid/fs/flag [fs/dos: fs/dos + 1]
	usepath p 'values/pid/fs/flag [root/pid/fs/flag: flag + 1]

Ladislav, REDUCE/into is used to eliminate a temporary series allocation 
in the common INSERT REDUCE and APPEND REDUCE patterns. It is used 
in mezzanine code, and does in fact reduce memory allocation overhead. 
Hate to break it to you, but REDUCE/into and COMPOSE/into were actually 
worth adding. Sorry.

REDUCE/into and COMPOSE/into cut down 2 copies to 1. They don't eliminate 
copies altogether.

The main reason that UNIQUE isn't used is because it is not very 
useful: It is easier to make sure that the series is unique in the 
first place. The other "set" functions like INTERSECT, DIFFERENCE 
and EXCLUDE are used more often, even though they do the same copies 
as UNIQUE, using the same hashing method.