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

Language Design: Use 'ident: Type' not 'Type ident'

soc.me

Post reply on HN
Print view View original

171–180 of 192 posts

Re: Language Design: Use 'ident: Type' not 'Type ident'

#171

Post by lliamander »

Sharlin wrote: post #151
lliamander wrote: post #78

Earlier quoted context omitted.

I agree, though I could see the merit for a standalone declaration: val x: String x = "hello" The type at this point is almost like a comment. For declaration and assignment though, I agree that reading "ident: Type" is harder for me. Perhaps an interesting idea would be to have the type at the end of the expression . Like so: val x = "hello": String Essentially, you're making a type assertion on an expression. Since…

> Perhaps an interesting idea would be to have the type at the end of the expression. Like so: > val x = "hello": String Rust has had exactly this (so-called type ascription ) for a while in nightly, but it's not stabilized yet due to some unresolved issues.

Good to know!

Re: Language Design: Use 'ident: Type' not 'Type ident'

#172

Post by mamcx »

ogoffart wrote: post #140
mamcx wrote: post #81

Earlier quoted context omitted.

> The difference between Python, C++, Haskell, Common Lisp, Prolog, and SQL isn’t syntax Ok, let's try: Do SQL without the SQL syntax. P.D: I don't think we are that in disagreement ("The syntax just needs to be a decent enough interface to the semantics"), is that the claim of "syntax don't matter" make it look is just an irrelevant aspect of the language. Can be argued how much relevant, but after years on this tra…

> Ok, let's try: Do SQL without the SQL syntax. Select(`my_table`, [`column_A`, `column_B`]) .Filter(`column_C` > 53 && `column_D` == $varA) .Sort_by(`column_C`) There you go: you have the exact semantic as a traditional SQL query (1:1 mapping) and only the syntax is different. Now, one may argue that the syntax is "ugly", less familiar, that the ` are hard to type or whatever, but this is just taste. One simply get…

I was to talk about the SQL stuff, but I think it will be wasted as long we get blind to the fact syntax IS semantic.

However this:

> but the exact way they are written, not as much (as long as it is within reason)

Then what is "within reason?". Is more logical to only have GOTO than IF, is better to have ELSEIF or nest IF?, what happened if my lang say that null is the same than Option.None?, what if generics use [] and not ?.

Whitespace matter, yes? no?

Allow unicode?

CamelCase, snake_case or what? What if all const are lowercase, types mixcase and the rest UPPERCASE?

For some, APL syntax make more sense than algol.

Talk about why, that is the point of this kind of talk.

Is VERY easy to rug this kind of stuff. VERY. I WAS in that camp before. But now, I try to build my own lang (relational), and DAMM, it start to be much clear why syntax matter, even "the exact way they are written", because switch this to that and suddenly, my lang is ANOTHER paradigm (or worse, will be CONFUSED as be).

Naming, is one the hard things in computer science.

---

I understand why is easy to dismmis this as irrelevant. Sometimes I don't see why some people are so upset about typography and font selection, or why my profesional brother complain about framing in photograph. But go and SEE what the DESIGNERS of lang say about this stuff and you will note that for them, even this apparent less-significant thing matter. you can even get a prize on the field for show the importance of syntax (http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...)!

If that mean that most will not see, GREAT! That is the mark of good design.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#173

Post by klyrs »

andreareina wrote: post #125
klyrs wrote: post #76

Earlier quoted context omitted.

C is just riddled with mistakes and this one finally gelled with me. Python taught me that whitespace is great for syntax and, in this case, I'm quite convinced that it should be used more firmly in most languages.

Python's syntax precludes works against a lot of things, like first-class lambdas, case (yes it can be emulated with if/elif, but it's not the same, even without fallthrough), pattern-matching in general, or assigning the result of a method-chaining pipeline to a variable. I use python at $dayjob, and I run into the limitations of whitespace as syntax all the time.

Yeah, the switch thing is a mindboggle, but the associated pep makes it very clear that/why the problem is quite unsolvable.

https://www.python.org/dev/peps/pep-3103/

It's quite frustrating as there are a lot of situations where a simple switch would be so nice...

Re: Language Design: Use 'ident: Type' not 'Type ident'

#174

