VID Expression Optimization

[hostilefork]

@Carl Sassenrath

In R2, VID faces were described mainly with a style name, followed by a sequence of datatypes. For example, you could write:

button "Here" "There" red green 100x32 [browse home]

So, we placed a high value on expressing modifications in a minimal way.

Yeah, this is kind of what I mean when I say it's always seemed like gibberish. I'm guessing the "Here" is what the button says when you're not hovering it, and "There" is when you are? (Though that sounds backwards).

Couldn't at least the foreground and background colors be done with a PATH!, like red/green, and if you wanted to set just the background color you could do /green?

I dunno. @rgchris's StyleTalk makes a lot more sense.

@Carl Sassenrath

Let's take an example:

user-name: field "default name"

Now, if for some reason you need that field to look different, such as use white text on black box area, you would first want to ask yourself if that should be defined as a new style in the style sheet. But, if not, you could write:

user-name: field "default name" with [
    area-color: black
    text-color: white
]

My first impulse here was "wow, this looks like it would be an interesting job for FENCE!". Having another part of speech as an array type, to take on meaning in your dialect in that position:

user-name: field "default name" {
    area-color: black
    text-color: white
}

Even looks like CSS, eh?

(I do not see there being any wisdom in picking alternate terminology from CSS for when you're drilling down to the implementation properties. Very diminishing returns.)

I think those are the main things I have to say at the moment. When I get the inkling to look a little more into this I'll add to this thread.

Although seeing this WITH pattern reminds me of something...

Trailing Words To Add "Refinements" In Ordinary EVAL

I've been tempted sometimes by the idea of variadic lookahead to implement syntaxes even in non-dialected code, where you could tack words on the end of something to be more competitive with other languages. e.g. with IMPORT being able to say FROM.

JavaScript:

import "module-name";
import { export1 as alias1 } from "module-name";

Should we be not able to do that because it's not in a block?

import "module-name"
import ["module-name"]
import [[export1 as alias1] from "module-name"]

import/partial "module-name" [export1 as alias1]

But to play devil's advocate for a moment, would it really kill the language to be able to look nice?

import "module-name"
import [export1 as alias1] from "module-name"

There was a backlash to ELSE that worked by literal looking ahead for the word "ELSE" (and Ren-C's ELSE certainly does not do that).

I do think literal lookahead for specific words is inelegant to allow in the main evaluator. It puts keywords into a part of the substrate that brags on being able to override and rename essentially anything: you can alias my-import: :import but you can't do my-from: :from. Having your hands cuffed on renaming is supposed to only happen once you've crossed the (Rebol -> Dialect) barrier.

Ren-C allows you to do it with variadics if you really want to, and I'm not sure if we have complete experience to say that it's bad in all instances.