I’ve been thinking a little about how to support indexing in UCL, as in getting elements from a list or keyed values from a map. There already exists an index builtin that does this, but I’m wondering if this can be, or even should be, supported in the language itself. I’ve reserved . for this, and it’ll be relatively easy to make use of it to get map fields. But I do have some concerns with supporting list element dereferencing using square brackets.

Thought I’d take a little break from UCL today. Mum found a collection of old cassette tapes of us when we were kids, making and recording songs and radio shows. I’ve been digitising them over the last few weeks, and today the first recorded cassette was ready to share with the family. I suppose I could’ve just given them raw MP3 files, but I wanted to record each cassette as two large files — one per side — so as to not loose much of the various crackles and clatters made when the tape recorder was stopped and started.

A brief update of where I am with UCL and integrating it into Dynamo-browse. I did managed to get it integrated, and it’s now serving as the interpreter of commands entered in during a session. It works… okay. I decided to avoid all the complexities I mentioned in the last post — all that about continuations, etc. — and simply kept the commands returning tea.Msg values. The original idea was to have the commands return usable values if they were invoked in a non-interactive manner.

I’ve started trying to integrate UCL into a second tool: Dynamo Browse. And so far it’s proving to be a little difficult. The problem is that this will be replacing a dumb string splitter, with command handlers that are currently returning a tea.Msg type that change the UI in some way. UCL builtin handlers return a interface{} result, or an error result, so there’s no reason why this wouldn’t work. But tea.

The UCL simplifications have been implemented, and they seem to be largely successful. Ripped out all the streaming types, and changed pipes to simply pass the result of the left command as first argument of the right. "Hello" | echo ", world" --> "Hello, world" This has dramatically improved the use of pipes. Previously, pipes could only be used to connect streams. But now, with pretty much anything flowing through a pipe, that list of commands has extended to pretty much every builtins and user-defined procs.

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.

Well, I dragged Photo Bucket out today to work on it a bit. It’s fallen by the wayside a little, and I’ve been wondering if it’s worth continuing work on it. So many things about it that need to be looked at: the public site looks ugly, as does the admin section; working with more than a single image is a pain; backup and restore needs to be added; etc.

More on UCL yesterday evening. Biggest change is the introduction of user functions, called “procs” (same name used in TCL): proc greet { echo "Hello, world" } greet --> Hello, world Naturally, like most languages, these can accept arguments, which use the same block variable binding as the foreach loop: proc greet { |what| echo "Hello, " $what } greet "moon" --> Hello, moon The name is also optional, and if omitted, will actually make the function anonymous.

Came up with a name: Universal Control Language: UCL. See, you have TCL; but what if instead of being used for tools, it can be more universal? Sounds so much more… universal, am I right? 😀 Yeah, okay. It’s not a great name. But it’ll do for now. Anyway, I’ve started integrating this language with the admin tool I’m using at work. This tool I use is the impetus for this whole endeavour.

A bit more on TCL (yes, yes, I’ve gotta change the name) last night. Added both lists and hashes to the language. These can be created using a literal syntax, which looks pretty much looks how I described it a few days ago: set list ["a" "b" "c"] set hash ["a":"1" "b":"2" "c":"3"] I had a bit of trouble working out the grammar for this, I first went with something that looked a little like the following, where the key of an element is optional but the value is mandatory: