Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tulip – An untyped functional language

jneen.net

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Tulip – An untyped functional language

#51

Post by kazinator »

draegtun wrote: post #47
_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).

Perl6, Clojure, Racket, Rebol, Red, Factor & Forth are some other languages that allow hyphenated names. And I agree with you that hyphens are more readable. They're also good for adding extra semantic meaning - https://news.ycombinator.com/item?id=3978992

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.

Re: Tulip – An untyped functional language

#52

Post by kazinator »

thomasfoster96 wrote: post #38
_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).

I've been playing around with creating a toy language which treats '-' as a name for a function. It means there always needs to be white space around a - (the syntax of the language isn't like LISP), but that increases readability at the cost of two extra key presses.

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.

Re: Tulip – An untyped functional language

#53

Post by kazinator »

jneen wrote: post #9
lectrick wrote: post #6

> I strongly dislike macros that can hide in code. I get really frustrated when I open a source file and see (foo ...) and can’t tell whether it’s a function or a macro until I read documentation. Well... that's just, like, your opinion, man. Seriously though. In Elixir, for example, much of the language itself is implemented via its own macros, which demonstrates a certain nice extensibility. If Elixir followed this…

Yep, it's my opinion, and that's why I put it into the design. Lots of language design comes from opinions. I hope it's borne out. FWIW it's the same approach Rust has taken, where macros have to end with a ! to make them visually distinct.

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.

Re: Tulip – An untyped functional language

#54

Post by jerf »

iopq wrote: post #49
exprL wrote: post #45

Earlier quoted context omitted.

