add normal-looking aliases to standard library gates

[jalehman]

The four-letter names are clever, but in cases where there are well-defined names for concepts in the rest of programming, we should use them.

TODO:

• Completion pass — what else should be included/excluded?
• Bikeshed
• Add documentation of the caliber found in sequent
• More bikeshedding

[tacryt-socryp]

Fun bikeshed:
Organizing aliases in one place, perhaps in its own file, or at least core, indexed by data structure would be nice as a way for people, particularly new people, to quickly find what they're looking for.

For instance, though perhaps the name shadowing is not ideal:

++  list
  |%
  ++  append  snoc
  ++  transform  turn
  ...
  --
::
++  map
  |%
  ...
  --
::
++  set
  |%
  ...
  --

I could imagine pointing people to this "alias" file in the standard library instead of hoon.hoon

[jalehman]

This would mean that, assuming your example, they'd be accessed as append:list, right?

[tacryt-socryp]

Yes, which is very explicit and predictable (good for newcomers). The other advantage is that all the "nicely named" functions would be together, which would make them easier to find and use for newcomers. I imagine =, and =* could be sufficient for making them more ergonomic in practice.

=/  a  (gulf 0 8)
=*  l  list
(append:l a 9)

[jalehman]

If I had map or set as arms in that core, would they not conflict with the molds of the same name? Same for list I guess.

[tacryt-socryp]

Yes, hence my comment that the name shadowing in my suggestion isn't ideal... I just can't help but think there's a better naming scheme for things than having no outer core name, like the list utilities, or "by", "in", etc that have no relation to what they do.

[jalehman]

Yeah, I think you're on to something here. Making naming more regular across the board at the expense of verbosity seems like a net positive. A dumb way to do it:

++  liblist
  |%
  ++  append  snoc
  ++  transform  turn
  ...
  --
::
++  libmap
  |%
  ...
  --
::
++  libset
  |%
  ...
  --

[tacryt-socryp]

One idea... these are all "collections" of things, and potentially could have their type in them as well.

++  collections
  |%
  ++  list
    |%
    ++  mold  ^list
    ++  transform  turn
    ...
    --
  ::
  ++  map
    |%
    ++  mold  ^map
    ...
    --
  ...
  --

Usage:

=,  collections
=/  a=(mold:list @)  (gulf 0 9)
(transform:list a inc)

[belisarius222]

I've thought for a while we might want to structure the stdlib like this:

++  list
  =<  form
  |%
  ++  form  |$  [a]  $?(~ [i=a t=$])
  ++  flop  |*(...)
  ++  turn  |*(...)
  ...
  --

This way you can still use list as a mold builder without qualifying it, but list-related functions would be inside the list core (they'd be in the context of the form:list gate). You'd call turn:list unless you first had a =, list to allow unqualified turn or a =* l list to allow turn:l, as @tacryt-socryp mentioned.

[tacryt-socryp]

That sounds great Ted