Changes to naming conventions: request for suggestions

[lmorg]

The builtins are pretty undiscoverable at the moment and that's an issue because of the number of builtins that are included with Murex.

The original naming convention borrowed inspiration from old UNIX idioms but I don't think that works as well now this shell has matured

I experimented a while back with aliases for common array-based operations with a list prefix:

murex-dev» runtime --aliases -> [{ $.k=~"^list" && printf "%15s: %s" $.k $.v.alias.0 }]
   list.reverse: mtac
      list.sort: msort
     list.split: jsplit
    list.append: append
     list.regex: regexp
    list.string: match
    list.suffix: suffix
      list.left: left
     list.right: right
    list.prefix: prefix
   list.prepend: prepend

So I'm thinking of expanding this out:

• list: anything that reads and returns an array (even if that operation supports an array length of 1)
• list.new.str: would point to a
• list.new.type: would point to ta
  • I'll probably deprecate ja as a builtin and have it as an alias to ta json. Because ja is already served by %[] and having a separate builtin just adds to the noise.
• struct or data: anything that can read any kind of structure (object / map or array). The output need not be a structure. So something like count would be a struct.count
• struct.new or data.new: functions used to generate structs (eg 2darray and map)
• sys: functions like os, cpuarch, cpucount
• escape: escaping functions like escurl
• fs: filesystem operations (Changes to naming conventions: request for suggestions #860 (reply in thread))

That will still leave a whole lot of stuff uncaptured, but it's a start.

why do this?

My thinking is purely around discoverability.

1. Stage one: create aliases to get a feel for if the naming convention works. I wont document those alises at first, I just want us to get a feel for what works and what doesn't.

2. Stage two: swap the aliases and builtin. So that the builtin names then become list.regex and the alias is regexp. This should retain backwards compatibility while also allowing the website documentation to having things grouped in a more helpful way. eg

The ultimate goal is to make it easier for new people to start using the shell.

suggestions required

So what I'm looking for is some advice and suggestions around sensible prefixes. Is the examples above sane or not? Can you think of other category names?

Is this idea even a good one? Am I over thinking things and creating a bigger problem?

[lmorg]

Maybe instead of struct, we used data? I don't love struct as a prefix but I'm not entirely sold on data either.

[tiymat]

I'd agree that with so many builtins, discoverability can be a challenge.

Maybe a types prefix that could encompass format, cast, tout and possibly more I can't bring to mind right now?

fs for f, g, tmp, and lockfile?

[lmorg]

Good idea re fs. added that to the brief in the opening post

[lmorg]

Also how about shell for aliases for core murex operations like alias, function, etc. I'd always keep probably these as aliases rather than rename the builtins though.

[lmorg]

I've been having some second thoughts about this plan. On the one hand I quite like the idea of having pseudo-namespaced builtins to keep things organized and discoverable. But on the other hand, it does create multiple ways to do do something. Which is a little less appealing.

This is something that probably should have been implemented from day one but now I'm not too convinced it's a worthwhile change.

Definitely open to some opinions on this matter.

What I have done in the meantime is added support for documentation to have subcategories (basically just tagging). And the website can now group similar items. eg: https://dev.murex.rocks/commands/

I think this a good starter to solving the discoverability problem