Eukleides is decidedly not a golfing language, but when a geometry-related question came up on PPCG, I had to give it a shot. Eukleides can be quite rigid; for starters it is very strongly typed. Functions are declared by what they intend to return, so while
set would be the shortest way to declare a function, it can’t really be exploited (unless returning a set is, in fact, desired). Speaking of sets, one thing that is potentially golfable is ‘casting’ a point to a set. Given a point,
p, attempting a setwise operation on
p will fail because a point does not automatically cast to a set (strict typing).
p=set(p) will overwrite point
p with a single-item set containing the point that was
p. If, however, it is okay to have two copies of the point in the set,
p=p.p is three bytes shorter.
If user input is required, the command
number("prompt") reads a number from STDIN. The string for the prompt is required, though it can be empty (
""). Thus, if more than four such inputs (or empty strings for other purposes) are required, it saves bytes to assign a variable with a one-letter name to an empty string.
Whitespace is generally unavoidable, but I did come to realize that boolean operators do not need to be preceded by whitespace if preceded by a number. So,
if a==7or a==6 is perfectly valid.
7 or6 are all invalid, however. This may be an interpreter bug, but for the time being it is an exploitable byte.
Finally, loci. Loci are akin to for-loops that automagically make sets. Unfortunately, they don’t seem to care much for referencing themselves mid-loop, which meant that I couldn’t exploit how short of a construction they are compared to manually creating a set in a for-loop.
This was a fun exercise, and just goes to show that if you poke around at any language enough, you’ll find various quirks that may prove useful given some ridiculous situation or another.