|
P
7004 | Re #6996: Thanks Carl, I eventually found the docs and have CGI working just fine. | Paul
1209d |
|
P
6996 | Re #6992: Paul, it's a bit of a puzzle why google isn't finding the R3 cgi docs. Try searching for REBOL R3 cgi ... and the First R3 CGI script is what you want for doing CGI. But, yes, we need to move that to the R3 manual, once other things here get taken care of. | Carl
1210d |
|
P
6717 | Re #6714: I think it fit better EXTRACT raver than PICK.
EXTRACT already return a block. Need thinking. | DideC
1248d |
|
P
6715 | Re #6714: I see the issue in that it outputs a block instead of the value, but since the input index is also a block, the output can be better predicted. It's still picking values from a block using an index. | Henrik
1249d |
|
P
6714 | Re #6713: Is it still PICK though? | Graham
1249d |
|
P
6713 | Suggestion for modification for PICK: pick [a b c d] [3 1]
== [c a] Does this make sense? | Henrik
1249d |
|
P
6628 | Re #6626: That doesn't affect function! or closure! contexts, but all other
binding loop functions are affected. There's no need to bind 'self since you
can get the context from BIND?. There is no real 'self field in objects anymore
- the 'self in the code blocks is a side effect of MAKE OBJECT!. And the loop
functions that do binding apparently do it too, though that seems like a bad
idea. Someone should CureCode it. | BrianH
1262d |
|
P
6626 | It seems that in blocks executed via FOREACH, SELF is somehow special.
Witness, in the R3 toplevel: >> do foreach x [1] [self]
== make object! [ x: 1
It looks like SELF is rebound to FOREACH's execution context. While I
could understand the reasoning behind this, it does not seem to be
an intended effect, as the execution context is not exposed via SELF
in other cases. For example, a simple FUNC: >> do func [x] [self] 1
== make object! [ system: make object! [
... Is there a reason behind the effect seen in FOREACH? Or is this simply
a bug? | Andreas
1262d |
|
P
6383 | Re #6372: Why not just a simple mezzanine? index-of: func [series value] [either series: find series value [index? series] [none
]] | Gregg
1267d |
|
P
6374 | Re #6372: Hi Henrik, I am curious why INDEX? FIND would be used often? I've never written that idiom, because the series returned from FIND carries its index with it, and most other functions will use it. Eg. COPY/part a find a b | Carl
1268d |
|
P
6372 | Is there merit for a short form for INDEX? FIND ? Perhaps there could be a speed up, but mostly, I'm looking to a way to handle when FIND returns NONE. I know my arguments are weak, but I run into this a lot. | Henrik
1268d |
|
P
5839 | Did you ever decide on whether all functions shold return values? http://www.rebol.net/cgi-bin/r3blog.r?view=0024#comments | PeterWood
1331d |
|
H
5045 | Plugins | Carl
948d |
|
H
4532 | tasking | ladislav
1464d |
|
P
4323 | Please VOTE on effect of UNSET value:
http://www.rebol.net/r3blogs/0207.html | Carl
1484d |
|
P
4266 | Re #4265: thanks, I asked, since open/write looks like erasing the contents. | ladislav
1490d |
|
P
4265 | Re #4264: I suppose WRITE/APPEND. | Henrik
1490d |
|
P
4264 | Hi everyone, what is currently the easiest way how to append a couple of bytes to a file? | ladislav
1490d |
|
H
4217 | Exceptions | Carl
1493d |
|
P
4103 | Hi guys - isn't it just too much ado about nothing? :-) One function being native or not? I know you might be talking about general principle, but I think that R3 has much deeper issues to solve .... | pekr
1504d |
|
P
4102 | Re #4099: You're not answering my question. :) Give me a hard number. Tell me what people have done where it was too slow. How can we make sure it will meet the target need if we don't know what that is? If financials are the target, how much is interim rounding needed (now that we have the new money! implementation), and in what contexts? Where else would it be used, that requires a huge number of calls to it? Would it be used in signal processing? If so, is that a target use, and is ROUND the thing holding REBOL back from being applied there? Or are we better off doing something like the convolve effect (an awesome feature that probably not many people use), taking things to a higher level? | Gregg
1505d |
|
P
4101 | Re #4098: I'm drawing a blank on funcs where /deep is the common case, and is implied. What are the best examples? | Gregg
1505d |
|
H
2165 | Modules | Carl
1162d |
|
H
1228 | Lab | BrianH
1589d |
|
H
1125 | Semantics | BrianH
1441d |
|
P
1124 | If you have an option to REWORD that makes it use only positional keywords,
and make that option not work on block templates, you could do positional.
Perhaps the option could be called /index ... | BrianH
1603d |
|
P
1123 | If you do strict positional you will lose block template support because there
will be no escape chars in block templates. If you do optional positional you
would not have semantic problems with mixed positional and keyword use. Since
you can use numbers as keywords yo can get nearly the same effect. By the way, block template support is coming - I just haven't done it yet. | BrianH
1603d |
|
P
1122 | Don't forget that REWORD will also have the function of Carl's REPLACE-ALL
function suggested above. It will behave almost the same as REWORD of strings:
- There will be no need (or support) for escape characters or /escape.
- There will be a /deep option.
- There might be an /only option (but I am leaning against it at the moment). | BrianH
1603d |
|
P
1121 | Re: 1110 - You can do this if you like with the existing REWORD
>> REWORD "blabla...$1...$2..." [1 "hello" 2 ","]
The numbers become keywords. | BrianH
1603d |
|
P
1116 | http://www.rebol.net/r3blogs/0169.html for summary. Press g to goto it from here. | Carl
1603d |
|
P
1114 | What about calling REWORD a RECOMPOSE? I know, it is longish, but doesn't it do kind of composing, just for blocks? The problem is, that RE in RECOMPOSE might suggest reduce compose .... just an idea .... | pekr
1603d |
|
P
1113 | Well this time I read it. This is a lot like a suggested change to allow COMPOSE on strings. I think it is a valuable function to have, but I would not think of it as a REWORD (which indicates to me changes to WORD!s in a block.) It is also very close to REPLACE, as of course you've noted several times. There are two (maybe three) general patterns of COMPOSE-ition that we should isolate to make sure we get them right. I'll open a wiki page on it, because we need to talk about it more. | Carl
1603d |
|
P
1110 | I will repeat it, but for me it's exactly a format function (same purpose)
but acting on strings as well.
>> REWORD "blabla...$var1...$var2..." [var1: "hello" var2: ","]
== "blabla...hello...,..."
a good ehancement would be to not being forced to use named vars, but
index instead.
>> REWORD "blabla...$1...$2..." ["hello" ","] | Steeve
1603d |
|
P
1108 | REWORD will be simple to use, but has been difficult to implement. What it
does is simple word (or other value) switching, with an optional escape char
for strings. It is a builder function: based on a template and a block of word
value pairs, but with the standard /into option if you want to save memory. I'm considering adding substitution to REPLACE as well, since REPLACE is a
modification function, not a builder. Builders and modifiers are completely
different in implementations and use, even if they take the same parameters.
For instance, REMOVE-EACH is a modifier, MAP is a builder. | BrianH
1603d |
|
P
1101 | Subheadings: Idioms 754, Syntax 1096, Options 1097, Naming 1098, Dialects 1100 | BrianH
1603d |
|
H
1100 | Dialects | BrianH
1603d |
|
H
1098 | Naming | BrianH
1309d |
|
H
1097 | Options | BrianH
1473d |
|
H
1096 | Syntax | BrianH
1279d |
|
P
1087 | I have not followed REWORD/SUBSTITUTE but I assume is is a constructor function, a sort of reverse of parse? Since I've not looked at it yet, I don't know how complicated it is, but that's where the design needs to be careful (complicated things need good docs, or they never get used.) I was detecting that concern in Gregg's message too, but not quite sure. | Carl
1603d |
|
P
1086 | We need to create some sub headings in this group... not for specific functions, but for general categories. | Carl
1603d |
|
P
1085 | That #1070 map! with "a" twice is a bug.
The correct result should be "a" 2 | Carl
1603d |
|
P
1083 | REWORD generates a new series based on a template and rewording rules, pairs of
values where all instances of the first value (the word) are changed to the
second value. The first value of the pair will usually be a word or a string
with a word in it, so REWORD makes sense. If the template is a string you can
also specify an escape char or string - the default is "$" by Carl's request,
to be compatible with shell scripting conventions. If the template is of a block type, the "word" could be any value, but is still
going to be a word or string most of the time - STRICT-EQUAL? rules apply if I
can manage them. We handle string templates with generated PARSE rules. We can't use PARSE to
do the block substitution until some of the Parse Proposals are incorporated,
so it's done with REBOL code and recursion for now. This function has been the source of many CureCode requests. | BrianH
1603d |
|
P
1081 | In REBOL, variables are called words. It makes sense with the changes to the
doc strings, and based on the behavior of the function, which will include
abilities like Carl's REPLACE-ALL function. Ignore the REPLACE-ALL name - look
at what the fnction does instead. | BrianH
1603d |
|
P
1080 | This won't work for SUBSTITUTE, but REPHRASE sounds like a word we would like to find some appropriate use for later. :-) | Henrik
1603d |
|
P
1079 | REWORD doesn't sound right to me, at a glance. It's doing variable substitution/assignment/expansion, correct? I haven't kept up with the details. | Gregg
1603d |
|
P
1070 | Is this intentional?
>> a: make map! ["a" 1 "a" 2]
== make map! [
"a" 1
"a" 2
] >> pick a "a"
== 1 Is this the precedence you would like in REWORD, for instance? First come? | BrianH
1603d |
|
P
1069 | It would particularly help if the [ref: name value] syntax were implemented,
as this would allow changes. The ref would refer to the target map or object. | BrianH
1603d |
|
P
1068 | I figure that the ordering would be the same as to-block map! at the time, but
non-deterministic otherwise. I'd love to see parallel stuff some day :) | BrianH
1603d |
|
P
936 | I already use ANY (in funcs) and i'm used to. So DEFAULT looks not necessary IMO.
But if it must be there, I prefer the dialected way, even if slower : the form is rebolish and clear. Other way looks weird.
Brian version is not bad, but people who put 20 values will put 20 lines of "DEFAULT blah: 10" => verbose ! | DideC
1604d |
|
P
874 | Note that my submitted DEFAULT now supports these syntaxes:
- default x 10
- default x: 10
- default 'x 10
- w: 'x default :w 10
It's the simplest solution. I like the dialected
- default [x: 10]
but it would be much slower. The advantage would be that you could avoid DOing
the expression, just like ANY, and the multiple var thing Gregg mentioned. The
disadvantage is that it would be much slower (maybe even if it were native). | BrianH
1604d |
|
P
868 | Added lit-word! notation to DEFAULT (mezz-control 556). | BrianH
1604d |
|
P
867 | Note that my submitted DEFAULT supports these syntaxes:
- default x 10
- default x: 10
- w: 'x default :w 10
It's the simplest solution. I like the dialected
- default [x: 10]
but it would be much slower. The advantage would be that you could avoid DOing
the expression, just like ANY, and the multiple var thing Gregg mentioned. The
disadvantage is that it would be much slower unless it were native. | BrianH
1604d |
|
P
865 | I like the last one, for two reasons: 1) the first three have the word twice, which is just wrong :), 2) it makes it a dialected function, so you can set more than one default with a single call. #4 doesn't seem right either, requiring the use of a set-word! arg like that. | Gregg
1604d |
|
P
864 | I'm not against DEFAULT (obviously), I just know that there is a tradeoff when
compared to ANY (which I still want changed). | BrianH
1604d |
|
P
863 | Submitted DEFAULT to DevBase, set-word! notation supported. Here it is:
default: func [
"Set a word to a default value if it hasn't been set yet."
'word [word! set-word!] "The word (use :var for word! values)"
value "The value" ; unset! not allowed on purpose
][
unless all [value? word not none? get word] [set word :value] :value
] | BrianH
1604d |
|
P
860 | It's kind of an interesting situation there... with ANY vs DEFAULT. The down side of DEFAULT, and one we'd want to fix, is the missing set-word notation. On the other hand, Gregg is right that the intention of the expression is more clear using the DEFAULT word. Unfortunately, it's not possible for DEFAULT to sniff backwards into the set expression without some serious magic. So, that leaves us with these possible forms: foo: default 'foo 10
foo: default foo 10
foo: default foo: 10
default foo: 10
default [foo: 10] I've not thought in detail what it would take to implement, but should not be that tough. | Carl
1605d |
|
P
853 | But the word 'default has meaning that ANY doesn't. | Gregg
1605d |
|
P
851 | Advantages to using ANY (with the proposed change) instead of DEFAULT:
- The expression that creates the default value will only be run if necessary.
- The word will be set with an explicit set-word, which is more FUNCT-friendly. | BrianH
1605d |
|
P
850 | Or you could have DEFAULT be this: default: func [
"Set a word to a default value if it hasn't been set yet."
'word [word!] "The word (use :var for word! values)"
value "The value" ; unset! not allowed on purpose
][
unless any [get word] [set word :value] :value
] | BrianH
1605d |
|
P
848 | Note: If ANY treats #[unset!] as #[none] (and only ANY should be changed, not
ALL), then you won't need a DEFAULT function at all: just use ANY instead. | BrianH
1605d |
|
P
844 | I don't mind a function flag like [throw], but I've always hated the name. It
makes very little sense - this kind of thing should be self-documenting. What I am curious about is whether something like this is still possible with
the new function call semantics. Only you can answer that one Carl... | BrianH
1605d |
|
P
838 | BrianH, "equivalent of [throw]" - there is none at this time. We should talk about it to figure out best approach on it. | Carl
1605d |
|
P
798 | I think a good question to ask whenever you allow unset! values is:
* What does nothing mean here?
That would be a good guideline for treatment of unset! values. | BrianH
1606d |
|
P
784 | Should I move the language design chat about unset! from Idioms to here? | BrianH
1606d |
|
P
725 | Question: What is the R3 equivalent of the R2 [throw] function attribute? We
need something like that for USE and every other mezzanine control function.
This relates to bug#539 for now, but more will come... | BrianH
1608d |
|
P
319 | Proposal: AS type! action, with AS-* wrapper mezzanines ( http://curecode.org/rebol3/ticket.rsp?id=546 )
This proposal came from discussions in various AltME worlds. Discuss :) | BrianH
1615d |