4 ms·

> Notice how not a single variable in this code has a name. They all only have types. Pretty cool, never even thought about this being possible.

evincarofautumn 12y ago
It’s not a novel idea, but Wake does it quite well. Most variable names aren’t that useful—they’re just one of many possible syntactic ways to plumb values around.
- seanmcdirmid 12y ago
  I've been playing around with an idea to replace variable names with brands. So say you have an argument to a procedure: brand position <- Point Position is a point, but is not a distinct type. You can document it centrally and not for each time it is used as an argument to a procedure or as a variable. E.g. def Set(position): ... You have define brands before you can define your procedure, but multiple procedures can share brands they use to declare their arguments.
  - kazinator 12y ago
    So position is like a typedef that you can use without a name, because it is self-naming. Obvious problem: def Drawline(position, position): ... Oops! We now need a position0 brand and a position1 brand, both of which are aliases for Point.
    - seanmcdirmid 12y ago
      They aren't just type aliases, they actually have unique slots in the symbol table when used so...you define more brands :) brand position <- Point brand start-position <- position brand end-position <- position def DrawLine(start-position, end-position): ... = start-position + ... ... = end-position - ... But that is kind of annoying, brand composition as adjectives would probably work better: brand position <- Point brand start brand end def DrawLine(start&position, end&position): ... = start&position + ... ... = end&position - ... Very natural language, and start/end can be used to qualify all variables that are starty or endy. The biggest problem with the approach is that you have to think ahead of time about what your variables mean, and they might become fairly verbose (so "start position" rather than "startp"). Also, when you get into the implementation, it is kind of tiring to think about what every local variable should mean, so maybe this only really works for procedural parameters and maybe to help define fields. I've been thinking about this for awhile, but haven't put it into a prototype yet.
- chipsy 12y ago
  The canonical example is how it's done in Forth: Ask for a number and it's already on the stack. Ask for three numbers and you push onto the stack three times. Upside: Terse code. Downside: Stack juggling can be a big maintenance burden. FWIW I've realized that in languages that are variable centric, an anonymous naming convention is often preferable to a human name because it centers one's concerns around the algorithm. After studying the options for a while I now flip between descriptive word style and "single letter and number." So I have a lot of "x0, x1, i0, s0, a0" in my function arguments. Where it's a record type, I'm deciding between abbreviation and descriptive - which ultimately depends on how often and densely I expect the data structure to be accessed(short names imply it gets used in a dense, idiomatic style).
  - evincarofautumn 12y ago
    Yep. I am working on a statically typed stack-based language, as I quite like the Forth style. Stack manipulation sucks, so I mainly use locals for auxiliary parameters, to get them out of the way of the main data structure or values that a definition is manipulating implicitly. For example: define do_the_thing (Foo bool -> Bar): -> should_log; if (should_log): dup log_foo foo_to_bar if (should_log): dup log_bar
munro 12y ago
That's how I find functions in Haskell! [1] Most of the time searching the type will give you the function you need. [1] https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%5ba%5d+-%3E+%5bb%5d https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%...
PeterisP 12y ago
It kind of fits how we'd talk in natural language about many common fragments of code. I mean, if I write a small function doSomething(inputDataString) then when talking about what the function does, I'd just refer to "the string" or "that string" as there really can be no more meaningful name to refer to that. If there are multiple such parameters, only then names start making sense. Similarly for iteration constructs like java 'for (Foobar foobar : foobars)' - when you're talking about what is done with that single instance of foobar, you just refer to it as 'a foobar' or 'every foobar', and a specific name is often meaningless if you don't need to distinguish it from others.

evincarofautumn 12y ago

It’s not a novel idea, but Wake does it quite well. Most variable names aren’t that useful—they’re just one of many possible syntactic ways to plumb values around.

seanmcdirmid 12y ago
I've been playing around with an idea to replace variable names with brands. So say you have an argument to a procedure: brand position <- Point Position is a point, but is not a distinct type. You can document it centrally and not for each time it is used as an argument to a procedure or as a variable. E.g. def Set(position): ... You have define brands before you can define your procedure, but multiple procedures can share brands they use to declare their arguments.
- kazinator 12y ago
  So position is like a typedef that you can use without a name, because it is self-naming. Obvious problem: def Drawline(position, position): ... Oops! We now need a position0 brand and a position1 brand, both of which are aliases for Point.
  - seanmcdirmid 12y ago
    They aren't just type aliases, they actually have unique slots in the symbol table when used so...you define more brands :) brand position <- Point brand start-position <- position brand end-position <- position def DrawLine(start-position, end-position): ... = start-position + ... ... = end-position - ... But that is kind of annoying, brand composition as adjectives would probably work better: brand position <- Point brand start brand end def DrawLine(start&position, end&position): ... = start&position + ... ... = end&position - ... Very natural language, and start/end can be used to qualify all variables that are starty or endy. The biggest problem with the approach is that you have to think ahead of time about what your variables mean, and they might become fairly verbose (so "start position" rather than "startp"). Also, when you get into the implementation, it is kind of tiring to think about what every local variable should mean, so maybe this only really works for procedural parameters and maybe to help define fields. I've been thinking about this for awhile, but haven't put it into a prototype yet.
chipsy 12y ago
The canonical example is how it's done in Forth: Ask for a number and it's already on the stack. Ask for three numbers and you push onto the stack three times. Upside: Terse code. Downside: Stack juggling can be a big maintenance burden. FWIW I've realized that in languages that are variable centric, an anonymous naming convention is often preferable to a human name because it centers one's concerns around the algorithm. After studying the options for a while I now flip between descriptive word style and "single letter and number." So I have a lot of "x0, x1, i0, s0, a0" in my function arguments. Where it's a record type, I'm deciding between abbreviation and descriptive - which ultimately depends on how often and densely I expect the data structure to be accessed(short names imply it gets used in a dense, idiomatic style).
- evincarofautumn 12y ago
  Yep. I am working on a statically typed stack-based language, as I quite like the Forth style. Stack manipulation sucks, so I mainly use locals for auxiliary parameters, to get them out of the way of the main data structure or values that a definition is manipulating implicitly. For example: define do_the_thing (Foo bool -> Bar): -> should_log; if (should_log): dup log_foo foo_to_bar if (should_log): dup log_bar

munro 12y ago

That's how I find functions in Haskell! [1] Most of the time searching the type will give you the function you need. [1] https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%5ba%5d+-%3E+%5bb%5d https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%...

PeterisP 12y ago

It kind of fits how we'd talk in natural language about many common fragments of code. I mean, if I write a small function doSomething(inputDataString) then when talking about what the function does, I'd just refer to "the string" or "that string" as there really can be no more meaningful name to refer to that. If there are multiple such parameters, only then names start making sense. Similarly for iteration constructs like java 'for (Foobar foobar : foobars)' - when you're talking about what is done with that single instance of foobar, you just refer to it as 'a foobar' or 'every foobar', and a specific name is often meaningless if you don't need to distinguish it from others.