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

    From 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 chars and ints, some developers and even language designers think it's just a natural thing for chars and ints 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.



  • @ben_lubar said:

    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'?





  • @another_sam said:

    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.



  • @Maciejasjmj said:

    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.



  • @Maciejasjmj said:

    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 return or diverging expression. So, if my_err were declared without the ! annotation, the following code would not typecheck:

    ``` fn main() { fn my_err(s: &str) -> ! { panic!() }
    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.



  • @loose said:

    Depends on the font

    I liked this, but you meant "typeface".



  • Flips coin....tails...yeah :)



  • In Cool, that's called Nothing, so Rust functions that return Nothing are labeled with "!". Which apparently means "Nothing".



  • @ben_lubar said:

    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?



  • @another_sam said:

    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.



  • @blakeyrat said:

    Ok; and what does it mean to subtract a character from a character?

    :hanzo:

    https://what.thedailywtf.com/t/am-i-the-only-one-who-knows-what-strongly-typed-even-means-anymore/50820/5?u=another_sam

    That turned out uglier than I expected. Not sure what I expected, but that wasn't quite it.



  • @ben_lubar said:

    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.)



  • @blakeyrat said:

    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.



  • @blakeyrat said:

    For example, you can attempt to capitalize one.

    Okay, I capitalize i. Do I get İ? I? ɪ?

    @blakeyrat said:

    You can compare one to another to find which should sort first.

    @blakeyrat said:

    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 after h? How about '?



  • @ben_lubar said:

    Okay, I capitalize i. Do I get İ? I? ɪ?

    You get blakey telling you to search "attempt" in a dictionary.

    @ben_lubar said:

    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); }



  • @ben_lubar said:

    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.



  • @Zecc said:

    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.



  • @ben_lubar said:

    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.



  • @ben_lubar said:

    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.



  • @ben_lubar said:

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



  • @ben_lubar said:

    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?



  • @blakeyrat said:

    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



  • @xaade said:

    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.



  • @blakeyrat said:

    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)



  • @xaade said:

    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.

    1. It should be fine for direct casting, as long as that's specified in the language directly.

    2. 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++.



  • @blakeyrat said:

    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


  • @another_sam said:

    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?



  • @xaade said:

    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 always panic!.



  • Nothing is not Unit. 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 from Unit, Int, Boolean, and Nothing.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.