Tulip – An untyped functional language • Hacker News Board

Re: Tulip – An untyped functional language

#11

Post by a_c_s » Fri, Mar 27, 2015, 8:40 PM UTC

evincarofautumn wrote: post #5

wyager wrote: post #4

"I’ve renamed the language from Unf to Tulip, because some folks pointed out that the old name created an unnecessarily sexualized environment" Are fifth graders critiquing programming languages now? Seriously, who makes that association and then feels the need to comment on it?

“Unf” is quite widely used as a spelling of a moan, to express sexual desire or gratification. While it can be used to express non-sexual enjoyment, the sexual connotation it evokes is just unnecessary when it comes to a programming language, regardless of the original intent.

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

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

Re: Tulip – An untyped functional language

#12

Post by namanbharadwaj » Fri, Mar 27, 2015, 8:40 PM UTC

duaneb wrote: post #3

Note that it definitely has types, they just aren't required explicitly. It seems to use dynamic type matching.

It's unityped! It has one type with infinitely many variants/tags (.). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.

Re: Tulip – An untyped functional language

#13

Post by evincarofautumn » Fri, Mar 27, 2015, 8:41 PM UTC

a_c_s wrote: post #11

evincarofautumn wrote: post #5

Earlier quoted context omitted.

“Unf” is quite widely used as a spelling of a moan, to express sexual desire or gratification. While it can be used to express non-sexual enjoyment, the sexual connotation it evokes is just unnecessary when it comes to a programming language, regardless of the original intent.

While I've never seen this use personally, UrbanDictionary very strongly corroborates this. http://www.urbandictionary.com/define.php?term=unf

It’s worth noting that “universal noise of fucking” is a backronym—the word was originally onomatopoeic.

Re: Tulip – An untyped functional language

#14

Post by _pmf_ » Fri, Mar 27, 2015, 8:46 PM UTC

This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).

Re: Tulip – An untyped functional language

#15

Post by duaneb » Fri, Mar 27, 2015, 9:04 PM UTC

jneen wrote: post #8

duaneb wrote: post #3

Note that it definitely has types, they just aren't required explicitly. It seems to use dynamic type matching.

Yep! It focuses more on dynamic type-checks than on static typing though, so I put it in the category of "untyped functional" - more like clojure and erlang than haskell or ml.

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.

Re: Tulip – An untyped functional language

#16

Post by duaneb » Fri, Mar 27, 2015, 9:06 PM UTC

namanbharadwaj wrote: post #12

duaneb wrote: post #3

Note that it definitely has types, they just aren't required explicitly. It seems to use dynamic type matching.

It's unityped! It has one type with infinitely many variants/tags (. ). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.

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.

Re: Tulip – An untyped functional language

#17

Post by david-given » Fri, Mar 27, 2015, 10:05 PM UTC

evincarofautumn wrote: post #5

wyager wrote: post #4

"I’ve renamed the language from Unf to Tulip, because some folks pointed out that the old name created an unnecessarily sexualized environment" Are fifth graders critiquing programming languages now? Seriously, who makes that association and then feels the need to comment on it?

“Unf” is quite widely used as a spelling of a moan, to express sexual desire or gratification. While it can be used to express non-sexual enjoyment, the sexual connotation it evokes is just unnecessary when it comes to a programming language, regardless of the original intent.

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

Re: Tulip – An untyped functional language

#18

Post by rdtsc » Fri, Mar 27, 2015, 10:05 PM UTC

_pmf_ wrote: post #14

This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).

Easier to type too. No need to press the shift key.

Re: Tulip – An untyped functional language

#19

Post by chubot » Fri, Mar 27, 2015, 10:08 PM UTC

This looks cool -- is there any source code? What language is it written in?

"Tulip is still in active development, and I could use a whole lot of help, both filling in the design gaps here and actually churning out the implementation"

Re: Tulip – An untyped functional language

#20

Post by jewel » Fri, Mar 27, 2015, 10:52 PM UTC

_pmf_ wrote: post #14

This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).

This would be an easy text-transformation that you could do in vim. Upon opening the file, translate all dashes without spaces "foo-bar" to add spaces "foo - bar". Then convert all underscores to dashes. "foo_bar" to "foo-bar". On save, invert the process.

You'd have to actually run the language's parser in order to do the transformation to avoid changing strings, and even then it'd only work if the parser output kept track of the original line and character so that you could know where to make the change.

This sort of text-transformation is something I've long wished my text editor did. At a previous job the standard was three-spaces of indent, regardless of the language.