31–40 of 59 posts
Earlier quoted context omitted.
https://github.com/jneen/tulip
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)
Earlier quoted context omitted.
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 'unkno…
There does seem to be a method/interface system (Under the "Methods, Protocols, Implementations" header). And it seems to have some sort of dispatch system for tagged structures that can be later modified by the user.
"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?
It was a decision I made, partly because I realized they were right, and partly because I think tulips are pretty. ) ( ( _) |/
she's doing a high kick away from the viewer?
Earlier quoted context omitted.
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.
> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics…
That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string.
Truly adding a number to a string looks like this:
number: 0x000000000000002a
string: 0x7ffb000000007264
result: 0x7ffb00000000728e
A term that describes essentially 100% of languages is not a useful one, so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime".
Earlier quoted context omitted.
> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics…
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string lo…
Earlier quoted context omitted.
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.
>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…
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).
Earlier quoted context omitted.
> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics…
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string lo…
Earlier quoted context omitted.
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)
They have moved towards treating RPython as a framework: http://rpython.readthedocs.org/