AltME groups: search

Ladislav, in answer to your first question about "We should allow 
one iteration when start = end, but trigger an error otherwise if 
we have a non-advancing step.", yes. That is the difference between 
the two models in that ticket. 0 bump should behave consistently, 
according to a model which makes sense.


In one of those models, the bump is given primacy over the start-vs-end 
factor, and judged *on its own* a bump of 0 is an error (since it 
doesn't make FOR advance in one or the other direction). So, that 
error should be triggered categorically before the range is even 
considered.


If, on the other hand, start-vs-end is given primacy, then we have 
3 valid answers to the direction argument: forwards, backwards, or 
once - the bump argument doesn't determine direction, it determines 
velocity in the direction already chosen. In the start=end case the 
bump is always ignored, so ignoring it for 0 makes sense. In the 
start<end or start>end cases, a bump of 0 is basically out of range 
because those cases are only defined  to move in the positive or 
negative direction, respectively. That means that start<end is only 
positive, and start>end is only negative.


Does that make the difference between the models clear? Of course, 
because you can BREAK, CONTINUE, or even set the index position in 
the code, that doesn't actually reduce our flexibility where we really 
want to do anything interesting. It just makes the basic model make 
sense.

However, I must agree with Fork that we need a general loop in Rebol 
no matter what. (see e.g. iteration in the decimal range as an example) 
Just the dialect he proposed does not look sensible to me when compared 
to the general loop I am using for a long time.)

I think that something as powerful as yours, but maybe a little friendlier 
for the newbies, and maybe with some REWORD-style thoroughness, might 
work. I think that we need to go beyond the old style of general 
loop though - we're competing against languages with list comprehensions, 
not just C-like languages :)

So it's not a power thing. Cool.

It's a dialect thing then.

Just as another perspective: COLLECT + FOREACH is a powerful, easy, 
and flexible list comprehension-like alternative.

I use COLLECT + FOREACH a lot, as well as COLLECT + PARSE.

Ladislav, that's a feature list, not a dialect. It's a great feature 
list, and when we're building the dialect we should take all of that 
into account. But what you suggest in CFOR is not much prettier than 
FOR, and is almost as ugly as C's for loop. It's powerful, but not 
something we can point to and say "Look at how powerful we are!" 
to people who don't understand that surface stuff doesn't matter 
when you're talking about power. Imagine people who haven't heard 
of big-O notation or Turing completeness, but have used Python or 
Ruby. Especially Ruby because of how pretty it is but how much it 
sucks beneath the surface.

Ladislav, that's a feature list, not a dialect.

 - sure, feature list is not a dialect. CFOR is a dialect, though, 
 exactly like there is an object specification dialect or function 
 specification dialect. The fact that you do not see it is a dialect 
 does not matter at all

No, I see that, it's just not necessarily a very good dialect in 
the sense of dialect design. It's powerful, but not clean enough.

We have some more flexibility here because we can't actually do this 
as a mezzanine, it has to be native code (no [throw]). So let's take 
the opportunity to make it really nice.

Btw, REWORD has a #539 problem too, as of the http://issue.cc/r3/1990
changes. Those new features need [throw] to work peoperly, or a native 
implementation. Oh well, that's the price of a powerful dialect sometimes.

CFOR, EVERY etc

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions -- just have to set words 
to values.

For me, the syntaxtic sugar neatness of the new proposals is outweighed 
by the simplicity of the setup for the existing method.


No real opinion on how to standardise the existing behavior other 
than to reiterate a point Brian has already made: FOR start and end 
can work on series too; all the examples I've seen of proposed change 
behavior is for numbers. We need to ensure thar series FORing works 
as expected too.

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions 

 - this looks like you never used CFOR, otherwise you would have know 
 that it does not require anything of that kind

Ladislav, in your latest FOR notes, is your last case [for i 1 1 
0] an infinite loop? I changed %new-loop.r to reflect your design, 
but tripped over that and wanted to clarify. Is this a correct interpretation?

Normal termination
    [loop [i 1 2 1]  [print i]]
    [loop [i 2 1 -1] [print i]]

Should not start
    [loop [i 2 1 1]  [print i]]
    [loop [i 1 2 -1] [print i]]
    [loop [i 1 2 0]  [print i]]
    [loop [i 2 1 0]  [print i]]

