AltME groups: search

One of the interesting tradeoff tickets is http://issue.cc/r3/537
- I wrote up the ticket initially and expanded it to include all 
affected characters, but looking at it now I'd have to recommend 
that it be dismissed. If it is accepted it would have the side effect 
that more syntax would be accepted, but all of the newly accepted 
syntax would be hard to read. Accepting that ticket would make R3 
more difficult to read, debug and maintain, so it's a bad tradeoff.

XML is some of the simplest to parse, and I guess schema too.

XML schema validation process is an 80 page document guide and 80 
page reference.  it isn't quite as easy as the xml it is stored in.

Ok, I mix lex and parse. I mean lexical analysis.

XML and HTML are relatively easy to lex, and require Unicode support, 
so hand-written lexers are probably best. Schema validation is a 
diffferent issue.

Most generators seperate lexical analysis and parsing, but I've used 
ones that don't, like ANTLR and Coco/R. There are strengths to both 
approaches.

In answer to your comments link above:
- Syntax errors are triggered before semantic errors: 1.3, 11

- Words that start with + and - are special because of potential 
ambiguity with numbers: 1.1

- Arrows are only allowed in the special-case arrow words, not generally: 
1.2, 1.3, 4

- %: is ambiguous - it could be a file that wouldn't work on any 
OS, or the set-word form of %, so an error splits the difference: 
10.2
- Fixed already: 2.2 for arrows in R3, 7, 13


Some of the rest are related to http://issue.cc/r3/537and others 
have been reported already. If you want 10.2 to not trigger an error, 
it is more likely to be accepted as a set-word than a file. Thanks 
for these, particularly the lit-word bugs.

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

It's for the parse function, I'm working on, and I want to be sure, 
I don't get a local var, if vars are used in the parse rules.

Geomol, that's something I've never seen anyone do in REBOL before. 
The discarded arguments are even evaluated properly and typechecked.

moebius function. its body bends and bites back into its own spec 
:)

/local is special only in HELP not listing any refinements and args 
from the /local refinement onwards. You can even use that to hide 
refinements (sth. like 'private' refinements):

Yup. The order of logic values as considered by SKIP, PICK and POKE 
is true then false. This was done to make PICK compatible with EITHER.

Yup, because PICK, POKE, AT, INDEX? and /1 work with indexes, while 
SKIP works with offsets.

that depends if both the concept of three states and index direction 
change can be merged into one function and if that makes sense.

