jhass changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.18.7 | Fund Crystals development: http://is.gd/X7PRtI | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/crystal-lang/crystal | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/ | Logs: http://irclog.whitequark.org/crystal-lang
txdv_ has joined #crystal-lang
txdv has quit [Ping timeout: 264 seconds]
triangles2 has joined #crystal-lang
triangles has quit [Ping timeout: 265 seconds]
triangles2 has quit [Quit: Leaving]
Philpax has quit [Ping timeout: 244 seconds]
onethirtyfive has joined #crystal-lang
Philpax has joined #crystal-lang
onethirtyfive has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
A124 has quit [Ping timeout: 264 seconds]
onethirtyfive has joined #crystal-lang
onethirtyfive has quit [Remote host closed the connection]
bjz has joined #crystal-lang
aldum has joined #crystal-lang
bjz has quit [Read error: Connection reset by peer]
Philpax has quit [Ping timeout: 252 seconds]
hooo has quit [Read error: Connection reset by peer]
pawnbox has quit [Remote host closed the connection]
bjz has joined #crystal-lang
pawnbox has joined #crystal-lang
Philpax has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
bjz has quit [Ping timeout: 258 seconds]
bjz has joined #crystal-lang
pawnbox has quit [Ping timeout: 276 seconds]
pawnbox has joined #crystal-lang
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
ponga has joined #crystal-lang
A124 has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
ponga has quit []
pawnbox has joined #crystal-lang
Philpax has quit [Ping timeout: 250 seconds]
dome22xl has joined #crystal-lang
<dome22xl> I can't find any documentation on what this is useful for anyone ? class Foo(A, B, C); end; a = Foo(1,2,3).new; p a
<jhass> wait, that compiles?
<dome22xl> Yes it was
<dome22xl> it does*
<jhass> ah, I guess for StaticArray
<dome22xl> Yeah its just what someone wrote the other day in my bug i posted as puppetpies https://github.com/crystal-lang/crystal/issues/3132
<jhass> oh so you're wondering about generics in general?
<dome22xl> I was confused about how you could use this i'll have a read.
<dome22xl> So you can call T anything thats what was confusing now i see and you can have many if you want as different args
<jhass> yup
onionhammer has quit [Ping timeout: 264 seconds]
pawnbox has quit [Ping timeout: 264 seconds]
pawnbox has joined #crystal-lang
dome22xl has quit [Quit: Leaving]
Ven has joined #crystal-lang
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ven has joined #crystal-lang
Ven has quit [Client Quit]
Ven has joined #crystal-lang
Ven has quit [Client Quit]
Ven has joined #crystal-lang
Ven has quit [Client Quit]
Ven has joined #crystal-lang
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pawnbox has quit [Remote host closed the connection]
Ven has joined #crystal-lang
Ven has quit [Client Quit]
willl has joined #crystal-lang
maxpowa has quit [Ping timeout: 250 seconds]
maxpowa has joined #crystal-lang
<Papierkorb> Are there any syntax changes "ahead", or is the syntax as it currently is probably 'final'?
<Papierkorb> Expectations are fine, I don't expect anyone to have a all knowing crystal ball ;)
maxpowa has quit [Ping timeout: 250 seconds]
<jhass> I'm not aware of anything immediate but everything is still on the table
<jhass> for example select when was added as sugar over Channel.select just the other day
<jhass> there's still an open issue with nested struct field access that might warrant a syntax change
<jhass> there's some desire to unify lib and regular structs/unions more
<jhass> I can imagine a bit sugar for locking isn't out of question
<jhass> globals will probably go very soon (except for $~ and $?)
maxpowa has joined #crystal-lang
<jhass> single letter names will probably get disallowed for types to keep them free for free vars/generics
<Papierkorb> jhass: thanks
<jhass> oh and co/contra variance in generics might need syntax too
<Papierkorb> co/contra variance?
<Papierkorb> "if not of type T, use this"?
<jhass> put child class of T in Array(T)
<jhass> put superclass of T in Array(T)
<jhass> cast Array(T) to Array(T.superclass)
<jhass> stuff like that
<jhass> (cast Array(T.superclass) to Array(T))
<jhass> asterite: so generics for this cycle? much <3
<RX14> jhass, that doesn't fix using Object or Int as a class var does it?
<jhass> I don't think so
<jhass> it pretty sure it's groundwork towards
<jhass> *but
<RX14> mhmm
A124 has quit [Quit: '']
A124 has joined #crystal-lang
<BlaXpirit> jhass, why do you say globals will go?
<jhass> most people are in favor of it
<BlaXpirit> how do you know?
<jhass> note globals != global state
<BlaXpirit> ok
<BlaXpirit> i will not settle for using idiotic meaning classes
<BlaXpirit> meaningless*
<RX14> only for small hacky scripts are globals needed
<RX14> and in that case might as well use ruby
<RX14> i really don't think that it's a big deal
Oliphaunte has joined #crystal-lang
jwaldrip has joined #crystal-lang
<BlaXpirit> hm i found that one prominent use i had for globals could actually be constants
<RX14> mutable constants replace a lot of global usage
* BlaXpirit shudders at mutable constants
<RX14> well at least they can only have one initialization point
<RX14> which is the point of the change
<BlaXpirit> but it's gonna happe
<BlaXpirit> n
<RX14> ?
<RX14> did you read the technical reasons for removing them?
<BlaXpirit> did not convince me
<RX14> well both class vars and constants can be/are namespaced
<RX14> which is the code style reason
<RX14> and the technical reason is that global variables must have an initializer
<BlaXpirit> class vars can be namespaced inside a meaningless class, but not in a module
<RX14> for constants thats obviously the first and only assignment
<RX14> but for global vars it's a lot harder
<BlaXpirit> if I start a simple program, I have 2 options: use only pure functions, or put everything into a stupid class
<BlaXpirit> not very good prospects
<FromGitter> <drosehn> The issue for crystal is that crystal wants to detect many types of errors at compile-time, instead of run-time.
<RX14> BlaXpirit, https://carc.in/#/r/175m
<RX14> class vars work in modules
<BlaXpirit> RX14, well these are basically globals then anyway
<RX14> ...yes
<RX14> so are class vars
<RX14> as the issue stated multiple tmes
<RX14> this is not about removing mutable global state
<RX14> just global vars
<BlaXpirit> so, again, what is the problem with globals specifically if class variables are globals too?
<RX14> class vars have a defined initialization and typing point
<BlaXpirit> solution: require globals to have the same
<RX14> it looks to me like you didn't read it all
<RX14> do you really want def $foo syntax?
<RX14> i don't
<BlaXpirit> why def
<RX14> it looks ugly in ruby
<RX14> BlaXpirit, because what other initializer syntax is there
<BlaXpirit> $asdf : Thing = make_thing()
<RX14> so the first asignment?
<BlaXpirit> this is not an assignment, it's a declaration
<BlaXpirit> could drop the '='
<RX14> what if you want to leave off the global var's type
<FromGitter> <drosehn> For my purposes, getting rid of global variables isn't really going to be much of an issue. I took a simple program which had a few dumb global variables, added a `module` and `end`, changed the $-variables to @@-variables, added setter/getter methods, and it worked fine.
<RX14> then it's an assignment
am_ has joined #crystal-lang
<FromGitter> <drosehn> That might sound like a lot, but it was more work to type in that description than it was to make the changes to my script... :)
<RX14> again, it only affects hacky scripts which is ruby's market
<BlaXpirit> drosehn, these silly changes is exactly what I don't want because there is no meaning behind this
<RX14> plus the workaround is easy
<RX14> BlaXpirit, yes there is - again it seems like you havent read the issue
<BlaXpirit> goddammit what do you want from me
<BlaXpirit> i'm not saying class variables can't be used for global state, i'm saying it's stupid
am_ has quit [Client Quit]
am_ has joined #crystal-lang
<RX14> and i'm saying that the technical issues are most of the reason why
<FromGitter> <drosehn> <shrug>. It's a good idea to drop globals, even if it causes a tiny bit of extra work in a few cases. The larger the program, the more trouble you'll have from global variables. That's been true in my experience, at least. And crystal is geared towards larger programs, not small scripts. I do not see it as problem to get rid of $-variables for smaller programs.
<RX14> the compiler needs to tell the difference between declarations and assignments of global variables
<RX14> it's clear for class vars
<RX14> it's not for global vars
<BlaXpirit> yes, but it's not a reason to drop global variables
<RX14> yes it is because it makes it incredibly difficult for global variables to work in the compiler
<FromGitter> <drosehn> I did ponder the issue when asterite brought up the idea of dropping $-variables, and after a few hours of thinking about it (and a good night's sleep!), I gave a thumbs-up to the idea.
<am_> without globals, main function will need to pass the "ideally globals" to all function it calls, which in turn will need to do the same, possibly caring for "ideally globals" variables which doesn't use, but are used on the level below
<am_> either you have some Rust paranoid attitude, or it's a bad idea wiping out the globals
<RX14> no, this is not about removing global state
<BlaXpirit> RX14, it's about removing the reasonable way to have global state
<RX14> for flips sake it means declaring one module and using macros to declare your global vars
<RX14> it's not an appreciably large amount of extra effort
<RX14> and it's cleaner AND much easier for the compiler devs
<RX14> whereas you needed to write `$x = 0` you write `property self.x = 0`
<BlaXpirit> and come up with a meaningless wrapper
<BlaXpirit> i can only hope that in reality i'd be able to come up with some meaningful name for the wrapper
<RX14> you have to name the file you're working in anyway
<RX14> the module can be the same
<FromGitter> <drosehn> how about `class Globals` ?
<RX14> even that if you're lazy
<BlaXpirit> that's the worst class name i've seen in my life
<RX14> it's a hacky script if you're using global vars anyway
<FromGitter> <drosehn> Obviously you haven't seen programs I have written! :)
<RX14> so it really doesn't matter
<BlaXpirit> RX14, there are legitimate global resources, like a texture
<RX14> and if it's a serious program they will be class vars or constants
<BlaXpirit> i hope that such global resources can actually be constants instead
<BlaXpirit> they will not be class vars because even two instances of an application don't need separate copies of a texture
<RX14> if you're using global vars in anything more than single-file prototyping you're doing it wrong imo
<FromGitter> <drosehn> Though more seriously, I found that if I did have a lot of global variables, that I soon wanted to group them. "These ten global variables are for one thing, and these other ten are for something totally unrelated to that". So I'd end up moving the globals into classes just for name-space reasons.
<BlaXpirit> uh wait what nevermind what I just said
<RX14> yeah
<RX14> class vars == namespaced globals
<RX14> its that simple
<FromGitter> <drosehn> yep.
<RX14> except for a few differences which make it hard to compile
<BlaXpirit> welp, onto my next pet peeve. I don't like how it's difficult to use functions without putting them in a class
<BlaXpirit> because functions can't reference top-level variables
<BlaXpirit> it's a bit related to globals because top-level variables and globals are synonymous in Python
Oliphaunte has quit [Remote host closed the connection]
<BlaXpirit> again, it's for simple scripts, but this leaves few good alternatives
<FromGitter> <drosehn> do you mean module-level @@-variables? it's easy enough to reference them.
<BlaXpirit> no I mean a script where you write a = 5 without any indentation
<RX14> no, local vars in the top level scope
<BlaXpirit> these will feel out of place because they remain the only first-class items at the top level, if that makes any sense
<FromGitter> <drosehn> dunno. I'm not having any problems with it.
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<BlaXpirit> they can't be referenced in any inner scope
<BlaXpirit> but again this is only weird to me because I'm used to nested scopes, but Crystal has basically one scope
<BlaXpirit> that is - local to the current method
<RX14> it has lexical scopes in the method, with a class scope that can be accessed via alternate syntax
<RX14> only constant (incl. class, module) lookups really use nested scopes
<BlaXpirit> finally I understand what seems off
<RX14> i like how it works
<RX14> because it encapsulates well
<RX14> it encourages good code
<BlaXpirit> everything that you define in a function can be accessed in the nested lexical scopes
<RX14> when you're making a hacky script in crystal you can really feel it
<BlaXpirit> however if you're at the top level, not everything you define can be seen inside functions
<RX14> the top level is essentially it's own function
<BlaXpirit> top level is too special of a case. on one hand you feel like in a function but you're not because you can define functions inside it
<RX14> yeah top level is interesting...
<BlaXpirit> I just checked that you can define a function inside a function in ruby, but it seems to be pointless?
<BlaXpirit> oh they're not nested, you're still defining it at top level. well then...
<RX14> yeah ruby is weird
<BlaXpirit> if this top level is just as weird in ruby, then I suppose I should drop all my concerns
<BlaXpirit> thanks
<bjmllr> the ruby toplevel is weirder
<BlaXpirit> right
<FromGitter> <drosehn> it isn't really all that weird, once you get comfortable with the idea that everything is an object.
<BlaXpirit> drosehn, please... functions are not objects
<RX14> neither is everything an object in crystal
<BlaXpirit> i'm actually too used to a language where everything is actually an object, sometimes i can't get over functions not being them in ruby
<RX14> numbers are not *really* objects in crystal
<RX14> they look like them
<RX14> in that they have methods and you can reopen the class
<RX14> but they are not
bjz has joined #crystal-lang
bjz has quit [Client Quit]
<BlaXpirit> top level feels especially strange because a `require` can lead to code execution
<FromGitter> <cjgajard> BlaXpirit, methods ARE objects in Ruby, but to access that object you have to use `method(function_name_as_symbol)`
<RX14> you can pass around methods now?
<RX14> without making them procs?
* BlaXpirit puts 4 spaces in front of a big chunk of code and sighs
<bjmllr> `method(:puts)` will give you an instance of `Method` describing `puts` but it's not "the puts method". you'll get a different `Method` each time. you can `call` it like a proc though.
<bjmllr> in ruby
<RX14> huh
bjz has joined #crystal-lang
bjz has quit [Max SendQ exceeded]
bjz has joined #crystal-lang
bjz has quit [Ping timeout: 244 seconds]
<jhass> RX14: conceptually numbers are objects, that they have a different memory representation is just an implementation detail. Same in Ruby, Fixnum's do not allocate a whole object structure, their value is encoded into their "pointer"
<RX14> i guess
<jhass> Ruby's toplevel is less mysterious once you introduce the concept of self and the default definee being different things
<jhass> the toplevel definee in Ruby is Object, so def foo; end; and class Object; private def foo; end; end; is the same
<jhass> def changes self, but not the definee
<jhass> self on the toplevel is an instance of Object called "main"
<BlaXpirit> mm yeah... well then that just leaves Crystal's toplevel mysterious
<jhass> it is, it's full of special cases still
<FromGitter> <drosehn> wrt methods in ruby: define a method named "blah" in irb. Then do `xxx = method(:blah)`. Then see what you can do with `xxx`.
<jhass> it's just a representation of the method though, a description of it if you so will
<FromGitter> <drosehn> for instance: `xxx.class` returns `Method`. and `xxx.methods` returns an array with all the methods which are available on that `Method` object.
<jhass> to make it a first class function something like 1.upto would need to return a Method object and parens would need to be required to call it
<jhass> or bar(def foo; end) would need to pass a Method object to bar
<jhass> however some people argue that Proc's/the stabby lambda are actually first class functions
Oliphaunte has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]
onionhammer has joined #crystal-lang