World: r3wp
[Core] Discuss core issues
older newer | first last |
Ladislav 13-Oct-2006 [5607x2] | this is not about getting rid of parens, this is about *not clashing with parens* |
With COMPOSE/DEEP you cannot use parens safely | |
Henrik 13-Oct-2006 [5609] | by safely you mean selective evaluation? |
Ladislav 13-Oct-2006 [5610x2] | yes |
imagine I need parens in the layout block. Then I am getting out of luck with compose/deep | |
Henrik 13-Oct-2006 [5612] | I can see that now. I've just not run into a case like that, I guess. :-) |
Ladislav 13-Oct-2006 [5613] | it is not that rare to use parens in the layout block, I guess |
Henrik 13-Oct-2006 [5614] | that would be cases where you need to compose things during runtime and not "layout time" |
Ladislav 13-Oct-2006 [5615] | another example: if you look at the SPIDER implementation, you will see it is implemented using BUILD too. I bet it would be much harder with compose, because there *are* parens in the implementation. |
Henrik 13-Oct-2006 [5616] | are you going to prepare docs for it? |
Ladislav 13-Oct-2006 [5617] | I am not sure I know what to write ;-), maybe I should ask somebody else |
Henrik 13-Oct-2006 [5618] | well, if some good examples came into place, then I think it would be possible to write a little bit around it. |
BrianH 13-Oct-2006 [5619] | Well, you know I'm in favor of including BUILD in the default REBOL. You clash with parens all the time when building parse rules. |
Ladislav 13-Oct-2006 [5620x2] | Brian: right, for parse rules it is much better than compose |
Actually, we might use something like REDUCE/DEEP/ONLY, if the /DEEP refinement existed and if /ONLY specified the words that should be evaluated instead of the unevaluated ones | |
Pekr 13-Oct-2006 [5622x2] | hmm, what if you have more parens, containing the same words, and one you want to evaluate, while second you don't? |
just theoretising, not knowing what actually 'build is about .... | |
Ladislav 13-Oct-2006 [5624x3] | good question, Pekr. Answer: you can choose any new word you want to for the evaluation - especially some words you know you cannot encounter in the block are good. |
For example when I use the word 'spider, I am pretty sure, it cannot clash with any "native" DRAW command, because spider isn't native DRAW command. Does that make sense? | |
This is exactly why COMPOSE isn't as comfortable. There are many blocks containing parens and you cannot pick any replacement for parens in COMPOSE case. | |
Henrik 13-Oct-2006 [5627] | now would the only advantage to use compose be that it's a native function? does build make compose redundant? |
Ladislav 13-Oct-2006 [5628] | yes, the only advantage of COMPOSE is, that it is native in my opinion. |
Henrik 13-Oct-2006 [5629] | would build be possible to make natively for R3? |
Pekr 13-Oct-2006 [5630] | that's what I wanted to ask about - native 'build in R3? |
Ladislav 13-Oct-2006 [5631] | I am sure it is possible |
Henrik 13-Oct-2006 [5632] | then I would vote for having it done and deprecate the use of compose, or is that too drastic? |
Ladislav 13-Oct-2006 [5633] | we may make Compose deprecated, but need to keep it for the backward compatibility in my opinion |
Pekr 13-Oct-2006 [5634] | or could not functionalities of both merge somehow? compose/build for e.g.? |
Ladislav 13-Oct-2006 [5635] | yes, that is another option Carl is investigating too. We can either improve REDUCE (/DEEP, etc.) or COMPOSE |
BrianH 13-Oct-2006 [5636] | Compose has its uses. I don't want to go the Perl "there's more than one way to do it" path, but flexibilty can be useful. |
Henrik 13-Oct-2006 [5637] | http://www.fm.tul.cz/~ladislav/rebol/build.r<--- posting the source again for newcomers. |
BrianH 13-Oct-2006 [5638x2] | Has anyone implemented some kind of functional-language-style structural patten matching and transformation? |
In theory you should be able to compile such code to parse rules... | |
Pekr 13-Oct-2006 [5640] | pattern matching? do you think about improving 'parse? |
BrianH 13-Oct-2006 [5641] | All the time - haven't you been paying attention? :) |
Henrik 13-Oct-2006 [5642] | I thought parse was already being improved for R3? |
BrianH 13-Oct-2006 [5643] | I think so. I hope so, I was rather active in the discussions of appropriate improvements to the dialect. |
Pekr 13-Oct-2006 [5644] | Henrik - where did you get it from? :-) IIRC asking Gabriele some time ago the answer was something like possibly. IIRC there was one page with parse suggestions, but not sure what will come in. I know that mine would make parse a different tool, but for "novices" like me, I would welcome 'to [a | b | c] :-) |
Ladislav 13-Oct-2006 [5645x2] | Brian - parse inspirations welcome, if you have got more ideas than the ones you already presented elsewhere |
to [a | b | c] is definitely a candidate for R3 | |
Henrik 13-Oct-2006 [5647] | pekr, I seem to remember some discussions where Gabriele was involved. there was also code examples shown, but I didn't read it closely. |
BrianH 13-Oct-2006 [5648x2] | I don't know - I was pretty throrough before. Let me review past discussions and see if I've come up with anything new. |
later | |
Henrik 13-Oct-2006 [5650x3] | ladislav, what if I want to use values that are already set elsewhere, like function input? then the /with values block needs to specify the values too: a: func [b] [ build/with [this block contains a c] [c: :b] ] Perhaps I've created the build block elsewhere and want to use parts of it with BUILD. Perhaps also I want that block to be fully readable. Then it would be nice to: y: [that is a very large animal] a: func [animal] [ build/words [that is a very large animal] [animal] ] a 'cow == [that is a very large cow] |
whoops, the first part didn't come along clear enough: It involves a bit of double work, since you need an additional variable. | |
the second part should have been: a: func [animal] [ build/words y [animal] ] | |
Ladislav 13-Oct-2006 [5653] | the problem with your 'animal example is, that such a thing can be implemented natively and be quite fast. To obtain the fastest possible mezzanine implementation I resorted to the "object-like" behaviour. BTW, it is easy to "transform": a: func [animal /local animal*] [ animal*: :animal build/with [that is a very large animal] [animal: :animal*] ] |
Anton 13-Oct-2006 [5654] | I support the idea of adding build as a native. I would like to check it out more but I think it's a good bet from what I've seen today and in the past. |
Henrik 13-Oct-2006 [5655] | ladislav, yes, maybe it wouldn't be a good part of build, though I would have liked to see such a function, at least as mezzanine. |
Gregg 13-Oct-2006 [5656] | 1) I think reduce/only works backwards; /only should say what words you want evaluated. I don't know how much code depends on that yet, or if Carl would be open to change it, or even what the design rationale was. I wonder if adding BUILD is will cause some confusion, because of similar methods to do the same thing, WRT REDUCE and COMPOSE. What I like about COMPOSE (and, yes, I don't like the downside of trying to compose in parens) is that the parens are visible, so you know what's being operated on. With BUILD, 'ins and 'only don't jump out visibly as much. |
older newer | first last |