I like that PICK is stopping point for none propagation. PICK data 
none should trigger an error, because otherwise you couldn't tell 
the difference between that and PICK [#[none]] 1.

We keep adding more points of none propagation, and every time we 
add one it makes more errors propagate further away from their point 
of origin. This makes it harder to figure out which code caused the 
error where none wasn't screened for or checked for, making it that 
much more difficult to debug.

Tonight's Moment of REBOL Zen:

Literal and Get Arguments in R2

see: http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.2

These functions use Literal Arguments:


 ++ -- ? ?? cd default deflag-face first+ flag-face flag-face? for 
 forall foreach forskip help l ls map-each remove-each repeat secure 
 set-font set-para source

This function uses Get Argument:

	quote

It could be questioned, why functions like

	get set unset in catch throw checksum


, which all have arguments named WORD, don't use Literal Arguments?

The only exception to the above is ++ and --, which take lit-word 
arguments because their primary use is with a literal word value, 
so taking a lit-word argument gets rid of a ' in the most common 
case. And since ++ and -- started in R3 and has its behavior explicitly 
emulated in R2, you can put word-generating expressions in parens 
for the less common case.

FIRST+ is part of the same exception as ++ and --.

it should create a date at 0:00 and GMT

to date! should create a timezone and hour by default

But that doesn't work when you don't want a time and date.

in databases .. date and timestamp are different

In some SQL implementations, date, time and datetime are different. 
And then timestamp is different from all of those.

Don't see why not. It also is a simpler solution than splitting the 
date! type into date! and datetime!.

and just a refinement to default to local time

Given that R3 might get some restrictions, maybe having the /utc 
option like NOW would be better. Like this:

to-datetime: func ["Converts to date! value." value /utc "Universal 
time (no zone)"][

    value: to date! :value unless value/time [value/time: 0:00 value/zone: 
    either utc [0:00] [now/zone]] value
]

But that is starting to get more confusing, since /utc would only 
affect date values without times specified, not convert ones with 
times specified. It might be better to just say that it adds 0:00+0:00 
if not otherwise specified, since that is how dates are defined for 
date arithmetic compatibility between dates with times specified 
and those without.

There are many competing and conflicting standards for how to format 
dates - REBOL just picked one of the international standards that 
looks more human-readable than most. You can get at the component 
parts if you want to format them differently.

MOLD only has to be compatible with REBOL syntax, and the more human-readable 
subset at that. To be compatible with less flexible data formats, 
use formatting functions that are specific to those formats.

As long as it works for my world and web services

I think I'd like to see a flag or something that sets the number 
of decimal places for decimals, and number of places for time.

Given that the "missing" parts of the precision aren't actually missing, 
sure, that works. And the standard allows those portions to be not 
depicted, just assumed. If you have to generate something less flexible, 
that is a *different* standard, so a different formatting function 
is appropriate.

Keep in mind that times in REBOL and most other systems are fixed-point, 
not floating point. There is no loss of precision.

That diferent formatting should not be standard. Generating code 
that is more complex than it needs to be is just a waste of space. 
Remember that MOLD output need only be compatible with REBOL code, 
not with any other syntax processor, and you see that it isn't a 
problem.

Settable system-wide flags that affect MOLD are a bad idea, since 
they mean that you have to put wrapper code around every call to 
MOLD to make sure that it matches what your code expects. This makes 
very call to MOLD more complex and less task-safe.

If you do MOLD output and then reduce the number of zeroes output, 
it requires parsing MOLD's output. Working straight from date! values 
means no parsing required.

if it's a date with no time portion, then date/date gives you an 
error.


It works for me. Or maybe I'm doing it differently. A date! always 
has a time value, correct, though it may be none? And if it's none, 
that affects the default formatting.


While I've had a few times that the trimming of zeros from time values 
annoyed me, it isn't high on my priority list. If I don't like REBOL's 
default format, or if I have to send data to another process, I just 
know I need to format it.

and now that we have now/utc, a lot of the pain is gone, IMHO.

Having QUOTE, would it be an idea to have CITE like this?

cite: func ['word] [:word]


Only difference, I think, is when passing any-function! types to 
it:

>> type? quote next
== action!
>> type? cite next 
== word!

All other types seem to return the same for QUOTE and CITE.

Passing an unset word to QUOTE will return unset! in R2, and will 
return the word in R3. CITE returns the word.

Geomol, in R2 when you pass a word to a get-word parameter, the value 
assigned to that word is passed instead. There may have been a good 
reason for this initially, but in the long run it turned out to be 
a bad design choice, and was fixed in R3. It has nothing to do with 
the any-function! types.

There is a similar special case for when you pass a get-word value 
to a lit-word parameter, bot in R2 and R3. R2's APPLY function has 
code to undo these special cases, and R3's APPLY doesn't do the special 
evaluation; APPLY is used to break the evaluation rules, often for 
safety.

FIRST, SECOND and THIRD can be used on functions like:

>> first :repend
== [series value /only]


SECOND and THIRD returns the function body and spec. FIRST returns 
a stripped spec, just the arguments and refinements. I notice, it's 
produced each time contrary to the other two:

>> same? second :repend second :repend
== true
>> same? third :repend third :repend  
== true
>> same? first :repend first :repend
== false


What is FIRST on a function used for? It may be used internally, 
but does anybody use it externally? It seems more logical, if FIRST 
on a function returned the spec, SECOND the body, and nothing else.

Yes, I see the benefit. I was just wondering, if it was actually 
used. I guess, you used it somewhere? :)

If used, would it be more logical to have FIRST return the spec, 
and THIRD return, what FIRST return today? Or am I missing some vital 
point?

Looking at SPEC-OF, and another question pop up. Why isn't copy/deep 
the default for COPY? Wouldn't the world be much easier, if it was?

I want to download the page, and to do it from different ip

wow, i didn't know u can do that! where is it documented? i just 
remeber get-modes in relation to setting binary mode for the console 
or parity and speed setting for the serial port...

Geomol, using copy/deep by default would be extremely bad for speed 
and memory.   in most of the processing, you don't need to copy the 
deep content of a block, but the wrapper block itself, so you change 
the order or filter it.  


IIRC using copy/deep also causes cyclical references to break-up 
so using it by default would be disastrous.  


just look at how often we really need to use copy/deep compared to 
not and you'll see that the current behaviour is much more useful.

I imagined a can of worms. Guess I have to read and think it all 
through at some time.

The modulus operation from math is not defined for negative numbers 
at all. Most programming languages with a modulus operation have 
extended it to cover negative numbers, but there is no agreed definition 
for it. This is why *all* programming languages and math processors 
that have modulus of negative numbers defined, are using an arbitrary 
platform-dependent definition for it, *even Wolfram Alpha*.

From HELP MOD: "Compute a nonnegative remainder of A divided by B."
MOD can produce negative results as seen above.

From HELP MODULO: "Wrapper for MOD that handles errors like REMAINDER."

So REMAINDER must give wrong result in some cases. What does REMAINDER 
say:

From HELP REMAINDER: "Returns the remainder of first value divided 
by second."

That's what I expect a modulo operation to do. A modern definition 
is given by Knuth in "The Art of Computer Programming" using floored 
division, and this seems to be also the definition, Wolfram Alpha 
use. So I would say, REMAINDER give the correct answer in the second 
case, but not in the first.


As I see it, REBOL have 3 modulo functions, and none of them operate 
as expected, if Knuth's definition is used.

BTW, this was discussed and implemented in ALtMe some time ago

none uses Knuths definition
 Ladislav, please!


Check mod in these languages: Clojure, Common Lisp, Filemaker, Fortran 
(modulo), Lua, Mathematica, MATLAB, R, Ruby (remainder), Scheme (modulo), 
Smalltalk (\\), VHDL


and maybe a few more. They all give the same result as from Knuth 
definition.

And, moreover, you can easily redefine the MOD and MODULO, since 
they are mezzanines

>> ? cd 
USAGE:
    CD 'dir


Notice the non-evaluated Literal Argument. So when you use CD, the 
argument isn't looked up.

>> ? change-dir
USAGE:
    CHANGE-DIR dir


With CHANGE-DIR, it is looked up. It is expected behaviour, but maybe 
confusing, that CD and CHANGE-DIR are different.

If I remember correctly, CHANGE-DIR came first, and it's suited for 
being used in scripts. CD is suited for using at the prompt.

<tab> completion of directories and files works, if you give argument 
as a file! datatype, but not when giving word! argument for CD. I 
believe, this is hard to get by.

And then, maybe if CD were constructed like this:

	cd: func [
		'dir [file!]
	][
		...
	]

From group Core-old:


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of 

side-effect" from how REBOL is structured.  Datatypes are implemented 
as a sort of object class, where the interpreter "sends messages" 
to the class to evaluate expressions. The PATH action is a message 
that tells the datatype to perform a pick-like or poke-like internal 
function."

I made a block of all datatypes and sorted it. That was the outcome.

Nevertheless, it seems the method is going to be complicated and 
slow for /COMPARE as I don't know how it handles periferal cases 
like:

sort reduce [true false]
== [false true]

which cannot be compared outside SORT using:

lesser? true false
** Script Error: Cannot use lesser? on logic! value


and I don't know and should not need to know how many periferal cases 
there are.

Since you can sort a block of logic! values, then <, > etc. should 
work on them, so that's missing. Doing to-integer on logics first 
solve it. And you have to check all the other datatypes by hand first 
to find out, where possible problems are, I guess.

SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.

And then there is one string related to those, crlf.

The one that gets me is remembering that newline is a character and 
new-line is a function, rather than vice-versa.

Exchanging newline and new-line, and I bet a lot of people will mix 
those up. :) Why do you feel, they should be the other way around?

