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
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
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.
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".
Sorry, I meant to say "When I first saw blockize...|
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 :-))
Hmm... I like enclose... or maybe as-block?|
Why not something like FORM/BLOCK or FORM/ONLY? Whereas I like the first one more.|
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.
I prefer enclose, (I already to use it in my applications).|
Well.. I think I like enblock.|
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).
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
>> same? a as-string a
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.
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.
- 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.)
I've been using envelope, though I appreciate that has meaning in other areas of communication...|
How about BRICK?|
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".|
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...
brian... did you read Carl's code snippet? ;-)
unless block? value [value: reduce [value]]
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.