|
rjmccall posted:Awesome. It feels awesome. How hard has it been to keep quiet about this for what seems a long time? rjmccall posted:I think we'd like a proper (hygienic, Scheme-like) macro system eventually. - How about a meta object protocol? I can't see how a class would define behaviour under 'for-in' loops ? - You have string interpolation, but no string formatting (yet?) - Do you normalize unicode identifiers? - Will there be named versions of .. and ... because i'm poo poo at remembering the difference. - Can't see any handling for runtime errors beyond option types, like exceptions. Did I miss something? But mostly, there are a lot of nice bits. Integer overflow protection, explicit casts between numeric types, no old style octal literals, underscores in numbers. Enums and match show a lot of thought. This is something other languages should steal. My main problem is really waiting for open source/non apple targets or environments.
|
#
¿
Jun 3, 2014 01:47
|
|
|
|
| # ¿ Apr 29, 2024 01:53 |
|
|
I'm not versed in Objective-C 
|
|
#
¿
Jun 3, 2014 02:29
|
|
|
rjmccall posted:hmm, yes, modeling multiple return values with tuples seems like a very interesting idea, but unfortunately we're totally booked right now, maybe we'll take it under advisement for a future release, please file a bug so you can track progress. as it is not an open project yet i imagine this will not be the last time you say this. quote:Declaring that type objects conform to a protocol intended for instances is an interesting question, because it's simultaneously (1) abstractly reasonable, (2) maybe somewhat marginal in value, and (3) sets off my "this is going to cause problems" instincts something fierce, although I'm not sure why. I like generators in python and use them a lot. I also like to be able to have different sorts of collections outside of the array/dict builtins. You can override other operators, but not 'foo in bar' (and yes i know it's actually for foo in bar). quote:I think we discussed it and decided that not normalizing was the right thing to do. IIRC, the problem is that locale-insensitive normalization is often not good enough, but making the compiler locale-sensitive would be a terrible idea. http://unicode.org/reports/tr15/ Last time i checked this seemed locale independent. Although if you're using identifiers for module names, and using it to search the filesystem, well, you might have a fun time as HFS+ does it's own normalization https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties quote:We have some really vague design points here, but we ran out of time for this release; the political reality is that we needed to make Cocoa feel really great so that we could get the space to do other things well. I think we want something that'll feel kindof like checked exceptions, but maybe with a unified error type and different expectations about how they'll be used (and possibly not using stack unwinding). But this is still up in the air. The c# team wanted to add checked exceptions, but they never surfaced. I'd rather see something like coroutines than real exceptions. quote:Yeah. The basic schedule I'm expecting / hoping for is "get 1.0 out the door, clean up the repository, release to open source", but of course, it's not my call. I am unsure of the politics, but i'm hoping for the best.
|
|
#
¿
Jun 3, 2014 03:02
|
|
|
rjmccall posted:My Unicode is not very strong. I understand that there are normalizations you can do which would unify some strings, and we should probably at least be doing those. They're about combining characters, as some letters can be stored as 'ü' or 'u+umlaut'. There are other ones like ligatures too, which have standard forms. NFC, NFD. There is another version (NFKD, NFKC) to handle some semantic similarities, mapping ligatures to individual letters, and numeric sub/superscripts into normal numbers. quote:The question is whether (case-sensitive) string equivalence is actually locale-insensitive, because that's what I would expect name lookup to use in a maximally Unicode-aware world. Case sensitivity is a different issue, and of course, unicode has a thing for this: casefolding
|
|
#
¿
Jun 3, 2014 03:46
|
|
|
Axiem posted:The insane power of the case statements in Swift is one of my favorite features of the language. It just gives you so much power compared to most languages. I'm hearing the usual slew of things about swift, "It's proprietary" (yep, and it locks you in just as much as using objective-c does) but isn't really a language or platform for anything but apple dev. However one thing I am hearing over and over is both the enums and case statements. I dunno about using swift but I certainly hope other languages pinch them.
|
|
#
¿
Jun 7, 2014 16:58
|
|
|
|
| # ¿ Apr 29, 2024 01:53 |
|
|
Axiem posted:This might be my lack of functional programming background speaking here, but what's the big deal with tail recursion? And why would I as a programmer even care whether or not the language is doing it--isn't it something under the hood anyway? as others have said, sometimes it's easier to implement things recursively. one case in particular stands out: state machines. one function for each state, call the function to change to that state. when you have tail call elimination, your stack won't grow as you change states. there are other ways to simulate this though, and i usually end up with a trampoline functions instead.
|
|
#
¿
Jun 22, 2014 12:18
|
|