Am I the only one who knows what "strongly-typed" even means anymore???
-
MS Research announced a new language, Koka.
http://www.rise4fun.com/koka/tutorial
http://www.rise4fun.com/koka/tutorial
http://www.rise4fun.com/koka/tutorial
http://www.rise4fun.com/koka/tutorial
http://www.rise4fun.com/koka/tutorialFrom their tutorial:
Types
Koka is also strongly typed.From the example that comes literally 4 paragraphs before that statement:
base = (c - 'a').int
Uh? Guyz? Guyzzz? Your "strongly-typed" language just SUBTRACTED A CHAR FROM AN INT!
In their defense, there's a long history of language that claim to be strongly-typed making this EXACT SAME ERROR, but it still boggles my mind. Just because C, that primitive barely-more-than-assembly bullshit, confused
char
s andint
s, some developers and even language designers think it's just a natural thing forchar
s andint
s to be interchangeable.EVEN IN LANGUAGE DEVELOPED AFTER UNICODE WAS A THING!
This annoys me.
-
c
is a character and they subtracted a character and then converted it to an int. I see no issue with this.
-
It's as if you enjoy pedantic, thousand-post arguments on what a "strong type system" really means, and why subtracting a char from an int is or is not a valid operation under such system.
Because honestly, you should see it coming on an express track.
-
Also:
Koka uses a simple layout rule where semi-colons are automatically inserted
Three or so paragraphs in and I already hate the language. Good marketing.
-
c is a character and they subtracted a character
How do you subtract a character from another character? They're not numeric types, they're not sets, I'm not sure where else the "subtraction" operation is defined but characters aren't it.
Let me guess...
'd' - 'c' = 'l'
?
-
http://www.rise4fun.com/koka/tutorialhttp://www.rise4fun.com/koka/tutorialhttp://www.rise4fun.com/koka/tutorialhttp://www.rise4fun.com/koka/tutorialhttp://www.rise4fun.com/koka/tutorial
Why linked five times?
Why fuck that up, Discourse? Useless piece of shit.
-
Let me guess... 'd' - 'c' = 'l'?
Depends on the font
Oh wow! thanks to discourse dicosistency, this reply works on so many levels (well at least 2, anyway)
-
Hm.
A novel part about Koka is that it automatically infers all the side effects that occur in a function. The absence of any effect is denoted as total (or <>) and corresponds to pure mathematical functions. If a function can raise an exception the effect is exn, and if a function may not terminate the effect is div (for divergence).
Someone call that Turing guy...
-
Is this a Table of Contents? I can't tell.
s.encode(3) does not select the encode method from the string object, but it is simply syntactic sugar for the function call encode(s,3) where s becomes the first argument.
GTFO.
-
Also:
Koka uses a simple layout rule where semi-colons are automatically inserted
Three or so paragraphs in and I already hate the language. Good marketing.
There's a difference between semicolon insertion like Javascript, which is pants-on-head retarded, and optional semicolons like Python and Scala, which is just fine. I didn't read far enough to find out if this statement was inaccurate and they actually meant the other.
-
and if a function may not terminate the effect is div (for divergence).
Someone call that Turing guy...
https://doc.rust-lang.org/reference.html#diverging-functions ?
6.1.3.3 Diverging functions
A special kind of function can be declared with a
!
character where the
output type would normally be. For example:fn main() { fn my_err(s: &str) -> ! { println!("{}", s); panic!(); } }
We call such functions "diverging" because they never return a value to the caller. Every control path in a diverging function must end with a
panic!()
or a call to another diverging function on every control path. The!
annotation does not denote a type.It might be necessary to declare a diverging function because as mentioned previously, the typechecker checks that every control path in a function ends with a
``` fn main() { fn my_err(s: &str) -> ! { panic!() }return
or diverging expression. So, ifmy_err
were declared without the!
annotation, the following code would not typecheck:fn f(i: i32) -> i32 { if i == 42 { return 42; } else { my_err("Bad number!"); } }
}
<p>This will not compile without the <code>!</code> annotation on <code>my_err</code>, since the <code>else</code> branch of the conditional in <code>f</code> does not return an <code>i32</code>, as required by the signature of <code>f</code>. Adding the <code>!</code> annotation to <code>my_err</code> informs the typechecker that, should control ever enter <code>my_err</code>, no further type judgments about <code>f</code> need to hold, since control will never resume in any context that relies on those judgments. Thus the return type on <code>f</code> only needs to reflect the <code>if</code> branch of the conditional.</p>
-
Well, the Wikipedia article on that exact issue is very clear:
These terms do not have a precise definition
So you can't say "it's strong" or "it's weak". You can at best say "it's stronger" or "it's weaker", and only after a lengthy
shitflingingcivilized debate.
-
-
Flips coin....tails...yeah :)
-
In Cool, that's called
Nothing
, so Rust functions that returnNothing
are labeled with "!
". Which apparently means "Nothing
".
-
c is a character and they subtracted a character
Ok; and what does it mean to subtract a character from a character?
I want to subtract @ from }. What's the result? Why?
-
Why linked five times?
Why the fuck not? It's my post, I put what I want in there.
-
So you're saying that a character type is only "strongly typed" if it's impossible to write code that operates on it?
By the way, the answer is =. Because Unicode.
-
Ok; and what does it mean to subtract a character from a character?
That turned out uglier than I expected. Not sure what I expected, but that wasn't quite it.
-
So you're saying that a character type is only "strongly typed" if it's impossible to write code that operates on it?
?
There are operations that are valid on character types. For example, you can attempt to capitalize one. You can compare one to another to find which should sort first.
You can't add or subtract them, though, that doesn't make any fucking sense. That's just carrying-forward C's brain-dead brokenness out of habit and "we've always done it that way". (The fact that characters have a numeric identifier is implementation detail and should not be exposed so easily.)
-
http://www.rise4fun.com/koka/tutorial
is 404-ing for me at the moment. This annoys me.Did they give up the language already?
Edit: it's back.
-
For example, you can attempt to capitalize one.
Okay, I capitalize
i
. Do I getİ
?I
?ɪ
?You can compare one to another to find which should sort first.
The fact that characters have a numeric identifier is implementation detail
So what do you propose we use to compare them if not the numeric identifier? The number of pixels when rendered in a certain font? The English name of the letter? Does
I
come before or afterh
? How about'
?
-
Okay, I capitalize i. Do I get İ? I? ɪ?
You get blakey telling you to search "attempt" in a dictionary.So what do you propose we use to compare them if not the numeric identifier?
You use their alphabetical order. What than means outside of any specific collation is an exercise for the reader.
-
So what's the implementation of the "alphabetical order"? Maybe we can define it to be
int compare(char a, char b) { return (int)(a - b); }
-
So what's the implementation of the "alphabetical order"?
IT DOESN'T MATTER!!!!!!!!!!!! IT'S A DETAIL!!!!!!!!!!!Also, yes.
Except you should stick the return value to one of -1, 0, 1.
-
Except you should stick the return value to one of -1, 0, 1.
That's not in the contract for Comparer and if you depend on that your code is guaranteed to break.
-
So what's the implementation of the "alphabetical order"? Maybe we can define it to be
int compare(char a, char b) { return (int)(a - b); }
In some locales for some ranges of characters it might be
a.getUnicodeCodePoint - b.getUnicodeCodePoint
, but it should never be what you wrote because you're still subtracting a character from a character.
-
Maybe we can define it to be int compare(char a, char b) { return (int)(a - b); }
Maybe we can also define
tolower()
as:int tolower(int c) { return ((c >= 'A' && c<= 'Z') ? c + 32 : c); }
-
Ok. I stand corrected. But neither does the contract specify it should return a meaningful offset.
-
Okay, I capitalize i. Do I get İ? I? ɪ?
DEPENDS ON WHAT LOCALIZATION YOU PASS IN! You know this, you are not stupid.
Face it, Ben, I'm so right here that here's no way you could even pretend I'm not right and everything you type in this thread is just going to be a very strange spelling of, "oh Blakeyrat, you are so correct you blew my mind".
-
So what do you propose we use to compare them if not the numeric identifier?
I propose the only comparison you can make is sort order, and that is dependent on localization.
You seem to be working from this assumption that you "must" be able to add and subtract characters, which MAKES NO SENSE.
-
Still don't get what duck typing is good for.
You can do the same thing in a strongly defined language with interfaces, and you get the failures at compile time.
All without caring what types things are.
public IQuacker { void Quack(); } public IWaddler { void Waddle(); } public ISwimmer { void Swim(); } public class Fish : ISwimmer { ... } public class Duck : ISwimmer, IWaddler, IQuacker { ... }
-
You're the only one in this topic who's even MENTIONED duck typing. What the fuck?
-
You seem to be working from this assumption that you "must" be able to add and subtract characters, which MAKES NO SENSE.
If that functionality is needed, you can make a new type or make a method that does it for you.
Would you be ok with casting to an int first to perform the math?
-
Well, if it's not strongly typed or duck typing....
It's just a fuckup.
I mean, I look at that, and I'm hoping they have some good reason for doing it.
Even if they don't know the right term to be using.
C++ is a clusterfuck. It really just is.
The way it handles pointers, the fact that it masks types as other types which allows you to do all kinds of nonsensical things.
All for backwards compatibility with C.
"Hey look, you can use our compiler on your old code".
Which, I guess led to its quick adoption.
But that broke the concept of having languages fulfill purposes
-
Would you be ok with casting to an int first to perform the math?
Not if it's a simple cast. I'd be fine with it if it was something like another_sam's example.
-
Yeah, that makes perfect sense.
Because what if you compiled with a different character set (like ebcdic instead of ascii), and all of the sudden all your "character indexing" fails hard.
-
You're still missing the point entirely.
The fact that character even have numeric identifiers is implementation detail.
-
You're the only one in this topic who's even MENTIONED duck typing. What the fuck?
You got @xaade'd.
-
And if it's part of the language directly? With a defined implementation?
IMO, the way characters are treated as ints in C++ should be considered undefined, if it isn't already.
(just remembered void pointers..... shudders)
-
And if it's part of the language directly?
YOU STUPID FUCKER COW TURD THIS IS A BRAND NEW LANGUAGE THE PAPER WAS PUBLISHED IN 2012!
Jesus. Ok.
No more replying to Xaade. Not until he grows an IQ point or two.
-
Two different thoughts there.
-
It should be fine for direct casting, as long as that's specified in the language directly.
-
If it works like C++ char is a byte crap, that should be undefined, and that example would be labeled undefined, IFF this language spec was as professional as C++'s is. However, off the top of my head, I don't know if it is undefined in C++.
-
-
Not if it's a simple cast. I'd be fine with it if it was something like another_sam's example.
... what if you could use an implicit conversion method?
implicit char2int(c: Character): Integer = { c.getUnicodeCodePoint } val c = 'a' // Character val i = c.subtract(8) // subtract is called on an Integer implicitly created from c using char2int
-
val i = c.subtract(8)
Ok, I'm becoming aware that certain portion of this forum hates operators.
or maybe they hate expressions
-
What if giant purple monkeys fell from the moon!?
Look, whatever. Pedantic dickweed away.
The point is, a "strongly-typed" language designed in 2012 shouldn't have made this extremely basic mistake.
-
Curious tangent.
Do you think non-strongly-typed languages are bad?
-
However, off the top of my head, I don't know if it is undefined in C++.
I'm okay with
char
being 8 bits, because then the choice to pass around UTF-8 in C strings becomes a simple solution for Unicode in C/C++.
-
I'm not talking about the data size.
I'm ok with simple char taking up 8 bits as well.
What I'm not ok with, is it simply being identical to a BYTE in nature, and having no strong typing between the two.
For the same reason that I don't store non-computational numbers (zip code) in bytes either. I store them in strings (most of the time, in data-contexts that don't have robust type systems).
In a strong-typed language, I'm tempted to make a new type.
It's the same reason you don't make an iterator a straight up int either. Implementation details are hidden, the iterator could be a pointer, or an int as an index.
But you don't get to rip it out, add 'c' to it, and not be able to predict what will happen.
###Or worse yet, change what will happen just by changing the character set you compile against.
-
I don't think that's quite correct. Rust functions that never return are labeled
!
. It's not that they don't return anything, it's that they alwayspanic!
.
-
Nothing
is notUnit
.Unit
is a type with exactly one value.Nothing
has no values and therefore can never be seen by code at runtime.There's also the
Null
type which is a bit weird - it's a type with exactly one value, but it inherits from every type apart fromUnit
,Int
,Boolean
, andNothing
.