Comments on: How best to blockify?
This is a really common line of code:
unless block? value [value: reduce [value]]
If the value is not a block, make a new block that holds the value. This is frequently used in functions that use block arguments to allow them to accept other values.
I would like a simpler function to do that. Something like:
blk: blockize value
Of course, I don't like the blockize name that much, but it is consistent with dirize.
You might think that:
to block! value
or:
make block! value
could do what we need, but they have special exceptions for some datatypes. For example if the value is a string, it is loaded. If the value is an integer, make creates a block of that size. Those kinds of exceptions are fairly standard in the conversion functions.
So, since reduce creates block, perhaps a cousin could be:
blk: deduce value
or:
blk: enduce value
Those are both good names... so good, I can almost see them for some kind of prologish function; I'm just not sure what.
Ideas?
17 Comments Comments:
Brian Tiffin
15-Mar-2007 23:12:52 |
When I first say blockize I thought of Gregg's 'trick', compose [(value)]
At least I first saw it mentioned in Gregg's code, tutorial, article somewhere.
Then I thought enclose
Then I thought "take what ever comes and be happy because you'll probably keep using compose [(value)] out of habit".
| Brian Tiffin
15-Mar-2007 23:22:02 |
Sorry, I meant to say "When I first saw blockize... | -pekr-
16-Mar-2007 2:17:51 |
not much to input from me, but for my "czech english", blockify would sound better than blockize, but then it would not be compatible with dirize, which would sound, dirify :-))
-pekr- | Gabriele
16-Mar-2007 5:38:11 |
Hmm... I like enclose... or maybe as-block? | Robert
16-Mar-2007 5:47:59 |
Why not something like FORM/BLOCK or FORM/ONLY? Whereas I like the first one more. | Peter Wood
16-Mar-2007 7:01:22 |
as-block is clear and concise.
Perhaps as block! would be more Rebolish and would allow as-block to be implemented as a mezzanine function. | Ladislav
16-Mar-2007 10:42:04 |
I prefer enclose, (I already to use it in my applications). | Anton Rolls
16-Mar-2007 10:46:19 |
Well.. I think I like enblock. | Maxim Olivier-Adlhoch
16-Mar-2007 11:13:39 |
I always compose [(value)] so its a moot point for me especially since the /only switch exists which basically allows exactly what another function would do.
IMHO people should simply collect their own lists of utility funcs, like
enclose: func [serie][compose [(serie)]]
why add yet another method for such a reduced scope of usefullness.
the as block! is not to bad, since its uniform with current 'AS funcs which do vanilla conversions, as long as we one day get a grid which explains all the differences of conversion from one type to another with the differences between 'MAKE, 'TO and 'AS and how they recover (or not) from errors or identified suspicious values (like a date/day of 0). | Maxim Olivier-Adlhoch
16-Mar-2007 11:22:35 |
to fully simulate Carl's example where the value is only changed, if its not currently a block (keeping the references to that specific block) I would use the as-block since AFAIK that is the (only?) difference between as-string and to-string.
ex: for strings:
>> same? a to-string a
== false
>> same? a as-string a
== true
this way, there is a clear and uniform understanding of the difference between to and as and its consistent across all series types.
plus we can keep those nice function names for more usefull semantics. | Carl Sassenrath
16-Mar-2007 12:34:23 |
Good feedback. Yes, this is one of those subtle ones. It is not a major function, but rather a helper. If it does not help the user (because user cannot remember it or the name is wrong), then it hurts the user (by adding more words) and it's not worthy of addition. So, therein lies the rub.
Some thoughts...
- Yes, this function is indeed the trivial form of compose. Problem is, writing it as compose [(x)] uses two more blocks that I prefer, the () and [].
- I like enclose, but we might want to reserve that for something related to closures (new in 3.0). The enblock choice is worth considering. Quite clear.
- In my English too, I thought about blockify, but does not match dirize.
- You are wise to notice that relationship to form -- it is the "convenient helper" for to-string. That is precisely what I want for block, but it must be pathless.
- I don't see the same relationship with as-block. In REBOL "as" provides a type alias, not a constructor. (That is, it uses the same value, does not construct a new one.)
| Chris
16-Mar-2007 12:46:30 |
I've been using envelope, though I appreciate that has meaning in other areas of communication... | Robert
16-Mar-2007 14:37:50 |
How about BRICK? | Gregg Irwin
17-Mar-2007 14:12:13 |
At first glance, I like ENBLOCK, because it relates to ENBASE and the concept of encoding something into another form. You could also read it as short for "ensure block". | Brian Tiffin
17-Mar-2007 14:52:40 |
I'm guessing that enblock value will be orders of magnitude faster than compose [(value)]?
I thought enclose might have a future purpose regarding enclosures...
I have a question though, what will enblock do with a block. Will it be
enblock [1 2 3] ==> [[1 2 3]]
or will it work like "ensure block"
enblock [1 2 3] ==> [1 2 3] - no effect
? I'd prefer the latter... | Maxim Olivier-Adlhoch
17-Mar-2007 18:49:10 |
brian... did you read Carl's code snippet? ;-)
unless block? value [value: reduce [value]] | Brian Tiffin
18-Mar-2007 12:01:38 |
Maxim; Yeah I realized how dumb the question was a few hours after I posted it, but I was already out enjoying Saturday night...
...for some reason...my construction worker friends didn't seem to care :)
Thanks for keeping things honest |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