Get rid of the bad old name and change the few scripts, that might 
use new-line. Problem solved!

As for SORT, that's an interesting problem. LESSER? and GREATER? 
are supposed to be constrained to datatypes that are comparable, 
and that have some form of magnitude or ordering. For datatypes that 
don't really have magnitude or ordering they don't really work. When 
it comes down to it, true is not greater than false inherently (considering 
it to be so is more of a moral stand). And none is not greater or 
less than 'a, they just aren't comparable concepts.


SORT doesn't have that luxury though, because it is designed to not 
fail (or rather, not trigger errors because a comparison fails). 
So it has to define some extra comparisons that don't really make 
any sense, as a fallback in the cases where there is no comparison 
that does make sense. The datatype ordering trick is one of those, 
where they are ordered by their inner datatype number, and different 
data that isn't otherwise comparable is ordered by its datatype number 
too (words are greater than unset but less than none, for instance). 
R3 has a list of those datatypes in order in system/catalog/datatypes, 
but if there's a similar list in R2 I don't know where it is - Henrik's 
above is a subset, just the datatypes with externally referenced 
values. R2's and R3's datatypes are in a different order.


SORT/compare is supposed to allow you to provide your own ordering 
function if the standard ordering doesn't make sense. However, if 
you want to support all of the comparisons that the built-in ordering 
supports, you have to make a really complex comparator function with 
a lot of special cases, and in the case of R2 replicate a lot of 
internal data; that function would be pretty slow too. This is why 
SORT/compare is more often used for more restricted cases, like reversing 
the order, or comparing based on object keys.

