Might we use THE-WORD! in PRINT to mean "MOLD"?

Domains Dialects/DSLs
1

I've talked in the past about how I think PRINT of a BLOCK! is a pretty limited dialect, in that its hands are kind of tied because it allows just any evaluation, not required to be in a GROUP!. Compare this with PARSE, which strictly controls evaluations.

One thing that occurs to me that could be done without really making that much of a ripple in SPACED/UNSPACED/DELIMIT would be if THE-WORD! could mean "mold this":

>> value: [a b c]

>> print ["Value is:" value]
Value is a b c

>> print ["Value is:" @value]
Value is [a b c]

Note this is a suggestion for the direct dialect behavior, not of a THE-WORD! that gets generated:

>> print ["Value is:" quote @value]
Value is @value

The idea that every stringy type that isn't a TEXT! form with their delimiters is something I've been assuming for a bit, in a "WYSIWYG" kind of mentality.

One technical question interfering in the evaluation raises is what to do about infix, such as something that is looking to pick up the THE-WORD! on the left.

>> @value left-quote
== @value

>> print ["Value is" @value left-quote]
Value is @value  ; this is presumably what the output should be

This would mean that while SPACED was looking at the pending evaluations, it would have to do something along the lines of notice it was a THE-WORD!, do the evaluation, and then ask if the evaluation moved by only one unit. There's actually more to worry about than that, because pure invisible comments would be evaluated as well...

Such interactions are complex, and raise a lot of questions about just how dialect-y you can get when you let people write any evaluative material in a block like that. But requiring GROUP! would be rather heavy-handed, and if literal inspections were done then at least if that's not what you wanted, you could use a group.

If this isn't good, is any PRINT (SPACED, DELIMIT) dialecting good?

People certainly want to use literal TAG! in unspaced:

unspaced [<b> "bolded text" </b>]

So the idea of using tags for control codes or saying how many digits of precision to print integers with would probably be unpopular. Is PRINT never going to aspire to more, and is that the job of a higher level print format routine?

If that's the mindset, then this THE-WORD! proposal is probably the only change that might be considered for squeaking by, but if it's the only irregularity it's probably not worth it. (?)

2

I've held off on doing anything interesting in PRINT for some time now, based on the... fear. :ghost:

It's the fear that if we give meaning to parts in the "print dialect", that there will be potential for confusion if we evaluate a freeform expression in the middle of that dialect that uses one of those parts.

>> block: [a b c]

>> print ["The block is: block]
** Error: Unknown rendering for &[block] in DELIMIT

>> print ["The block is:" @block]
The block is [a b c]

>> print ["This is" if get @block ["my fear"]]
This is my fear

There we see @block having nothing to do with molding at all. And yet, there it is--right in the "PRINT dialect"

So what I'm afraid of is that you'll be trying to read a PRINT expression and not knowing when the "magic" dialected parts are going to do their magic, vs. just be a parameter to some function call.

We wouldn't require groups on everything. Just function calls...

>> name: "Roscoe"

>> print ["Your name is" name]  ; no parentheses needed
Your name is Roscoe

>> print ["Your backwards name is" (reverse name)]  ; need parentheses
Your backwards name is eocsoR

There's an added benefit: if you see something like print ["foo" baz bar], you know baz and bar aren't functions. They have to resolve to non-function values, so you can read that with more confidence as to what's going on.

[But Is The Fear :ghost: Justified? Or "Trust The User"?

The only mechanical problem with mixing dialected-interpreted values with code is that it screws with enfix. Because the dialect is going one item at a time--consuming types that it recognizes--and then calling out to the evaluator when it sees things it doesn't--it could consume an item that people thought was meant for the left hand side of a function. That's not the end of the world.

I dunno. Beyond just the fear of confusion, we could also open up dialecting for paths and chains. I feel like there's a lot of cool things we can do with PRINT and giving meanings to things...

 >> string: "abcdef"

>> print ["What about limiting prints?" string:3]
== What about limiting prints? abc

So how oppressive would it really be if any function calls in PRINT were in GROUP!s?

Dialect With Fear, Or Dialect Without Fear, But... Dialect

You'll have a hard time convincing people your "dialected" language is all that when C's printf() is kicking your butt in the features department. So we're way behind schedule on having a featured PRINT with intelligent formatting as a dialect.

My instincts say that using GROUP!s for function calls isn't that oppressive, and cleans up some edge cases like enfix meddling with the code. When I have complex expressions in PRINT I usually parenthesize them anyway.

So I'm eyeing the concept of requiring the groups.

1 Like