Tulip – An untyped functional language (opens in new tab)

Also, note that, in the same breath practically, you can support true negative integer constants:

   -1234

which are distinguished because there is no whitespace. You can distinguish the unary operator being applied to 1234 from a true -1234 constant.

> This sort of text-transformation is something I've long wished my text editor did.

Emacs does this in some cases: specifically for camelCasedWords (http://www.masteringemacs.org/article/making-camelcase-reada...) and for the word 'lambda' which can be displayed as a symbol. There are many other modes which "overlay" some text over how it looked originally.

Add to that list, GNU Make. In gmake, you sometimes need things that look like paths to be variable names:

   VAR_$(PATH) := whatever

where PATH could be path/to/foo-parser.o, say.

That might be because Rust might not eat its own dogfood in that department, and build some of its own functionality out of its macro system.

But I can see just "knowing" at a glance if it's a macro or not.

I think the answer would basically be determined by how much of the language itself uses its own macro system AND what type of macro system it actually is. If it's significant, having special syntax would just look weird.

If you see (foo ...) but don't actually know what foo does, it doesn't matter all that much whether it is a function or an operator. Even if you know it's a function, that just tells you how the arguments are evaluated; but not what happens with those values. Untold effects could hide behind a function call.

OK interesting, it actually appears to be written in RPython, not full Python:

https://github.com/jneen/tulip/blob/master/tulip/libedit.py

(RPython is the "static" subset of Python used to bootstrap PyPy)

>Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.

That is incredibly disingenuous. The only way a Haskell or ML program could be as colossally unsafe as a unityped language program is if the programmer used only one giant sum type for the entire program, and most functions in the program were non-total with respect to that type.

"Unityping" provides no static type safety. It is isomorphic to, and usually a euphemism for, the lack of any static type system.

If you customize your runtime behavior based on any metadata about the value on which you operate, you have multiple types. Attempting to change the syntax will not change the fact that you need to differentiate behavior for numbers and strings.

Well, dynamic types are still types. :) It also seems strongly typed through a lack of implicit conversions between types.

I would say this is more like go than anything, though it seems to lack methods (and interfaces) and includes a functional syntax.

You're going to run into issues when attempting to extend polymorphism for built-in functions to user-defined types—imagine trying to figure out how to sort an 'unknown' type without a way to compare them without modifying the method to be explicitly aware of the new type.

unnecessarily sexualized logo

she's doing a high kick away from the viewer?

While I've never seen this use personally, UrbanDictionary very strongly corroborates this.

http://www.urbandictionary.com/define.php?term=unf

As an counter datapoint, this is the first time I have ever heard of this.