One cycle
    [loop [i 1 1 1]  [print i]]
    [loop [i 1 1 -1] [print i]]

Infinite loop
    loop [i 1 1 0]  [print i]

It was just this one case, which I think differs from Brian's model.

 - that is not true, in fact. Brian stated arbitrary rules like "for 
 i 1 1 whatever [...] should loop exactly once", that is a difference 
 as well

Having any termination test that can happen only if there is:


a) no adjustment of the cycle variable in the body changing this 
"expectation"

b) the bump is 0, which, of course, cannot change the termination 
test result when the variable remanins unadjusted

Brian, your arbitrary rules don't make sense when observed from the 
"termination test" POV. There is no termination test that can yield 
TRUE and FALSE being run twice in a row and not having changed inputs

And if it should *not* be infinite, is it a "should never start" 
case, or a "once only" case?

Once you get past the initial conditions then everything after that 
is affected by the direction, the bump and the code block. But we 
have to assume that start, end and bump could have come from the 
result of a possible erroneous calculation based on crappy data. 
The initial conditions guard against that. Ladislav, every code example 
you give that sets the index in the code block is considered intentional 
behavior. It is only start, end and bump that are considered possible 
out of the developer's control. If a developer passes an unknown 
code block to FOR then they deserve what they get.

This is a common factor in all of the R3 control functions. The body 
blocks are considered to be under developer control, while calculated 
intial conditions are considered to be possibly out of their control.

Um, no, because it doesn't handle the problem of making sure that 
accidental infinite loops aren't screened for. The termination condition 
that would be affected by bump=0 in your model could also be affected 
by index changes in the body. Everything in the body is considered 
intentional. So, you are lumping in presumed-intentional infinite 
looping with presumed-unintentional infinite looping. It's the same 
reason why FOREACH [] data body triggers an error, but FOREACH [a:] 
data body doesn't.

For instance, you might noting that FOR has a lit-word parameter 
for its index. That makes the word peovided considered intentional, 
because you have to do an extra step to not know which word was provided. 
And in general, people are presumed to know where they get their 
code blocks from.

In the constrained #1993 FOR, the constraint is a feature. It will 
protect you from infinite loops that you don't intend, regardless 
of what start, end and bump say. You would have to go out of your 
way to make an infinite loop, by setting the index in code that you 
wrote. That way, you know you can safely call FOR when you don't 
even know what start, end and bump are.

Well, that difference is a downside to CFOR, but the upsides outweigh 
it so I prefer #864.

You are just not used to writing code with bugs in it Ladislav. You 
don't understand how constraints can be a benefit.

Also, (just a warning). If you still want to allow cycle variable 
changes you do need to have the means how to determine when to terminate 
and when not

That wasn't a comment on the inconsistencies, that was an answer 
to the previous message where you said "the best what can be done 
is to not use the function at all." - I was agreeing with you in 
the infinite loop case, and giving my reasons why.

