r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Pekr
13-Oct-2006
[5623]
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
[5656x2]
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.
But I like the idea of a paren-friendly compose alternative, or maybe 
a refinement for COMPOSE.
Maxim
13-Oct-2006
[5658x3]
we could simply add a double parens filter.  that allows parens to 
stay in the blocks, and makes the composed values even more obvious...
like so :

COMPOSE [((this)) not (that)]
with syntax highlighting, compose is VERY programmer friendly.
BrianH
13-Oct-2006
[5661]
You can already do that as:
COMPOSE [([(this)]) not (that)]
Maxim
13-Oct-2006
[5662]
but those extra blocks add unneeded complexity...  and honestly... 
in about 80% of cases,  the /deep refinement is required...
BrianH
13-Oct-2006
[5663x2]
Or I just got that reversed, didn't I.
COMPOSE [(this) not ([(that)])]
Still awkward though.
Henrik
13-Oct-2006
[5665]
It's awkward, I think. I can't tell what really happens when you 
embed multiple levels of parantheses and brackets
Maxim
13-Oct-2006
[5666]
and its not of any help with /deep  I often use /deep when creating 
objects which use words which are the same as values within the code 
creating it.  same thing for dynamic view layouts.
BrianH
13-Oct-2006
[5667]
Yeah, with /deep you have to use nested calls to compose and to-paren.
JaimeVargas
13-Oct-2006
[5668]
I'm all for Build. I find it very comfortable.
Ladislav
13-Oct-2006
[5669x2]
I think reduce/only works backwards
 - me too
 'ins and 'only don't jump out visibly as much

 - 'ins and 'only are not "real keywords". Using the /with refinement 
 you can use any keywords you like. Actually, BUILD [...] is defined 
 as:

    build/with [...] [
        ins: func [x [any-type!]] [get/any 'x]
        only: func [x [any-type!]] [
            head insert/only copy [] get/any 'x
        ]
    ]
Anton
14-Oct-2006
[5671]
So they are just handy defaults. I think they're as well-named as 
they can be, probably.
Louis
14-Oct-2006
[5672]
When constantly having to convert from one currency to another is 
it best to not use the money! datatype? If I change for Rp. to $ 
and then back to Rp. I lose a few Rp.