<crystal-gh>
[crystal] PragTob opened pull request #931: Raise in Enumerable#take if a negative count is used (master...no-take-with-negative-count) http://git.io/vqthm
<jhass>
might be a bug, hard to judge without an (reduced) example
<ozra>
Yeah, I'm starting to think so too.. I'll see if I can get together a minimal example
<ozra>
Ha, no, I think I've simply missed one implementation! :) Fingers crossed
<ozra>
Boo hoo, sob, no, there seems to be some bugs :-/
<ozra>
Getting closer. Is there no way to constrain type variables / free variables?
<jhass>
don't think so, no
<ozra>
Ok, I'll make a wish-issue
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/vqqQm
<crystal-gh>
crystal/master 6653c97 Ary Borenszweig: Fixed #935: crash when overloading with generic type against fixed (primitive) type
<crystal-gh>
crystal/master 92bfad8 Ary Borenszweig: Fixed #933: crash when invoking super() on inherited generic class when the superclass doesn't have an initialize
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/vqq7g
<travis-ci>
manastech/crystal#92bfad8 (master - Fixed #933: crash when invoking super() on inherited generic class when the superclass doesn't have an initialize): The build passed. https://travis-ci.org/manastech/crystal/builds/69544066
<travis-ci>
manastech/crystal#aed5328 (master - Merge pull request #925 from yui-knk/feature/set_superset
<travis-ci>
manastech/crystal#b273a9d (master - Merge pull request #929 from yui-knk/test/enumerable_any
<ozra>
Can't methods be overloaded depending on block parameters?
<travis-ci>
manastech/crystal#286f735 (master - Merge pull request #930 from PragTob/enumerable-drop-while
<crystal-gh>
[crystal] asterite pushed 3 new commits to master: http://git.io/vqqNQ
<crystal-gh>
crystal/master 1bd7828 yui-knk: Alias `Set#size` `Set#length`
<travis-ci>
manastech/crystal#2514729 (master - Merge pull request #936 from yui-knk/feature/set_size
havenwood has quit [Ping timeout: 255 seconds]
<ozra>
I'll repose and rephrase a question if anyone knows, or the reason why: Can methods be overloaded depending on passed block parameters? Ie explicit acceptance of block parameter signature?
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<ozra>
I mean, based on the parameters of the block, like with a lambda function. If it takes two arguments, use one meth, if it takes one arg of int, use another, etc.
<ozra>
That is, how do you declare the type of the block for the receiving method...
<willl>
oh sorry. I'm not sure how that would work, since if you're a method taking a block, that method is what is sending the argument types
<willl>
it would be like picking a method based on what you want the return value to be, rather than the arguments. which maybe could be a cool feature, but I dont think is in there now
<ozra>
Yes, but it is receiving a receiver it will invoke, and that must be able to be typed? Otherwise static typing is thrown out the window?
<ozra>
More like a callback imo
asterite has joined #crystal-lang
<ozra>
All in all, blocks seems like a really bad design decision. Half of what is accomplished could go into templates/macros, the other (greater half) would be better of as lambdas / first class anon functions. I'd like to be proven wrong.
<asterite>
ozra: that idea has come up a few times, but for example you can do `5.times { ... }` and `5.times { |i| ... }`, so you can choose to use block args or not. Not sure how that would work if we introduce overloading based on block args
<asterite>
Also, for that to work you would need to say `&block : Int32 -> String` and `&block : String -> Int32` (for example), but then what, you have to try to type the block with different block argument types and see what happens? I don't know how that would work
<ozra>
I was thinking about my "I want for". I came to realize, I'm _not_ missing for. I feel uncomfortable with that `list.each do |v|`, list.each_with_index do |v, i|` even has to have different names (they don't in other langs where I've used each, and they're overloaded. All in all, I think blocks would be better of replaced with other constructs?
<ozra>
asterite: Ok, mmm, I'm not quite following on that. For the `5.times` scenario.
<asterite>
Well, overloading based on the number of block arguments is another thing, waj wants that for example. But for me it conflicts with existing semantic
<ozra>
no param, a times method passing no arg is matched. One param, a times method passing index is matched?
<asterite>
But then you have to define the times method twice, or add syntax for saying "one argument, optionally specified"
<jhass>
the point is that currently you get both for free and in 95% you want the same logic for both
<asterite>
Every little addition increases the complexity of the language exponentially, because it has to interact well with every other existing feature
<ozra>
asterite: I think a lot of the basic syntax of ruby is great (there are scientific proofs [small study] supporting Ruby and Python as top contenders in that regard), but the block construction is a disaster.
<ozra>
I was thinking more of a subtraction in this case ;-)
<ozra>
asterite: What's so bad about defining two times methods? Or two each methods instead of one each and on each_with_index?
<asterite>
How would you do Enumerable#map without blocks?
<ozra>
With lambda func. It would be inlined (sasumed)
<ozra>
_assumed_...
<asterite>
Well, two things here
<asterite>
You can think of blocks as lambda funcs speciailized for the case of a method receiving a single func
<asterite>
and their syntax is easier to read/write
<ozra>
depending on lambda syntax, but for current, yes
<asterite>
And then, you have the guarantee that non-captured blocks are inlined, and the way it's done is very easy for the compiler to detect, and there's no need to create closures and analyze them later
<ozra>
I guess, in the spirit of "one way to do it", I simply feel, there are no gains for blocks...
<asterite>
One more thing, that's always *the* reason for blocks
<asterite>
if you return from a block, you return from the enclosing method
<asterite>
with a function, you would return from the function
<ozra>
(I like variation as you may now, though, but not when the "weird" thing is the prominent ;-)
<asterite>
Imagine I do File.open(...) { if some_condition; return "BAD"; end }
<ozra>
Yes, and that is a rather dangerous construct, and should then be left to be done with template and macros _if_ you want to do it, imo.
<asterite>
That looks like the block is just regular syntax, no special scope, no lambda. And the return looks like a regular return, exists from the methods
<asterite>
This is the true power of blocks
<ozra>
I'm listening, so you know, I like to keep an open mind, so all my arguments are from current experience and knowledge, just like to say that.
<asterite>
We also have a language with strong inspiration on Ruby, and I think not having blocks is not having Ruby
<asterite>
Sorry, gotta go now. I also talk from experience, but of course everyone's experience is different :-)
<ozra>
I guess arguing for 'affecting external scopes state should go in macros/templates, rest in lambdas' is moot, but. Just one thing:
asterite has quit [Quit: Page closed]
<ozra>
The overloading or possibility of typing blocks/ acceptance of blocks?
<ozra>
Ah, bummer.
<ozra>
jhass: Given that blocks are a stay (I accept that, I make arguments to understand the reasoning), what do you feel about the possibility of overloading a method depending on the arg count of the block, like waj also seem to like?
<jhass>
well, currently arity isn't enforced
<jhass>
I think it would change a core semantic of the language
<jhass>
perhaps you should design your own new language with all the experiences you gathered
<ozra>
jhass: Yeah, exactly, I find that to clash with the static type checking and OOPness of the language, maybe it's just me.
<jhass>
I think Crystal is at a point where changing such core semantics is not feasible anymore
<ozra>
jhass: Haha, yes, but I live in reality, and in that I don't have time for such an endaveur ;-) I love Crystal, I just try to input, and if something good comes out of it - great, if not, that's ok too.
<jhass>
and most core semantics are in place intentionally
<jhass>
well, Crystal started as "such an endaveur" ;)
<jhass>
ozra: though tbh I think you'd help more with attacking the issues present in the current semantics, instead of radically changing the base design
<ozra>
jhass: Yeah, well you know, family, dogs, cats, garden, putting food on the table.. The usual routine would make it hard for me :-/
<jhass>
trying to find solutions that fit well into the existing semantics
<ozra>
jhass: Yeah, my perspective with those arguments are mostly to raise the question a bit higher, which may sometimes help with the small changes :)
<jhass>
I'm not sure I agree
<jhass>
I see it clog draw away focus too, since you usually continue to argue the radical change
<jhass>
s/clog//
<ozra>
jhass: I do think the ability to match block params would go well with, leaving it out and thus allowing 'free block matching'. So feasible.
<ozra>
jhass: Sorry about that, I'll simply refrain from that from now on. You have my word.
<ozra>
Not everyone likes hypothetical debates to reach a small, sometimes moot, conclusion, haha.
<jhass>
sorry if that sounded a bit harsh, I just have a feeling that you might spend a bit more time in arguing those than may be justified, in regards to prospects of getting the change in ;)
<ozra>
jhass: Ah, no problem. Yeah, that was kind of what I meant: can sometimes argue, knowing it won't get in, but to build up a picture and get responses to questions that perspective poses, which lets me understand the reasoning better. If I understand it better I can use it better. But there are much better ways of achieving that. Just simply asking :-)
<jhass>
and to reiterate, I think most of your suggestions do make a lot of sense, which also makes it hard to argue against them, I just think they'd fit better at designing a language from the ground up
<ozra>
jhass: Yeah, I definitely think you're right. If I had the funding so I didn't have to think about money, I'd definitely get on it. I like the scientific approach. And I'd probably get a lot of inspiration from Crystal :)
<jhass>
we're kinda just past the point, Crystal started with the goal of compiling Ruby, so staying close to Ruby is one of its core ideals and a large factor in its appeal. Even if that means repeating some of Rubys shortcomings for the sake of familiarity
<jhass>
it's often more like "what do we need to change in Ruby in order to work well with static typing" than "what would be the ideal approach"
<ozra>
jhass: Yeah, I mean, of the langs right now, this fits my bill the best, so I have nothing to complain about at large. But I will come with some more ideas, just ones that fit in better, and less arguing ;-)
<jhass>
cool, glad you take it that way :)
<ozra>
jhass: So this is with regards to what you just mentioned, typing. I'll tinker, if I can come up with a compatible and good way of doing the block-param matching, that makes it better while still being compatible. If I do, I'll post an issue.
<ozra>
jhass: I welcome your openess about how you perceive my rants :-)
<thor77>
why does crystal 0.7.4-1 require gc-static (aur)?
<jhass>
ozra: mmh, what if we could make type interference work for lambda definitions that are defined directly in method calls?
<ozra>
Yeah. I'll let my sub concious tinker a bit while I code now.. If I think of something (more "block near"), I'd like to check with you, since I know you're rooted in Ruby know how.
<ozra>
Had to reformat a bit :) And what about the other way around, making the foo method alternate depending on the block params (that's what I'm after...)?
<jhass>
well, not using the block param at all should work already
<ozra>
Ah, I mean, a block with {|a,b|} and {|a|} passed to 'foo' can match different foo's...
<jhass>
yes, that's your initial proposal, I know you want that, and we say it would conflict with not enforcing the arity ;)
<ozra>
ok, looking at your example...
<jhass>
my compromise would be ^ but without having to specify the restrictions in the proc definition if the proc is defined directly in a method call
<jhass>
then the compiler could match up the available overloads based on arity and do type interference for the proc arguments from the matching overload
<ozra>
jhass: However for terseness, seeing that we do have blocks, something flagging that arity match is wanted perhaps? Or that it's done _if_ more methods are defined, and their parameters match, then compare arity of yields as final decision maker. That would be completely transparent, and the expected behviour imo.
<ozra>
So if only 'foo()' exists, it takes any arity block. if 'foo(); yield 1,2; end;' and 'foo(); yield 1; end;' they are disambiguated by block arity matching? (but then - what to do with three params in block... match 2-param yield method?)
<jhass>
mmmh, I have to think more about that
<jhass>
I think meanwhile what I showed with overload matching based on a proc argument is a good workaround
<ozra>
cool, some ideas in the air :)
<jhass>
there's also the thing that I feel like it's extremely uncommon to actually have differing logic based on arity
<jhass>
so it's a lot of work in the compiler for a potentially rather small gain
<jhass>
maybe something to defer for when the more pressing issues are out of the way :P
<jhass>
like that we have abstract classes bothers me a lot more :P
<ozra>
jhass: Haha, well.. Abstract classes are ok with me :)
<jhass>
well, to me they're entirely redundant to modules
<jhass>
modules basically are a superset of their usecases
<ozra>
jhass: Well, they are more of mixins, while abstract classes are useful base-type-unifications..
<ozra>
So when all is needed is a common base-class for a bunch of complex variations of classes, simply making the root an abstract class is very clear, what the intention is, imo...
<jhass>
perhaps it's a bit easier, but I mean it kinda boils down to looking at the inheritance chain only vs looking sideways into the mixins that all objects may share
<ozra>
jhass: Yes but for method dispatching and signatures, the common root is necessary, and for the type inference to be able to reduce it to a common ground without making a zillion unions...
<ozra>
So, well, I think they both have an important place.
<jhass>
http://paste.mrzyx.de/ps8adjsoe so yeah, making that interference there is easier and that's the reason Ary gave me for introducing them, but semantically they're redundant IMO
<jhass>
note that abstract def foo works in modules too
<ozra>
O do also think the intention of the programmer is clearer, which is very important. 'class' have ties, 'module' feels very distant in that respect..
<ozra>
Ah, interesting example
<jhass>
maybe it's just me being poisoned by ruby where Class.superclass #=> Module ;)
zz_Cidan is now known as Cidan
<ozra>
jhass: Aha. Yeah! You're poisoned for sure! ;-)
<ozra>
I wrote `: Void` after a method, and it seems to work, but I don't see it in docs. What is the idiomatic Crystallic way of making a method non returning?
Cidan is now known as zz_Cidan
<BlaXpirit>
ozra, what is "non returning"
<ozra>
what would be `void foo();` in C/C++..
<BlaXpirit>
first of all, you just don't specify the return type. it's not an important detail, so maybe that's why it was left out of docs
<BlaXpirit>
void may be the way
<ozra>
Ah, because otherwise I'll get random return types depending on the last statement in different overloads I figured...
<BlaXpirit>
if i remember correctly, there is also a thing like NoReturn which means the method literally never ends executing. just do you don't run into this and get confused
<BlaXpirit>
ozra, returning nil is also good
<ozra>
Right, that's for exit() and the like..
<ozra>
Ok, would that be mean no data passing, or would it actually pass a nil value? It's a bunch of small methods here called in a large chain, and they all work only on internal object state..
<BlaXpirit>
actually, ozra, I don't think void works at all
<ozra>
No?
<BlaXpirit>
when you say it seems to work, can u show an example?
<BlaXpirit>
appears that methods can't return nothing
<BlaXpirit>
they can return nil
<BlaXpirit>
like in ruby
<ozra>
Aha, yeah, I tried all sorts of combos. 'def foo(): Void' must return void. But 'return' last returns nil. Hmm.. I guess Void is probably for C interaction. Ok, thanks alot BlaXpirit
<BlaXpirit>
yes
blue_deref has joined #crystal-lang
<blue_deref>
I see Hashes don't return nil when indexed with a non-existent key.
<blue_deref>
I am here to personally thank the person responsible for this.
<blue_deref>
In addition I would like to offer my time and efforts to improve this language.
<willl>
blue_deref: yeah it's a better default, but just so you know you *can* get nil out if you use #[]? http://carc.in/#/r/6f8 and the ? for optionally nil is a common pattern in crystal
<blue_deref>
well, hey, that's fine.
<blue_deref>
I just always thought Ruby was really...dangerous...with it's nils flying about everywhere
<blue_deref>
And I should be biased. It was my first language. :P
<BlaXpirit>
not using ruby keeps biting me when it comes to crystal
<BlaXpirit>
it shouldn't be so...
<blue_deref>
BlaXpirit, hello! It's Mooneye from #sfml.
<BlaXpirit>
hi
<BlaXpirit>
blue_deref, have you tried sfml with crystal>
<blue_deref>
Nope. Better believe I'm gonna.
<ozra>
Does sfml have any rudimentary UI things, like input boxes and buttons or so?
<BlaXpirit>
no
<ozra>
alright
BlaXpirit has quit [Quit: Quit Konversation]
<blue_deref>
ozra: There's SFGUI
<blue_deref>
ozra: Not sure how easy it'd be to get it working with crystal
<ozra>
blue_deref: On that page now ;-)
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #crystal-lang
<ozra>
Anyone knows the "alias_method" good? I'd like to alias 'write' so that operator '<<' can be used too..