Post by marmada »

A benefit of ident: Type is that it allows you to express complex anonymous types.

Example from Typescript:

const foo: 'A' | 'B' | 'C' = 'A'

Which states that foo must belong to the given union type. How would this look in a Type ident language?

const 'A' | 'B' | 'C' foo

That doesn't seem right. There's no clear barrier between the type and the identifier name.

Here's another contrived example:

const foo: () => Promise = async (x) => console.log(x)

Here foo is of type "() => Promise". How would this look in a Type ident language?

const () => Promise foo = async (x) => console.log(x)

To me, this is unclear because it is hard to tell where the type ends and the actual function begins.

Last example.

const foo: { [string]: number} = {"hello": 3}

I believe says that foo is an object with string keys and number values.

What does this look like in a Type ident language?

const { [string]: number} foo = {"hello": 3}

I think all of the Type ident examples are more confusing because it's to tell where the type ends and the name begins (this is most clear in the first example). This probably makes syntax highlighting worse/parsing more complicated/is tougher on the user. With ident: Type, it is very clear that the type starts after the ":" and ends before the "=" sign.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#175

Post by earthboundkid »

saagarjha wrote: post #97
earthboundkid wrote: post #94

Earlier quoted context omitted.

A pointer to an int "should" be &int, not int*. That we use *, the dereference operator, to indicate pointers is wrong. * in a type means it's an address, but * in a value means it's not an address. That's nuts! Make it consistent and use & both places. If you need to have a distinction between refs and pointers, it should be that pointers are nullable refs: &int? or some such. Edit: How to escape asterisks in HN?

I’ve had luck with not putting something directly after the asterisk.

Apparently HN does not have an escape character which seems like a real oversight. :-/

Re: Language Design: Use 'ident: Type' not 'Type ident'

#176

Post by battery_cowboy »

MaxBarraclough wrote: post #156
battery_cowboy wrote: post #143

Earlier quoted context omitted.

Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.

You misunderstand. C++ is Turing-complete at compile time , due to template metaprogramming. This demonstrates that it isn't a context-free grammar. This isn't true of all programming languages.

Thanks, i see what you were saying now, i misunderstood your original comment.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#177

Post by battery_cowboy »

tom_mellior wrote: post #158
battery_cowboy wrote: post #143

Earlier quoted context omitted.

Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.

Yes, but it is the difference to other programming languages. In C you cannot encode a Turing machine that is executed by the compiler at compile time . In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time . In C++ you can encode a Turing machine that is executed by the compiler at compile time . That is the difference we are discussing here.

Yes i now realize that, thanks for explaining further. The original comment was worded in a way that i misunderstood the claim.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#178

Post by battery_cowboy »

wtetzner wrote: post #164
battery_cowboy wrote: post #119

Earlier quoted context omitted.

The original comment was about Turing completeness, and it was defined incorrectly. I was giving an example of a dead-simple language that was Turing complete, because the claim was that metaprogramming made C++ Turing complete.

The claim wasn’t that C++ is Turing complete, that’s trivially true. The claim was that C++’s grammar is Turing complete. I don’t know if that’s exactly the right way to phrase it, but C++’s template expansion stuff is Turing complete.

It was a weird phrasing to me, but i get what you were all saying now.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#180

Post by dllthomas »

kevin_thibedeau wrote: post #133
dllthomas wrote: post #108

Earlier quoted context omitted.

There's a perspective that doesn't seem to be noted yet, which is that int *f is declaring that *f will be an int. This perspective addresses why the star belongs with the name, why it's star instead of ampersand, why you need to repeat the star for multiple variables, why the brackets goes after the name for arrays, and it will sort of get you where you need to go with function pointers (although there's an automati…

Then someone comes along and typedefs a pointer to hide the "scary" double pointer syntax.

I don't think that actually breaks things. A typedef isn't purely syntactic substitution like a macro.

If we have

    typedef float *floatp;
then the following compiles:

    float x, y;
    floatp xp = &x, yp = &y;
while the following does not:

    float x, y;
    float* xp = &x, yp = &y;
You have defined a new type (which happens to be equivalent to an old type - note that we don't get nominal type-checking from typedefs); the above logic still holds.
Post reply on HN