I would still like to see a dialected new-lines or line-markers func. 
I don't get the char and func names confused today.

Regarding the NEWLINE and NEW-LINE names. Consulting the function 
naming convention described in the documentation, it looks, that 
the NEW-LINE name is not adequate. (violates the function naming 
convention) That deficiency cannot be corrected by renaming NEWLINE. 
The SET-NEW-LINE name would be a preferable solution.

LESSER? and GREATER? are supposed to be constrained to datatypes 
that are comparable

 - in fact, this is a kind of a circular reasoning (cf. "Comparable 
 values are values that are comparable")

In fact, the example of SORT proves, that comparability of all values 
is useful and desirable (we can sort). This situation is quite typical 
in mathematics. For example, is zero a number? The answer is quite 
trivial: yes, because it is useful. Not "philosophical reasoning" 
collecting reasons why not (we cannot divide by zero, zero does not 
express the number of elements of any nonempty set, etc.) matters.

Ladislav, would you prefer, if lesser? and greater? worked on all 
combination of datatypes then? And then just let the sort rules deside 
the outcome.

The errors triggered by LESSER? and such when presented with meaningless 
comparisons are useful, especially for debugging. I recognize that 
SORT benefits from these placeholders, but LESSER? and such benefit 
from their absence.

The errors triggered are useful *for those functions*, as they help 
the developer track down places where their code doesn't make sense, 
usually because they are missing a guard or conversion somewhere. 
For SORT they aren't as useful, hence the placeholders and fallbacks.

Sorry, but I don't agree with the zero case, and I do agree with 
5 not being greater or less than yellow. So that argument falls down.

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

Ladislav, you are arguing that those comparisons have *use*, not 
*meaning*. They definitely have *use* in SORT, mostly as placeholders 
and fallbacks, so that SORT can be used as you describe above on 
heterogeneous data. But that doesn't mean that those comparisons 
have meaning.

Regarding the "meaning" of ordering. If we examine some of the orderings 
you eventually might find "meaningful" we can come to the conclusion 
that they are not the only alternatives possible, and thus are actually 
"meaningless" as well in that respect. To support the "most meaningful" 
ordering for the specific data SORT supports the /COMPARE refinement, 
which proves the point, that even the ordering one user finds "meaningful" 
may lack "meaning" for another.

And should it only do that in case of a 204? It's not clear if a 
304 response may also be affected.

The main problem with R2's HTTP scheme is, that it does not provide 
response-code even in cases where it should, like:

port: open/direct some-url


Without available response-code you have no chance to differentiate 
responses like 204 or 205 which has special meaning =

http://benramsey.com/archives/http-status-204-no-content-and-205-reset-content/

I think the most practical solution is to provide response-code in 
port/locals and return none for 204 and 205.

Also when you are using just:

new-content: read url-with-no-content-response


using error chatching and parsing the error message should be enough.

Thanks Oldes. I can handle it simply for now, and maybe this can 
be addressed more thoroughly in R3.

They are different and not backward compatible.
>> b: [1 2 3]
== [1 2 3]
>> c: skip b 3
== []
>> empty? b
== false
>> empty? c
== true
; c references to b, b is not empty, but c is.

On R3, TAIL? is a redefinition of EMPTY? with fewer supported types. 
Internally they are the same function code. This was done in order 
to have one version that is more flexible, and another that triggers 
useful errors.

Getting an error when sending bulk email: 

** User Error: Server error: tcp 501 <>: missing or malformed local 
part
** Near: insert smtp-port reduce [from address message]

The number of email addresses is 52. 

I can send using the same settings one at a time and I have succeeded 
sending  8 addresses at one time. But it bombs on my whole list.

If I want to store some fairly big data as undo information, it seems 
to make sense to store it as a diff, and load the data that I want 
to undo/redo to. Then it would also be possible to store the entire 
changes sequence to disk.

The biggest object here is around 4 MB or 550 kb compressed. I expect 
that binary diff would only be used during load and save, and then 
keep full objects in memory.

you are right. I looked into it and it looks to be way too slow, 
so I'm trying another approach.

Isn't unary minus introducing a third semantic rule? Functions are 
prefix, operators are infix with precedence over functions. And then 
unary minus is prefix with precedence similar to operators?

no,  AFAICT the unary minus is applied exactly like all operator 
precedence (from left to right).


negate and  "-"  do not have the same precedence, as you noted, so 
its normal for:
    >> negate 2 + - 2    
and
    >> - 2 + - 2
to give different results.

Isn't it strange, that if the value being searched for (in this case 
a) is found, and the next item in the block isn't a block, then it 
fails to defaul?

From the docstring for SWITCH: "Selects a choice and evaluates the 
block that follows it."

Oh, the docs are different at
http://www.rebol.com/docs/words/wswitch.html
It sais "Selects a choice and evaluates what follows it."

Must be a block
 ... hm why?

the change to switch was a good thing... wasn't it also mezz code 
a wee back?  IIRC this happened at the same time... and it made A 
LOT of code much faster.

in R2, the - operator is both unary and binary, and its arity is 
determined during interpretation

1) There are not unary version and binary version of the - operator 
in R2, there is just one - operator in R2, which is both binary and 
unary depending on the "situation"

2) The statement "there is no unary version of the - operator" may 
be true only if you state, that NEGATE is not a unary version of 
the - operator

I wrote: "...which is both binary and unary...", I could have written 
"...which is neither binary nor unary, since it does not have fixed 
arity, its arity being dependent on the situation..."