Simplifying UCL
I've been using UCL for several days now in that work tool I mentioned,
and I'm wondering if the technical challenge that comes of making a
featureful language is crowding out what I set out to do: making a
useful command language that is easy to embed.
So I'm
thinking of making some simplifications.
The first is to
expand the possible use of pipes. To date, the only thing that can
travel through pipes are streams. But many of the commands I've been
adding simply return slices. This is probably because there's currently
no "stream" type available to the embedder, but even if there was, I'm
wondering if it make sense to allow the embedder to pass slices, and
other types, through pipes as well.
So, I think I'm going to
take a page out of Go's template book and simply have pipes act as
syntactic sugar over sequential calls. The goal is to make the construct
a | b
essentially be the same as b (a)
, where the first argument of
b
will be the result of a
.
As for streams, I'm thinking
of removing them as a dedicated object type. Embedders could certainly
make analogous types if they need to, and the language should support
that, but the language will no longer offer first class support for them
out of the box.Â
The second is to remove any sense of
"purity" of the builtins. You may recall the indecision I had regarding
using anonymous procs with the map
command:
I'm not sure how I can improve this. I don't really want to add automatic dereferencing of identities: they're very useful as unquoted string arguments. I suppose I could add another construct that would support dereferencing, maybe by enclosing the identifier in parenthesis.
I think this is the wrong way to think of this. Again, I'm not here to
design a pure implementation of the language. The language is meant to
be easy to use, first and foremost, in an interactive shell, and if that
means sacrificing purity for a map
command that supports blocks,
anonymous procs, and automatic dereferencing of commands just to make it
easier for the user, then I think that's a trade work taking.
Anyway, that's the current thinking as of now.