Not true (technically). When you add an integer to a char, you get an integer. (If you add a floating point number, the result is such as well.) You can, of course, use the integer you got like a char (after all, C's char is a small integer type) to get your gibberish. You can also use a floating point number as a char, because C has lax implicit conversions.

If you add '!' to '#' you get 'D', which is non-sense in any high level language.

Not true; you added the byte that happens to be identified in ASCII by !, 33, to the byte that happens to be identified in ASCII by #, 35, and get 68, which is D. This is all perfectly sensible and type safe, two 8-bit numbers being added to produce another 8-bit number; you are only confused by the surface syntax. There's plenty of high-level languages that will let you do this; there's all sorts of reasons to make numbers and the ASCII chars they represent easily usable for each other in source code.

Re: Tulip – An untyped functional language

#55

Post by jerf »

klibertp wrote: post #48
jerf wrote: post #34

Earlier quoted context omitted.

"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…

> 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 We're not discussing a concept of "type safety" here at all, but rather a concept of "untypedness". I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped". They are not : untyped language is one which has no type errors both on compile time and runt…

"I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped"."

You completely missed my point, as evidenced by the fact you appear to believe I just claimed that when I in fact claimed the exact opposite, which is that since darned near nothing is "untyped", that's not a useful concept to use in discussing whether something is "typed" or not.

Assembler is truly untyped. Forth is untyped. Tcl is not untyped... it simply has a built-in coercian rule that it'll turn everything into strings if it doesn't like what you do to it. It's as close as you can get, but it isn't untyped.

A concept that describes only two languages is not all tha useful.

"They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types."

Again, the fact that you appear to have completely missed my point is evidenced by the fact that I drew a distinction whereby languages may be "dynamically" or "statically" typed but darned near nothing is "untyped".

With all due respect, you're not in a position to be claiming that other people are "fanatics"... you don't have the information to come to that conclusion because you appear to be incapable of reading what people say, because you've already decided in advance what they're going to say. Yes, that makes the world look like... well... anything you want, really, but it's not a true description. You are not in a position to be complaining about other people's "critical thinking" skills when you yourself aren't even accurately gathering information with which to critically think.

Re: Tulip – An untyped functional language

#56

Post by iopq »

jerf wrote: post #54
iopq wrote: post #49

Earlier quoted context omitted.

If you add '!' to '#' you get 'D', which is non-sense in any high level language.

Not true; you added the byte that happens to be identified in ASCII by !, 33, to the byte that happens to be identified in ASCII by #, 35, and get 68, which is D. This is all perfectly sensible and type safe, two 8-bit numbers being added to produce another 8-bit number; you are only confused by the surface syntax. There's plenty of high-level languages that will let you do this; there's all sorts of reasons to make…

No, I didn't. I actually added the character '!' to '#'. The C language doesn't DISTINGUISH characters from their numerical representations. That's where I say it's weakly typed. It does not have an actual character type, it only has 8 bit numbers.

Of course in C it is perfectly logical. I am pointing out that it is not as strongly typed as other type systems that have richer types.

Re: Tulip – An untyped functional language

#57

Post by TazeTSchnitzel »

exprL wrote: post #46
TazeTSchnitzel wrote: post #35

Earlier quoted context omitted.

B and early C are untyped like this

Early C? The parent described accurately how pointer addition in C works for all char pointers. (Well, other than the “nobody wants that” part, because that's how you skip n bytes of a string.)

C has pointer arithmetic

Re: Tulip – An untyped functional language

#58

Post by klibertp »

jerf wrote: post #55
klibertp wrote: post #48

Earlier quoted context omitted.

> 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 We're not discussing a concept of "type safety" here at all, but rather a concept of "untypedness". I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped". They are not : untyped language is one which has no type errors both on compile time and runt…

"I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped"." You completely missed my point, as evidenced by the fact you appear to believe I just claimed that when I in fact claimed the exact opposite, which is that since darned near nothing is "untyped", that's not a useful concept to use in discussing whether something is "typed" or not. Assembler is truly untyped. Forth is unt…

> Tcl is not untyped...

Wikipedia page says otherwise. Why won't you edit it and fix it if you're sure it's a mistake?

> A concept that describes only two languages is not all that useful.

Which is why you decide to change the meaning of this concept? Or what are you getting at? Do you want to say that "lack of static typing" equals "untyped"?

> With all due respect, you're not in a position to be claiming that other people are "fanatics"... you don't have the information to come to that conclusion because you appear to be incapable of reading what people say, because you've already decided in advance what they're going to say. Yes, that makes the world look like... well... anything you want, really, but it's not a true description. You are not in a position to be complaining about other people's "critical thinking" skills when you yourself aren't even accurately gathering information with which to critically think.

You know, there's a difference between my attacking a general notion some (unspecified) people share and your directly insulting me. I wonder why did you choose to read my comment as targeted at you personally? Do you feel like a "static typing fanatic"? Did you write any of the things I was complaining about? Did you say that Python is untyped? Did you say that the only kind of types we can have are static types?

I'm re-reading your comments and can't see any of these. I wonder, why the heck would you, then, assume I was criticizing you specifically? Are you really going to defend people who say those things? You know better and, if you read our conversation once again, you'll see that we're in an agreement (except for TCL). Don't you see I'm talking TO you, not ABOUT you? Is my written English that poor (well, it may be so, sorry)?

Re: Tulip – An untyped functional language

#59

Post by kibwen »

lectrick wrote: post #50
jneen wrote: post #9

Earlier quoted context omitted.

Yep, it's my opinion, and that's why I put it into the design. Lots of language design comes from opinions. I hope it's borne out. FWIW it's the same approach Rust has taken, where macros have to end with a ! to make them visually distinct.

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 loo…

Rust does eat its own dogfood with regard to macros, and over time has steadily replaced former language-level features like `log` and `panic` with macros. Syntactic distinction is a philosophical choice in service of making costs more explicit (and while it's true that functions can hide behavior, overuse of macros can trigger enormous code bloat, such as the `regex!` macro which compiles your regex into a state machine).

(There are also valid technical reasons for requiring syntactic distinction, as the sheer flexibility of Rust's macros in their ability to create new syntax run the risk of making it a nightmare to parse if you remove the unambiguous ability of the compiler to drop into macro-parsing mode. These challenges aren't insurmountable, just very hairy.)

Post reply on HN