<asterite_>
And also sferik talked about it as "pretty print" (and I admit the name I chose for that is wrong, but it's the first thing that came to my mind)
<jhass>
pe? print expression
<jhass>
something easy on the keyboard would be nice I guess
asterite has quit [Ping timeout: 276 seconds]
<asterite_>
Yes, that's why my initial name was pp, very easy to type :)
<jhass>
op would be nice to type, but can't come up with a mnemonic
<asterite_>
osome print?
<jhass>
mmh, ep is actually okay to type
havenwood has joined #crystal-lang
<jhass>
but backwards
<asterite_>
so many two-letter combinations :)
<jhass>
something with i (inspect)
<jhass>
?
<asterite_>
Yes, could be. Maybe pi or ip, but those are things already
<jhass>
io inspect object
<jhass>
but not true to its nature
<jhass>
and also with a meaning already :P
<asterite_>
:)
<asterite_>
ppe: pretty print expression
<asterite_>
but it's also not true, there's no pretty print
<asterite_>
Maybe pe or ep are fine
<jhass>
di debug inspect
<jhass>
doesn't work single handed though but at least LTR
daneb has joined #crystal-lang
<yopp>
pi-pi is just awesome
<jhass>
idk, or we just make pp's output pretty :P
<jhass>
"just"
<daneb>
what's pi-pi? pi-pi in south africa is urine ;)
<asterite_>
hm, maybe that's why after using pp for a while I feel like going to the bathroom...
datanoise has joined #crystal-lang
<rocketfair>
Hi. I'm curious on crystal. What's the view on syntax? Fascist rubyist or that it's just superficial out of the language stand point? (I consider syntax super important for humans, and that languages should be more agnostic to it - as long as semantics stay compatible, allowing more "lexical fronts")..
<strcmp1>
asterite_, lol @ pipi.
<strcmp1>
rocketfair, what do you mean by 'fascist ruby' ? the syntax of ruby is fascist, or you just don't like the ruby syntax?
<rocketfair>
Hi strcmp1 - eh, how do you change name here, before I continue, mine is wrong...
<strcmp1>
/nick newname
rocketfair is now known as ozra
<ozra>
Ah. Now I recognize myself in the mirror.
<strcmp1>
you're a nim user right? or maybe i saw you on the crystal repo
<ozra>
Oh, you might have seen some of my rants and PR's for Nim. ;). Yes.
<ozra>
Well, basically I find the huge amount of words that are not symbols, less then necessary.. So I was thinking about if - theoretically - an alternative parser front could be something acceptible in the future..
<ozra>
But, not very important. I'm examining different langs atm, and also interested in the community stance and philospohy of what matters in them, etc.
<jhass>
let's say it this way, most non nim users find that "fooBar and foo_bar is the same part" already beyond ridiculous ;)
<strcmp1>
jhass, why? jruby does the exact same thing, with methods.
unshadow has quit [Quit: leaving]
<asterite_>
ozra: you mean customizable syntax?
<jhass>
not saying I find it less ridiculous there, but it has some different reasoning there
<ozra>
jhass: That is actually one of the things I like about it. I've coded like that for a long time. Thin transpiler for C++ (which is where most time's been spent), where this-var -> this_var, SugarCpp does the same thing. For web I've used Livescript which does thid-var -> thisVar (for JS de-facto)
<jhass>
anyway, I prefer methods over operators and that's why I like ruby
<jhass>
a lot of "keywords" are just method calls
<strcmp1>
jhass, besides the author of nim is german, perhaps you could hang out ;)
<ozra>
asterite_: Well, I guess more of a "if an alternative syntax was dev'ed and liked by a bunch, would it be anywhere possible to be a part of the lang in the future". Sort of "One language - two ways of saying it"
<jhass>
Crystal seeks to have a Rubyesque syntax, and while it can't implement as much as methods as Ruby does, I think choosing words over symbols is what makes it retain Ruby's feel
<asterite_>
ozra: I don't think so. If you look at successful languages, they have one syntax, very few syntax customizations
<ozra>
The only thing I'd really like though is dash-identifiers (which I argued a lot for in the Nim community, where it really made sense since Nim already had gone down that road. It turned out well anyway.)
<jhass>
also look at the fights in the Ruby community over which aliases of the standard library to use, inject vs reduce, map vs collect, is_a? vs kind_of? etc etc.
<jhass>
too many ways to do things just increases tension in the community
<ozra>
asterite_: Yeah, they usually go the transpile route otherwise, like my C++ front (for livescript [coffeescript like] ish syntax). Others are I guess, Vala for, what the other was called, and in CSS world (not really comparable) with sass/scss..
<asterite_>
jhass: I agree
<asterite_>
But I think Ruby's syntax is pretty good already. Unless you are talking about making it an identation based language, which won't work because of macros
<ozra>
jhass: asterite_: Yeah that is the arguments I hear most often. It's too bad. I feel the split between languages are far worse than different teams / coders choosing their style, and staying in the same "module-sphere"
<ozra>
asterite_: Yeah, the 'end' markers burned in my eyes at first, but I simply changed the highlighter to class them differently and make them more subtle. The syntax is pretty clean, no doubt. And even though I've coded indentation based only a long time, there are definitely pros to explicit blocks, mostly for longer runs imo though.
<asterite_>
ozra: well, the parser is the most simple stuff in the compiler, so it should be replacable. But then you also need to replace the part where AST nodes get transformed back to syntax, macros use them. It should be doable, but I don't think we'll add explicit support for that (at least in the near future)
<ozra>
asterite_: I was thinking the same, it's pretty isolated. Well, I'm happy to hear it's not dismissed of the bat as an atrocity. I prefer a scientific approach - and I believe the syntactical differences in taste people have isnothing compared to different languages. So when there are great languages and potentially better syntaxes (for those preferring it - of course!) it's nice when it can be seen out of "the greater benefit for
<yopp>
anyone familiar with kalman filters?
<ozra>
Even if it's distant at the time - and might be proven wrong :)
<ozra>
yopp: Some..
<yopp>
I have cheap ultrasonic sensor that measures water level in my well
<ozra>
yopp: A a "neat" signal suitable for filtering :)
<yopp>
and it's a bit noisy, I'm trying to filter out the noise, but filter is very slowly adapts to the changes :(
<yopp>
so I can't see consumption from the filtered data
<ozra>
yopp: How fast does it change really? Isn't a rolling MA enough?
<yopp>
pupm can do 80/l min
<yopp>
and inflow is about 200-800 liters per day
<yopp>
problem is, that sometimes it catches echoes from the well walls
<yopp>
and MA is still noisy
<ozra>
Hmmm. Well you have both sink and some source. So measuring the depth will never give you the consumption?
<ozra>
Or is it more of "not overconsuming" that's of importance?
<yopp>
Source is more-like constant, it's really depends on the weather, but it's much lesser than possible consumption
<ozra>
Depending on how the signal fluctuates, based on the echos, simpler outlier detection could be an option also.
<yopp>
I have about 6 cubic meters, and pump can do it in a hour or so
<yopp>
I'm thinking about removing acceleration from the model
<yopp>
And I have no idea how to measure covariance of the process noise
<ozra>
Try it :) Testing out variations of algos usually beat heavy theoretical thinking, might be I'm stupid though ;-)
<ozra>
And very often, the simplest algos gives the best results..
<yopp>
Also, I'm thinking about feeding it not with raw data, but with median for a second
<yopp>
But my guts are telling me that this is a bad idea
<ozra>
So, two filters on top.. Well, you can never go more wrong then not trying an idea!
<ozra>
I'm guessing you have the raw signal recorded for some time, to backtest the algo on?
<ozra>
Mmm, I guess we're polluting crystal-channel with quite OT now though... Sorry.
jtarchie has joined #crystal-lang
<asterite_>
Question: right now HTTP::Client.get "www.google.com" fails because there's no scheme
<asterite_>
should we implicitly add the "http" scheme in this case, or give an error saying the scheme is missing?
<asterite_>
I see in Ruby HTTPClient gives an error, but RestClient adds it
<asterite_>
(right now it gives an error too, but it's a nil assertion failed)
<asterite_>
Well, I'll at least raise a better error message for now :-)
<ozra>
asterite_: Compiling the compiler takes about 5m10s on a test machine here, where Nim takes only 18s (pardon comparison, but, well that's what I'm doing for a project ;) - is there room for improvments in that area, or is it a tight squueze?
<asterite_>
ozra: are you compiling with --release?
<yopp>
ozra, I have raspberry pi that is constantly polling arduino over serial, and writing raw values to cvs
<yopp>
and small script that pushed this stuff to the rails
<ozra>
asterite_: Yes, in both cases..
<asterite_>
Yes, release takes a huge time but we believe there's room for improvement
<asterite_>
The time is spent in the LLVM optimizations, maybe LLVM could be faster
<asterite_>
There's also the thing that we are something generating too much LLVM IR code, some extra allocas, etc.
<asterite_>
but it's not a pressing point right now, the times we want to do a release are like, once or twice a month
<ozra>
asterite_: I'll try it without - because my use case needs fast change -> execution turn over - but _not_ in release mode, so I'll compare what matters, thanks.
<asterite_>
ozra: good. When we add/change/fix things in the compiler we usually use the debug build too
<ozra>
yopp: ah, alright
<asterite_>
ozra: you also have to take into account that nim is like 10+ years old (I think), we are just 2
<asterite_>
Mm, maybe 5+, I think D is 10+
<ozra>
asterite_: Yes, 9 I believe. Well, it is really impressive given the time, no doubt! It's just I'm comparing for actual use as of the moment ;-) However I hit a stop in Nim, and debugging that part of the piler has taken me quite some time and so I figured I should expand my horizon a bit before locking in.
DeBot has quit [Quit: Crystal IRC]
DeBot has joined #crystal-lang
<asterite_>
ozra: a stop in Nim? what do you mean?
<ozra>
I like the prospect of being able to omit types for prototyping stage and hardening code when needed, it's a great concept!
<asterite_>
Ah! I thought in nim you can sometimes ommit the types
<asterite_>
even in proc declarations
<ozra>
asterite_: Regarding inheritance and generics in combo. "Just" a bug not a language design flaw, it's just been a bit hard for me to nail the problem, but might just be I ain't clever enough - but it prevents my minimum test case from working out unfortunately. So now I'm trying a bit in Crystal, to get a wider picture.
<ozra>
asterite_: Ah, yeah, it has local inference, that's not a biggie for me, I'm used to C++ hell.
<ozra>
asterite_: in proc decls they implicitly become generics / type vars - but that is deprecated since a while.
<asterite_>
Oh! It's a bug in nim, I thought it was in crystal
<ozra>
asterite_: Ah, sorry if I was unclear. That was the show stopper...
<asterite_>
Because I'm not sure generic inheritance is working well here neither (but no bugs reported so far)... I was actually against generics inheritance
<asterite_>
can't you workaround it?
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<ozra>
asterite_: Aha, ok. Well I'll try a case. Maybe, I guess I am kind of re-implementing the C++ derived solution when trying the new langs, so ofc. I should approach it with fresh angles. But I'll begin there.. One only has so much time, and so much to evaluate :-/
<jhass>
asterite_: mh, re TMP_DIR, one thing that bugs me though is that the data is useful across invocations, while /tmp/ stuff is usually useful for the lifetime of a process. yet TMP_DIR suggest that it should at least default to /tmp/something, at least to me
unshadow has joined #crystal-lang
<asterite_>
I see... well, I'll check with waj, if he thinks CRYSTAL_OUPUT_DIR is ok we'll go with that
<jhass>
mh, how about cache?
<jhass>
CRYSTAL_CACHE_DIR
<asterite_>
Yes! Cache is the right name :-)
<ozra>
Let's see if I got this right - type vars must be only one capital letter?
<asterite_>
ozra: yes
<asterite_>
at least for now, maybe if we later add syntax for free varaibles that might change
<jhass>
asterite_: alright, updated
<jhass>
oh, forgot to update .travis.yml
<ozra>
shouldn't something like this work (signature excerpt only)? ```class Dt(A, B) < Bt(A); def intialize(a: Bt(A), b: Bt(B)); ...``` (with semis being newlines)
unshadow has quit [Quit: leaving]
bcardiff has joined #crystal-lang
asterite_ has quit [Ping timeout: 246 seconds]
unshadow has joined #crystal-lang
xd1le has joined #crystal-lang
<xd1le>
ysbaddaden: what is the limit? out of curiousity
<xd1le>
oh does he come on irc?
<jhass>
seldom
<xd1le>
oh thanks. only reason i came was to ask that question lol.
<xd1le>
gotta run
<jhass>
gotta brush up your idling skills then :P
<xd1le>
(i'm in the middle of configuring my irc client + being busy)
<xd1le>
as in
<xd1le>
i'm trying out switching to emacs
<jhass>
ah, emacs, the fifth major OS
<xd1le>
yeah until then i have a very basic weechat config which i'd rather just not use. unfortunately.
<xd1le>
okay bye for now.
xd1le has quit [Quit: WeeChat 1.2]
<wmoxam>
jhass: that's a high ranking!
<wmoxam>
;)
<jhass>
linux, os x/darwin, windows, other BSDs, emacs
bcardiff has quit [Quit: Leaving.]
<strcmp1>
jhass, you're a vim loser i guess?
<jhass>
worse, sublime
<jhass>
vim only adhoc stuff
Ven_ has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/vLxyC
<crystal-gh>
crystal/master a55d964 Jonne Haß: Make .crystal directory location configurable
<jhass>
idk, vim just doesn't stick enough with me, even went through vim-adventures
<strcmp1>
emacs is the answer ;)
Ven has quit [Ping timeout: 265 seconds]
<unshadow>
jhass: Sublime here too (also vim for smaller on the fly things), I now tried using Rubymine for big ruby projects
<unshadow>
jhass: a little bit outoftopic question, you got Arch right ? can you try running "openssl s_client -connect shkifut.info:443" and tell me if you too keep getting tlsv1 alert internal error:
<jhass>
yup
<unshadow>
:/
<unshadow>
Apperently ARCH's openssl is missing a few ciphers from OpenSSL (ECDHE_ECDSA)
<asterite>
but if you do it, it will be useful for a while, at least until we merge the shard project
<luislavena>
asterite: thank you, I can live with path for now or start testing shards too, not needing dependencies (for now) :)
<asterite>
luislavena: will history repeat itself and you'll bring crystal to windows?
<asterite>
just kidding, it's a huge task :-)
bcardiff has joined #crystal-lang
<luislavena>
asterite: no.
<luislavena>
asterite: except for a few things in relation to IO/Socket and FD, things should be easier. Crystal codebase is a bit simpler in that sense
<luislavena>
and MUCH cleaner than others I've seen (no names)
<luislavena>
asterite: but no longer doing OSS except for things that I need, so ¯\_(ツ)_/¯
<luislavena>
Right now I've started to work on DO (DataObjects) unified interface for SQLite3 and MySQL
havenn has joined #crystal-lang
<asterite>
Nice!
havenwood has quit [Ping timeout: 244 seconds]
<luislavena>
then building a ORM on top shouldn't be problematic
<luislavena>
(and less changes across adapters)
<asterite>
it's something we were talking with waj some days ago, we should provide some interface for db adapters
<asterite>
maybe in the form of a test suite
<jhass>
DBI?
<jhass>
never catched on in Ruby
<asterite>
It's not too late for us :-)
<jhass>
I think if you want to make people use it you'll need to do some work for them :/
<jhass>
you know, like Enumerable
<jhass>
give them free features by implementing that interface
<asterite>
what do you mean?
<asterite>
Ah! I see
<asterite>
Yes, that'll probably be the case
<jhass>
a connection pool could be a good start for example
<ozra>
That shard thing - why not use semver explicitly for crystal deps / mods - as a public recommendation (thus making version matching much more predictable)?
<jhass>
ozra: uh, best open an issue about that over there ;)
<jhass>
or get ysbaddaden to join :P
<luislavena>
jhass: unified mappings did catch with *some* ruby folks, not all. I guess the problem was existing unique adapters had already been used.
<jhass>
mmh, maybe
<ozra>
jhass: I'll keep it in mind - I'm gonna focus on trying to get my minimal test working, then I have a bug in Nim to jump onto, then I might jump back here, haha. Time flies..
asterite has quit [Quit: Page closed]
<luislavena>
jhass: connection pool is the first thing in my list of things :-)
<unshadow>
jhass: does the bot notify for opened issues ?
<ozra>
unshadow: yeah, worked right away. On to the next step. :)
<jhass>
unshadow: nope
<ozra>
jhass: super ooputunity to make the compiler a tutor by adding levenshtein error hinting there :)
<ozra>
See.. again, ooput... ;-)
<jhass>
heh
<jhass>
>> foo = 1; fo
<DeBot>
jhass: Error in line 4: undefined local variable or method 'fo' (did you mean 'foo'?) - http://carc.in/#/r/4x3
<unshadow>
Is this a bug ? http://carc.in/#/r/4x9 Program terminated abnormally with error code: 256
<ozra>
jhass: Ohoo - just not for methods?
<jhass>
IMO it is but asterite said there's no other way or something
<jhass>
>> def foo; end; fo
<DeBot>
jhass: Error in line 4: undefined local variable or method 'fo' (did you mean 'foo'?) - http://carc.in/#/r/4xb
<ozra>
Or just not for missing initialize -> new magic?
<jhass>
ozra: problem is that initialize does exist, you inherit a default one
<ozra>
jhass: ah - right. a little ambigiour trickier situation (nice english there, hehe)
<jhass>
>> class Foo; end; Foo.new.initialize
<DeBot>
jhass: Error in line 4: undefined method 'initialize' for Foo - http://carc.in/#/r/4xe
<jhass>
eh
<jhass>
well it's private I guess
<jhass>
>> class Foo; def foo; self.initialize; end; end; Foo.new.foo
<DeBot>
jhass: in line 4: undefined method 'initialize' for Foo - http://carc.in/#/r/4xf
<jhass>
heh
<jhass>
or maybe my Ruby expectations go wrong there
<zodiak>
hey, asked this last night but I guess no one is on PST time here ;) is there any docs/guides/howto around threads/actors/fibers/promises or the such ?
<ozra>
How did I go wrong with the next step: http://carc.in/#/r/4xg - should the operator be a method?
<ozra>
jhass: I should have tried first :) Managed by "re-opening" the class, to test how the actual use case would work. Hmmm, this is starting to make me carefully happy :)
<jhass>
ozra: oh btw stylewise we leave off empty parens ;)
<zodiak>
unshadow danke danke
<ozra>
jhass: Will one get shot? Looks more consistent to me ;-)
<jhass>
only if collaborating :P
<jhass>
I'm in the camp of leaving them off where possible, so I have no consistency issues either way :P
<ozra>
Ooh, juxtaposition calls are allowed too. Any percurliarities to think about for those?
<ozra>
jhass: Yes, I always crawl to the proj rules when collabing, that is all a-ok :)
<jhass>
forgive my lack in compiler theory, what's that?
<asterite>
But... I think I'd like to remove the ability to inherit generic types :(
<jhass>
maybe, we've been finding quite a few bugs since we get random input from carc.in, human driven fuzzer so to say :P
<ozra>
asterite: Why?
<asterite>
because you can do just fine without that
<ozra>
Hmm - well, I admit I haven't thought much further about the implementation - but for the thing I have in mind the minimum case I tested now seems like the obvious solution to me.
<asterite>
Oh, when I said "you" I meant a generic "you" :-)
<asterite>
For example Go has no generics and people are doing pretty cool stuff without them
<asterite>
(not that I like that, though)
<asterite>
Generics are fine, inheriting them... not sure
<ozra>
asterite: Oh, yes I got the generic you, haha. But .. well there are reasons I'm not using Go ;-)
<ozra>
asterite: I actually think it's a perfectly valid use case.
<jhass>
isn't include Enumerable(T) inheritance though?
<ozra>
Are they causing much greater complexity, or?
<asterite>
Well, but it's a module
<asterite>
I guess it's just that it makes things a lot more complex and I'm lazy to fix bugs :-P
<ozra>
asterite: Well, can understand that, but I find it to be a good feature. But, working on trying to fix it in Nim, I can say I do find it complex indeed. But I don't know what the crystal source looks like yet..
<ozra>
But I reeeally hope you will want to keep it :)
<BlaXpirit>
asterite, please reconsider.
<BlaXpirit>
if you think about it, generics in crystal are LESS flexible than normal classes
<asterite>
Don't worry, I'm already working on the bug ;-)
<BlaXpirit>
it's just a way to make types correspond to each other
<ozra>
Hey asterite: Since I'm out of arguments other than that it rules: I just went outside (Mimmi was yelling "come and look outside!") and there were these _super intense_ double rainbows (haven't seen the likes of before!) I take it as a sign of Crystal projecting a spectral display of "hooray for generic inheritance!" B-)
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jhass>
wat
<jhass>
oh, reminds me I should watch the wat talk again
<ozra>
Well, my minimal case of the project working after minutes in crystal, taken over a week of bug fixing in Nim and still not working. This is starting to look interesting :)
DeBot has quit [Remote host closed the connection]
<BlaXpirit>
i've watched it so many times
<ozra>
Can anyone give a quick hint on what purpose blocks serve that a lambda function wouldn't (which would be inlined anyway, and not introduce new parameter syntax for no reason.. )?
<asterite>
ozra: break, next, return
<asterite>
specially return
<ozra>
Aha, it is "templated in"
<ozra>
?
<ozra>
so to speak
<ozra>
thanks
<asterite>
Kind of. If you return from a lambda you return from the lambda. If you return from a (non-captured) block you return from the method containing the block
<asterite>
I think that's the main (huge) difference between blocks and lambdas
<ozra>
good use then :)
<asterite>
Well, I'll submit a bug for the generics thing, it isn't trivial to implement, I'll leave it for another day :-)
asterite has quit [Quit: Page closed]
<jhass>
ozra: blocks also differ in their parameter validation semantics http://carc.in/#/r/4y9
<ozra>
jhass: Ok. I'll have to read up on that then. I'll jump into investigating macros first :)
<jhass>
mmh, so it's just my testcase being the compiler that's being flawed? :D
<waj>
yup, llvm is required to *compile* crystal, not to run it :)
<jhass>
hah, I never realized
<jhass>
derp
<jhass>
well, shame on me, I have no crystal project with specs :D
<jhass>
willl: guess you need to sign up to staging too :P
<willl>
alright, working on that
<willl>
waj: after this makes it in, it'd be cool if the crystal travis build put the last working version up somewhere so other projects could test against crystal-head
<waj>
willl: that would be cool
<ozra>
yopp: The good ole` KISS principle :)
<yopp>
you don't tell
<yopp>
it's beat me in my arse
<yopp>
•in me
<jhass>
willl: uhm, sudo: false into your .travis.yml -> much faster builds ;)
<ozra>
Anyone know the reason why generic type vars are limited to one char?
<jhass>
willl: oh and it's failing because you need a createdb travis first, or maybe that's the part being broken on staging
<jhass>
ozra: basically a workaround so you don't declare one by accident
<jhass>
>> def foo(bar : T); puts "since this works #{T}"; end; foo(1)
<jhass>
so now imagine you meant that as a type restriction with MyCalss
<jhass>
(typo on purpose)
<willl>
jhass: yeah just caught that, thanks
<ozra>
Ok, I'm completely fresh testing Crystal, so I didn't get that fully: Can you make a func deffed with a typevar without any additional notation other than it being a single capital?? Perhaps then a number should also be allowed after at least. SomeCls(T1, T2) feels natural, and you'd never name a type like so..
<jhass>
sounds like a sane idea, feel free to open a github issue ;)
<jhass>
>> def foo(bar : T1); puts "since this works #{T1}"; end; foo(1)
<asterite>
ozra: the 1 letter restriction is because of this
<asterite>
Array.new(10, "a") # OK, Array(String)
kulelu88 has quit [Client Quit]
<asterite>
Array(Int32).new(10, "a") # Error
<asterite>
That's because that `initailize` has a T restriction, the same letter as the type of the array
<asterite>
if you don't say the T, it is inferred
<asterite>
if you say it, it is matched against that
<asterite>
Previously that worked for all identifiers (T, Foo, Bar) but that was bug prone, and since generics usually use single letters we though it was reasonable
<asterite>
Another way would be to have a special syntax to mean "this Foo is an identifier that I want to be inferred or matched if defined"
<asterite>
but we don't want to add more syntax for now, and this "workaround" is ok for now and doesn't introduce syntax that we' later might regret (so it's limiting stuff so we could maybe expand it later in a different way)
<jhass>
I think allowing 0-9 as second char is a sane thing to do though
<asterite>
me too
<ozra>
asterite: Yeah, I actually like the Crystal philosophy of adding connotations to how identifiers are named, avoiding cumbersome additional syntax, I do however still think a number after the capital letter would be great, I added an issue mentioning it in any event.
<ozra>
cool.
<asterite>
In fact I had a zip iterator using I1 and I2 and had to change it... and that was before we had that limitation
<ozra>
And a single digit would definitely suffice, limiting ambiguity, I can't see anyone having "T13", that would be a crazy amount of T's :).
<ozra>
Ah, ok.
vikaton has joined #crystal-lang
<crystal-gh>
[crystal] will opened pull request #848: Add link to API docs (gh-pages...gh-pages) http://git.io/vte8p