We are giving developers more control by saying that some stuff is 
under their control (i.e. the code blocks). We are providing some 
safety by saying that some stuff is presumed to be not under their 
control and thus possibly suspect (i.e. immediate-evaluation parameters 
to functions that they didn't write). We do screening of some stuff 
because that cuts down on the screening they have to do themselves. 
That way dvelopers can use functions and assume that they are safe 
to use by default.


For instance, one advantage of #1993 FOR would be that they would 
have to go out of their way to make it do an infinite loop, since 
no combination of start, end and bump would generate one. That means 
that they wouldn't have to wrap calls to FOR in expensive conditional 
code, they can just pass in any values of those parameters and trust 
FOR to never go infinite without them expecting it. Your CFOR would 
not have that advantage, but since it takes code blocks for all parameters 
it is assumed that you are more careful about those code blocks, 
as you should be as a general rule in R3.


It's about providing a balance. Complete consistency in how all parameters 
are treated regardless of their nature would not allow us to help 
developers where they need it. However, having a consistent policy 
that code must be treated more carefully by developers than non-code 
allows developers some flexibility while still allowing them to be 
careful. That is why code that developers provide explicitly is considered 
to be what they want to do, at least from the outside of functions. 
And you can make the distinction between code and non-code using 
simple type tests, which is why we have APPLY and ASSERT/type.

But that sill does not solve the case of finite loops, does it?

 - well, you could have really large finite loops that on a pragmatic 
 level are close enough to infinite to still cause a problem. I think 
 that there is a global evaluation limit that is supposed to protect 
 you from that, but I don't know if that currently works.

Really? Because I was assuming that FOR would have termination conditions 
(similar to yours). The initial conditions model just picks which 
set of termination conditions to apply, at least as far as the start, 
end and bump parameters are concerned. The body parameter, being 
a code block, is assumed to be under developer control. So if the 
developer wants to hack the termination conditions in the code block 
that is their fault.

FOREVER is assumed to be a solicited-for infinite loop, because it's 
right there in the name. #864 is assumed to be whatever the developer 
says, because "General loop" is right there in the doc string. #1993-1994 
FOR has the *feature* of not *accidentally* being infinite for any 
value of start, end and bump, its constraint is a feature; of course 
it could be *intentionally* infinite by changing the index in the 
code block, but that just means that there is one parameter that 
the developer would have to be careful about, the body block, and 
since that is a general pattern throughout R3 they would be doing 
that anyway.

Assuming that we are discussing #1993 and assuming:


* you insiste to allow the FOR I 1 1 0 and similar to be "infinite 
by default"

* want to support cycle variable changes in a simple and consistent 
way

the best you can do is to cause an error when finding out that

    all [start = end bump = 0]


is TRUE, since in that case there is no reasonable terminating condition 
that could not cause infinite loop by default. Some people may object, 
but otherwise it looks as not a big deal.

The fact that we even have a FOREVER loop at all means that there 
would be a value in having developers use it, just for their own 
documentation.

We've been trying to reduce the amount of expensive conditional code 
throughout R3. That's why a lot more functions allow none now.

BrianH: I'm really glad to hear that there is a concerted effort 
to reduce the amount of expensive conditional code throughout R3. 
 Great job all!

Depends on the model. If bump is a velocity, you can say that only 
velocities above (or below of you're going in reverse) 0 are in range.

That is a matter of coming up with a plausible theoretical explanation 
for something that we want to do for practical reasons.

Then start-vs-end sets the direction, and bump sets the velocity. 
It's just a way to explain *why* to newbiees.

Dealing with the consequences of triggering an error is more expensive, 
so we tend to only want to trigger errors when they really *are* 
errors. If there is a plausible way to just do nothing and/or return 
none when it's not potentially damaging, we should come up with a 
rationale that lets do that instead.

It's really a rationale.

We can just arbitrarily declare that we want 0 velocity to be considered 
out of range, as a favor to the developer, and the velocity explanation 
gives us a good excuse to not trigger an error. FOREVER existing 
means that they have other options, and index setting means that 
they can do whatever they want if they really want to, so it's not 
actually a constraint if they don't want it to be.

You can always declare something arbitrarily. The problem is that 
if you do declare a + b = none in case a = 0 you are most probably 
causing inconveniences to all people knowing that there might have 
been a more consistent behaviour...

Remember, #864 is a proposal to replace FOR with a more flexible 
power-user function that would be less safe to use. They lose some 
safety as a tradeoff for more power and prettier sytnax. So, they 
lose two features (safety and backwards compatibility) but gain more 
flexibility. The greater flexibility would come at the expense of 
a slower function: negligably in the case of the function itself, 
but more when you add the conditional wrapper code, so it would have 
to be used carefully if you want it to be efficient. Overall, that 
is the R3 motto right there: R2 is for newbies, R3 for power users.

Brian, for that case, does your model make it a "no loop" or "once 
only" condition?

For the bump-sets-direction start-and-end-set-the-range model, 0 
doesn't set a direction so it should trigger an error. Otherwise, 
the same.

Let me fix some comments above:

; start < end, start is bump > 0 and x >= end, termination is x >= 
end

; start > end, start is bump < 0 and x <= end, termination is x <= 
end


So, the direction sets the termination condition, and the bump sets 
the velocity that the loop is advanced between iterations, with range 
limits on the velocity as a starting condition in addition to the 
end range limits.

If you get a chance, it runs the tests and just outputs to the console, 
so you can, I hope, see quickly where it goes off.

Is there even a significant number of existing R2 users who even 
use FOR at all? I mean, it really was crappy in R2. I definitely 
want to fix this in rebol-patches just on general principle, and 
likely R3/Backwards too since they're supposed to be compatible with 
each other, but does it even make sense to have a regression test 
for R2 if we're not going to have new versions? Are the R2 tests 
supposed to be testing rebol-patches and R3/Backwards, or new R2 
versions that may never exist?

Over 10% of scripts at Rebol.org seem to use FOR. (135 out of 1152).

That's an upper bound as there may be a few false hits if someone 
is using 'for as a word etc....The search URL below finds the word 
FOR where it is in the body of a script (ie not in a comment, string 
or header)

    www.rebol.org/search.r?Find=[b]for

And =end is not a termination condition because you want the cycle 
to run at least once

Brian, =end is not a termination condition, see these examples:

for i 5 5 1 [print i i: -5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 3] ; this should be print 5 and terminate
for i 5 5 1 [print i i: 4] ; this should be an infinite loop
for i 5 5 1 [print i i: 5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 6] ; this should print 5 and terminate

and, of course, it is immediately obvious why =end is not a termination 
condition then

Is this a bug?

>> val: [a b c]
== [a b c]

>> val = [a b c]
== true

>> switch val [[a b c] [1]]  
== none

Looks a bit odd.....

In R2 it doesn't work if the val is a block! but it does with hash!
In R3, block! doesn't work but map! does

Test code:
   val: make map! [1 2 3 4] switch val reduce [val [print 1]]

BrianH: I used 'for quite a bit in R2.  But I used it simply when 
I needed access to a counter.

'Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.'  a couple of notes:


- you still don't get that if you are not consistent producing a 
lot of exceptions your code will be full of bugs and arbitrarinesses 
(there is absolutely no escape from this)

- you still don't get that there are concrete examples above demonstrating 
the problems you did not even consider yet

Also, saying that a cycle runs exactly once (which is, thus, independent 
on the cycle body) is too inflexible to not be considered just a 
bug  when knowing that the cycle varialble may be adjusted in the 
cycle body

At a quick glance, I believe for FOR and my LOOP have the same behavior, 
though I didn't address overflow as an initial goal.

And mine uses CFOR as the internal loop handler. As I noted briefly, 
it's just a dialect wrapper over CFOR.

You lost me. Do you mean CFOR can't spare the effort to do the checks, 
or you can't spare the effort to create a version of FOR that uses 
CFOR?

For those not following closely, the discussion about FOR is trying 
to clarify and document its behavior, while keeping it easy to use 
(e.g., avoid accidental infinite loops). Ladislav has also asked 
for better names for CFOR, his general loop func that is efficient 
and flexible, but requires a bit more care in use. There is also 
a general consensus that FOR takes more args than we would like, 
while noting that we have other looping funcs we can use in most 
cases.


I propose a new LOOP implementation that is compatible with the current 
LOOP func (and delegates to it internally), while also providing 
a dialected interface which is a wrapper to CFOR.

Goals:

* Provide a general loop that is both friendly and flexible
* Support multiple datatypes as FOR does today
* Use CFOR internally for efficiency
* Adhere to the latest model discussed here and on CC

Interface:

LOOP compatible
    [loop 5 [print "x"]]
REPEAT compatible
    [loop [i 5] [print i]]
CFOR compatible (except for all args being in a block)
    [loop [[i: 1] [i <= 1000] [i: i + i]] [print i]]
FOR compatible (except for all args being in a block)
    [loop [i 5 10 2] [print i]]
Like FOR, but with a default bump of 1
    [loop [i 5 10] [print i]]
Or -1 if start is greater than end
    [loop [i 10 5] [print i]]

You don't need to look at %new-loop.r, but if you have any input 
on the above interface approach, or just want to post a NEW-LOOP: 
+1, -1, or 0 message, that would be great.

Nice work, Gregg - thanks for doing all that.


I am having trouble getting LOOP to do what  FOR can do with a series:
    ser: [1 2 3 4 5 6 7]
    for v ser skip ser 5 2 [print v]
        1 2 3 4 5 6 7
        3 4 5 6 7
        5 6 7

Neither of these work for me:
    loop [v ser skip ser 6 2] [print v]
    loop compose [v ser (skip ser 6) 2] [print v]

Good catch. I just added series support, and since it's a simple 
dialect, it won't like that. In the current version, you would have 
to use an interim var for 'end. e.g.:

>> b: (skip ser 6)
== [7]
>> loop compose [v ser b 2] [print v]

Thanks Gregg.

If FORing on a series is relatively uncommon, then (per curecode 
#666) losing the direct ability would be a good R3ish thing to do.


I am little more concerned about LOOP set up needing COMPOSE in a 
way that existing looping constructs do not. The cost of creating 
simplicity in the language core should not be exporting complexity 
to the language users.

another contribution:
	use [count inc start end op][
		count: inc: start: end: op: 0	
		in-range: func [
			[catch]
			'word [word!]
			start [number!]
			end [number!]
			/bump step [number!]
			/local result
			] [
			if inc = 0 [

    if step = 0 [throw make error! "step parameter cannot be = 0"]
				count: start

    either start > end [inc: -1 op: :greater-or-equal?][inc: 1 op: :lesser-or-equal?]
				unless none? step [inc: step]
			]
			set word count

   result: either op count end [count: (get word) + inc true][false]
			if not result [count: inc: start: end: op: 0]
			result
		]
	]
	i: 0 ; define a var
	while [in-range i 1 3] [print i]

about the Gregg's loop (on Rebol 2.7.8.3.1):
>>  probe cfor [num: 1] [num <= 3] [num: num + 1] [print num "a"]
1
2
3
4

??


>> probe cfor [num: 1] [num <= 3] [num: num + 1] [if num = 2 [throw 
make error! "what 2?"] "a"]
; nothing printed nor error report

The existing LOOP is used quite often, so any replacement for it 
won't go in R3 by default. However, the main reason LOOP is used 
is because it doesn't have the overhead that a lot of the other loops 
have, less than the other natives even. Its simplicity and definite 
form are its strengths - a loop with a more flexible form would be 
need to process that flexibility at runtime, which would add inefficiency 
that could easily be avoided by making that choice at development 
time by choosing the loop that meets your needs. And any loop construct 
that requires any kind of manual reducing of its arguments in order 
to have it take the result of an expression is a definite no-go. 
I just got rid of that in REWORD.


I like http://issue.cc/r3/884as a replacement for FOR. It keeps 
the local binding (unlike Marco's CFOR above, sorry) and is flexible 
in behavior without being flexible in form (it has a very simple 
implementation).

Watch out though, all mezzanine control structures that execute code 
blocks passed as parameters are be subject to http://issue.cc/r3/539
so they would need to be native until we have a solution to that. 
And not a command, because the necessary internal stuff isn't exported 
(purposely), so you couldn't do REWORD as a command.

In rebol 2.7.8.3.1 the #884 version has the same "strange behaviors" 
as the one that Gregg posted as a file here.

I just updated it to fix a couple more bugs; haven't read any of 
Gregg's comments so I don't know what those strange behavior are, 
but they might be fixed now. I am more a fan of its API style - we 
can fix any internal problems.

I had to get rid of [catch] in my first edit. And [catch] is a bad 
idea for loops because it hides where the real error is being triggered.

Better to test it in R2 then to not test it at all. (By the way on 
R2 mine is a little faster).
I changed :ret to get/any 'ret and it works but in R3 :
>> do [cfor [num: 0] [num <= 3] [num: num + 1] [num]] ; works?


and why is it important to keep the local binding ?(I am not an expert 
of binding)

Sunanda, agreed on not export complexity. Words are supported directly, 
and we can look at making everything easy that it should support. 
Today, words are supported. e.g.:

a: 1
b: 5
loop [i a b 1] [print i]


Series values, as in your first bug report, are the thing I have 
to look into. Beyond that, should it just evaluate everything it 
gets?


Marco, FOR-STEP sounds too close to FORSKIP to me. Have to think 
about how FORSKIP fits in to the model. For that, and IN-RANGE, the 
main question is what their purpose is. On your first CFOR tests, 
I get these results:

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num "a"]
1
2
3
4
== 4

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [if num = 2 [throw 
make error! "what 2?"] "a"]
** Throw Error: ** User Error: what 2?
** Near: throw make error! "what 2?"

@Gregg: >> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num 
"a"]

for me it should print: 1 2 3 and give "a" as the result (as it does 
#884 NOW ;) )

@BrianH, when you say "And any loop construct that requires any kind 
of manual reducing of its arguments in order to have it take the 
result of an expression is a definite no-go.", does "manual reducing" 
mean having the user do it? e.g., if I get a spec passed to my dialected 
LOOP func, and I REDUCE it or DO/NEXT internally, is that a no-go? 
If so, where should I look for the reasons and guidelines about it?

>> checksum/method to-binary "A simple SHA-2 test." 'sha256

== #{E57EBDB51368F9A7ACE63E115193AEAD5E377742E0B4CD6B735CF5AAD49E67EB}

SHA2_Series could switch on width (224, 256, ... -- perhaps defined 
in an enum) rather than a symbol, but this made the logic in N_checksum 
cleaner.

Anyway, this is just a draft.

Arnold wrote (Red group): "R3 should follow this. " - I guess it 
might make sense to write it as a CC ticket (wish). Otherwise, I 
am neutral on this, not needing a shortcut for quit, but a user poll 
(opinions, please?) my reveal that preferences are against Q being 
a shortcut for QUIT.

Neat, glad to hear it. Again, this is just a test; feedback appreciated.

I use q in the console a lot.

q should not be set by default.  anyone can add shortcuts for such 
stuff easily in their %user.r   

maybe we could even add a function which define all the "command-line" 
shortcuts, thus allowing them to be undefined by default.

I think we should consider this heavily. Ladislav's points, and Brian's 
analysis in http://issue.cc/r3/1946make it clear that we need to 
understand the differences, and that we can probably get a large 
gain with very small tradeoffs.

Hello, here you can find a user that have difficulties to build Rebol3 
on Solaris, please mayyou help him?

http://rebol.informe.com/forum/rebol-3-f9/building-rebol-r3-on-solaris-t40.html

otherwise, he could probably make make on a different machine, where 
he can get an r3 interpreter

I parsed out a username @C\u00E1ssio so what do I need to do to show 
this as Cássio on a web page?

It is a great now coming from a great man Cyphre !

I have an updated SPLIT-PATH, modeled on Ladislav's implementation 
where it holds that

   file = rejoin split-path file


This does not match current REBOL behavior. His version arguably 
makes more sense, but will break code in cases like this:

	%/c/test/test2/ 
	REBOL      == [%/c/test/ %test2/]
	Ladislav's == [%/c/test/test2/ %""]


Ladislav's func only seems to go really wrong in the case of ending 
with a slash an that's the only slash in the value which return an 
empty path and entire filespec as  the target.

Schemes (http://) don't work well either.


REBOL also dirizes the file path if it's %. or %.., which Ladislav's 
does not. e.g.

	[%foo/ %../]  == split-path %foo/..

split-path: func [

 "Returns a block containing a path and target, by splitting a filespec."
	filespec [any-string!]
	/local target
][
	either any [
		; It's a url ending with a slash. This doesn't account for
		; formed URLs. To do that, we would have to search for "://"
		all [slash = last filespec]
		all [url? filespec  slash = last filespec]
		; Only one slash, and it's at the tail.
		all [target: find/tail filespec slash  tail? target]
	][
		reduce [copy filespec  copy %""]
	][
		target: tail filespec
		if slash = last target [decr target]
		target: any [find/reverse/tail target slash  filespec]
		reduce [copy/part filespec target  to file! target]
	]
]

The above matches Ladislav's REJOIN requirement, and handles a couple 
edge cases better. I have about 35 tests here, if people want to 
see them for discussion.

It leaves open the question of what the best results are in cases 
where the target is a dir. Should it be part of the path, returning 
no target? Should it be the target? Should it be the target if there 
is no traliing slash, but if there is a trailing slash it should 
be part of the path?

And could/should it be generalized by adding a /WITH option to specify 
a path delimiter other than slash?

why not use %.  as the last element of splitpath in case of a directory?
true = dir? %.

It makes sense to me Anton. I don't know why SPLIT-PATH does what 
it does today, by automatically dirizing that result. If everyone 
agrees, then the next question is whether a trailing %. or %.. should 
be returned as part of the path, or as the target. That is, do we 
presume that they are directories?


SPLIT-PATH, today, returns the last dir in the path as the target, 
if the path ends in a dir. Here are some example values, and what 
SPLIT-PATH returns today.

To me, it's a matter of whether SPLIT-PATH should be consistent in 
how it handles the path, as a string to process, or whether it should 
try to be "helpful". The problem with being helpful is that it may 
make other things harder.

By saying that SPLIT-PATH always behaves the same way, depending 
on whether the path ends with a slash or not, it may not shortcut 
a few cases for us, but it does make it easy to reason about, and 
also to wrap for other behavior. e.g., you can always dirize the 
path before calling it.