[00:00:38] *** mickael9` has quit IRC
[00:38:25] *** fredreichbier has quit IRC
[01:32:18] *** Oddity007 has joined #ooc-lang
[02:43:09] *** shahri has quit IRC
[03:03:50] <duckinator> anyone still lurking here?
[03:05:49] <Oddity007> meee
[03:06:03] <duckinator> Oddity007: do you know if ooc has something equivalent to this in ruby?:
[03:06:05] <duckinator> <<EOF
[03:06:09] <duckinator> blah blah blah,
[03:06:15] <duckinator> this entire section is returned as a string
[03:06:15] <duckinator> EOF
[03:06:16] <Oddity007> I don't use ruby
[03:06:29] <Oddity007> and I have no clue what you're talking about
[03:06:54] <duckinator> that^ in ruby is equivalent to "blah blah blah,\nthis entire section is returned as a string\n"
[03:07:19] <Oddity007> oh, no clue
[03:07:21] <duckinator> damnit
[03:07:27] <duckinator> it's a nice feature to have
[03:07:32] <Oddity007> I don't know if strings are multiline automatically
[03:07:54] <duckinator> hmm
[03:08:06] * duckinator tries
[03:08:45] <duckinator> :O they are!
[03:08:48] <duckinator> good catch, Oddity007 :P
[03:39:46] <duckinator> hmm
[03:43:01] <Nilium> Pretty sure ooh does not have that.
[03:43:06] <Nilium> ooc
[03:43:12] <Nilium> You blasted infernal system-wide autocorrect
[03:43:43] <Oddity007> disable autocorrect
[03:43:45] <Oddity007> always
[03:43:45] <Nilium> Also odd that it has multiline strings, since I prefer the C way of doing multiple lines: two string literals = one string literal.
[03:44:02] <Nilium> No, I decided to leave it on because Apple will inevitably make it on whether I like it or not, so better to adjust now
[03:44:07] <Oddity007> haha
[03:44:09] <Oddity007> so true
[04:04:02] <duckinator> Nilium: 99% sure the C way works too
[04:04:26] <duckinator> or...no...
[04:04:29] <duckinator> not on multiple lines:(
[04:04:42] <duckinator> ...or at all
[04:04:43] <duckinator> :(
[04:04:54] <duckinator> damn you, little puny 1% D:
[04:05:55] <duckinator> GAH WHAT THE FUCK IS THIS SHIT
[04:06:06] <duckinator> ["hi", "hi"] join("\n") println()
[04:06:09] <duckinator> THIS DOESN'T WORK?! :(
[04:06:50] <duckinator> ...
[04:07:01] <duckinator> it seems to believe ["hi", "bye"] is a String
[04:07:10] <duckinator> ./httprun.ooc:7:1 ERROR No such function join(String) for `Char`
[04:07:10] <duckinator> ['a', 'b'] join("\n") println()
[04:07:14] <duckinator> ./httprun.ooc:7:1 ERROR No such function new(String) for `ArrayListClass`
[04:07:14] <duckinator> ArrayList new(["hi", "bye"]) join("\n") println()
[04:08:00] <duckinator> ...
[04:08:04] * duckinator explodes violently
[04:08:12] <duckinator> array literals are miserably broken
[04:10:49] <duckinator> wtf
[04:11:25] <duckinator> Nilium, Oddity007: for anything useful, arrays are treated as if they were the class of the first object
[04:11:35] <duckinator> ie, [1, 2.0] is treated as a SSizeT
[04:11:43] <Oddity007> yeah :/
[04:11:49] <Oddity007> Should really be a type error
[04:11:59] <Nilium> Wait, integers are a SSizeT?
[04:11:59] <duckinator> well, actually
[04:12:15] <duckinator> Nilium: they're treated as SSizeT by default. not sure why.
[04:12:27] <Nilium> Oh well
[04:12:28] <Oddity007> r0flor
[04:12:30] <duckinator> anywho... imo [1, 2.0] should be treated as an array of floats (or w/e 2.0 is)
[04:12:31] * Nilium goes back to watching Memento
[04:13:09] <duckinator> but it seems like for everything but arr:=[......];arr[x]  arrays are just plain shit
[04:13:15] <duckinator> like
[04:13:26] <duckinator> x := [1, 2.0]; x[0] toString() println() // => 1
[04:13:37] <Nilium> Can you specify array type any other way?
[04:13:45] <duckinator> ArrayList new(["hi", "bye"]) // => ./httprun.ooc:7:1 ERROR No such function new(String) for `ArrayListClass`
[04:14:05] *** Oddity007 has quit IRC
[04:14:07] <duckinator> Nilium: not sure
[04:14:09] <duckinator> let me look
[04:14:22] <duckinator> imo what is currently "Array", should be more like CArray
[04:14:32] <duckinator> ...and maybe have a bit more functionality than a rock that's superglued to the floor
[04:14:38] <duckinator> ...unintended pun
[04:15:19] <duckinator> Nilium: arrays are disgustingly poorly implemented imo
[04:15:47] <duckinator> https://github.com/nddrylliog/rock/blob/master/sdk/lang/Array.h
[04:17:09] <duckinator> wtf...this is horrible
[04:17:33] <duckinator> arrays in ooc make me want to vomit. not even joking :\
[04:20:57] <locks> fix it :x
[04:21:16] <locks> is there an Homebrew formula?
[04:21:29] <duckinator> hm?
[04:21:45] <duckinator> Homebrew is that OSX thingy? if so, no
[04:24:02] <duckinator> locks: `curl http://dag.d/get-rock | bash` will install rock in ./rock
[04:24:07] <duckinator> s/curl/wget -O-/ if you wish
[04:24:10] <Nilium> Just download the latest version, replace libatomic_ops with the latest snapshot of libatomic_ops, and then run 'make bootstrap'
[04:24:12] <duckinator> er
[04:24:17] <Nilium> If you're on 10.6, you might not have to replace libatomic_ops
[04:24:20] <duckinator> locks: `curl http://da.gd/get-rock | bash` will install rock in ./rock *
[04:24:25] <duckinator> or wait, OSX, do what Nilium said
[04:24:32] * duckinator forgot it's not been fixed yet
[04:24:36] <duckinator> i really should fix that
[04:24:40] <duckinator> brb, i'll try
[05:23:28] *** curtism has quit IRC
[06:34:13] *** joshthecoder has quit IRC
[07:00:25] *** joshthecoder has joined #ooc-lang
[07:00:25] *** ChanServ sets mode: +v joshthecoder
[07:24:33] *** locks has quit IRC
[08:47:37] *** shamanas has joined #ooc-lang
[08:47:52] <shamanas> hello
[08:48:03] <shamanas> why is ooc-lang.org redirecting me to ndd's blog today? :/
[08:48:48] <duckinator> it works here :<
[08:48:53] <duckinator> i think the internets are broken
[08:49:16] <duckinator> someone else just told me duckinator.net is down but i can't find anyone else who can't access it (yet it fails for them if they try their VPS, which is in a different *country* than they are)
[08:49:37] <duckinator> is duckinator.net up for you? :P
[08:50:42] <shamanas> duckinator.net works fine
[08:51:11] <shamanas> but srlsy ooc-lang gets you to the ooc website? :P
[08:51:14] <duckinator> yea
[08:51:27] <shamanas> now it does too
[08:51:30] <shamanas> suspicious :P
[08:51:32] <duckinator> the one that annoys me because the header's nearly as large as the content :(
[08:51:43] <shamanas> xD
[08:52:27] <shamanas> btw there is no ArrayList<T> new(T[])
[08:52:36] <shamanas> its T[] as ArrayList<T>  :D
[08:53:29] <duckinator> hm?
[08:53:46] <duckinator> the array stuff i mentioned?
[08:53:53] <shamanas> was reading logs y
[08:54:23] <duckinator> it was ArrayList new([1, 2.0])
[08:54:34] <duckinator> which is passing an Array
[08:54:46] <duckinator> considering Array is useless, i was hoping that would work
[08:54:59] <shamanas> i think there is no constructor for ArrayList using an Array
[08:55:04] <duckinator> but my point was more that it treats [1, 2.0] as a SSizeT when I pass it to ArrayList new()
[08:55:11] <shamanas> but there is an as operator defined
[08:55:14] <duckinator> ArrayList new(["hi", "bye"]) // => ./httprun.ooc:7:1 ERROR No such function new(String) for `ArrayListClass`
[08:55:17] <shamanas> y I know
[08:55:23] <duckinator> it...yea...
[08:55:23] <shamanas> error reporting is broken
[08:55:35] <duckinator> Arrays are utterly useless :(
[08:56:04] <shamanas> hm well
[08:56:05] <shamanas> y
[08:56:07] <shamanas> :P
[08:56:21] <shamanas> I guess you could use them to define an ArrayList? Like
[08:56:29] <shamanas> [1, 2, 3, 4] as ArrayList<Int>
[08:56:35] <duckinator> hmm
[08:56:43] <shamanas> but ranges are better than that
[08:56:51] <shamanas> (for ints :P)
[08:57:04] <duckinator> that does work, yes
[08:57:11] <duckinator> but imo an Array on it's own should be able to do SOMETHING
[08:57:15] <shamanas> Also, this could be done with a typed varArg ArrayList constructor
[08:57:23] <shamanas> if we had typed varArgs
[08:57:35] <duckinator> it's 3am, don't talk about varargs ;P
[08:57:45] *** locks has joined #ooc-lang
[08:57:45] <shamanas> xD
[08:57:54] <shamanas> its 10 in the morning here :D
[08:58:43] <shamanas> ok brb ... and when im back, ill try to fix #311
[08:58:48] *** shamanas has quit IRC
[09:04:11] *** shamanas has joined #ooc-lang
[09:04:47] <shamanas> btw what happened to alpaca and old website? Asked sometimes, no-one told me D:
[09:10:04] <duckinator> iirc it was managed by pheuter, who i've not seen on irc in ages :(
[09:10:31] <duckinator> so if that's the case, it probably disappeared and he wasn't around to fix it, which sucks because it was pretty nice
[09:11:20] <shamanas> y ;(
[09:19:53] <shamanas> oh noes
[09:20:12] <shamanas> gota mess with the AST to fix #311
[09:21:57] <duckinator> D:
[09:23:08] <shamanas> the variableDecl for the comboRoot is defined directly in the AST, within  onFunctionCallCombo...
[09:23:28] <duckinator> ah...that doesn't sound fun .-.
[09:23:56] <shamanas> not at all
[09:24:03] <duckinator> anywho... since it's 3:20am and it seems I keep coming off as rude/cocky and upsetting the person I happen to be employed by, I'll just take that as a hint to go to bed ^^
[09:24:16] <duckinator> 'night o/
[09:24:16] <shamanas> :D
[09:24:20] <shamanas> night :D
[09:53:14] <shamanas> haha
[09:53:23] <shamanas> www.ooc-lang.org redirects to ndd's blog
[09:53:31] <shamanas> but without the www its ok
[10:06:39] *** shamanas has quit IRC
[10:20:07] *** shamanas has joined #ooc-lang
[11:09:52] *** shamanas has quit IRC
[11:21:30] *** Oleiade has quit IRC
[11:25:04] *** Oleiade has joined #ooc-lang
[12:55:48] *** Jetbeard has joined #ooc-lang
[13:36:48] <CIA-126> rock: Alexandros Naskos master * rea3e2e1 / source/rock/middle/FunctionDecl.ooc : Closes #321 - http://git.io/recRAw
[13:36:49] <CIA-126> rock: Amos Wenger master * r0982848 / source/rock/middle/FunctionDecl.ooc :
[13:36:49] <CIA-126> rock: Merge pull request #323 from shamanas/mangleArrayList
[13:36:49] <CIA-126> rock: Closes #321 - http://git.io/cea69g
[15:05:01] *** fredreichbier has joined #ooc-lang
[15:05:01] *** ChanServ sets mode: +v fredreichbier
[15:15:35] *** fredreichbier has quit IRC
[16:54:46] *** Nilium has quit IRC
[17:00:47] *** mickael9 has joined #ooc-lang
[18:03:23] *** void_star has joined #ooc-lang
[18:10:26] *** aanderse has quit IRC
[18:11:01] *** Jetbeard has quit IRC
[18:19:52] *** MayDaniel has joined #ooc-lang
[18:28:09] *** void_star has quit IRC
[18:30:44] *** MayDaniel has quit IRC
[18:43:17] *** shahri has joined #ooc-lang
[18:45:04] *** Nilium has joined #ooc-lang
[18:45:05] *** ChanServ sets mode: +v Nilium
[19:43:11] *** shamanas has joined #ooc-lang
[19:43:29] <shamanas> hello world :D
[20:08:58] <duckinator> ohai shamanas
[20:09:33] <shamanas> duckinator: tomorrow ill finish the #311 fix (oh so close!) and work on fixing array error reporting
[20:09:39] <duckinator> \o/
[20:09:52] <shamanas> duckinator: then maybe the "most derived type"
[20:10:35] <duckinator> the most derived type, assuming rock's not changed a whole lot in that specific portion, has at least part of the fix mentioned in #10
[20:10:57] <shamanas> yes i saw it :)
[20:11:11] <shamanas> should be easy if the only thing to do is what ndd says
[20:11:38] <duckinator> yea
[20:11:58] <shamanas> i guess ill have to test every type against the next one and the opposite
[20:14:11] <shamanas> hmm
[20:14:19] <shamanas> o guess i could try to work on oc sometime? :P
[20:14:50] <shamanas> but ill most likely write ugly code :(\
[20:14:57] <shamanas> never really wrote a compiler/interpreter
[20:15:13] <shamanas> only a lisp interpreter in C++ one time ... pretty simple stuff
[20:15:20] <duckinator> i've written plenty....but none of them worked right... :D
[20:15:33] <shamanas> although i pretty much know how they work
[20:15:47] <shamanas> and with my bit of rock experience
[20:15:53] <shamanas> i improved
[20:16:10] <shamanas> still, id have no idea how to write resolving from scratch myself
[20:16:19] <shamanas> the frontend and backend is pretty easy imo
[20:16:50] <duckinator> i think ndd's got a decent start on oc, you'll probably at least be able to help with the simpler stuff :P
[20:17:13] <duckinator> whereas i've worked with the sdk far far far more than rock itself, so..yea...not really much experience with any working compilers ;P
[20:18:57] <shamanas> anyway ill just fix some rock stuff for now.. hopefully i can help with oc someday ^^
[20:20:28] <shamanas> https://gist.github.com/1149746 <--- and this is my language design experience :P
[20:21:51] <duckinator> i've come up with a bunch of language designs. none are very good...similar to the compilers for them... ;P
[20:22:09] <shamanas> this is heavily ooc inspired btw :P
[20:22:28] <shamanas> i liked stiff btw ;)
[20:23:01] <shamanas> the FFI is not finished though
[20:23:05] <duckinator> stiff took a lot of ideas from ooc and/or ideas that were at one point discussed or considered for ooc ^^
[20:24:29] <duckinator> i really like the Dispatch API in stiff...might try implementing that in ooc sometime
[20:25:51] <duckinator> stiff is like a bizarre combination of JavaScript, ooc, and a couple ooc ideas that nobody bothered with because they offered little to no benefit ^^
[20:26:49] <shamanas> i only found one flaw
[20:26:54] <duckinator> the big thing that i got from an old proposed ooc change was the ->{} instead of func{}...that'd to nothing but break old ooc code or offer no benefit and make the language more complex
[20:26:57] <duckinator> which is? :D
[20:27:12] <shamanas> the pattern matching
[20:27:18] <shamanas> in the gist you made
[20:27:37] <shamanas> you had something in the lines of
[20:27:58] <shamanas> f: fn(0) -> 1
[20:28:03] <shamanas> f: fn(1) -> 0
[20:28:15] <shamanas> f: fn(n) -> n+1
[20:28:18] <shamanas> for example
[20:28:26] <shamanas> but this is like redefining the functuion
[20:28:36] <duckinator> ah, yea
[20:28:47] <shamanas> how do you know the user doesnt want to redefine it with an inclomplete pattern match?
[20:28:58] <shamanas> thats why in pride there is the pattern matching literal
[20:29:00] <shamanas> :D
[20:29:05] <duckinator> well, what i came up with this:
[20:29:52] <shamanas> wich is (Type1,Type2) => (0,_) -> 0 | (_,0) -> 0 | (_,_) -> 1
[20:29:53] <duckinator> f: -> (arg1, arg2) { /* do something with arg1 and arg2 */ } // function declaration
[20:30:19] <duckinator> f: (arg1, arg2) -> /* do something with arg1 and arg2 */  // pattern matching
[20:30:29] <duckinator> it's subtle but...it sorta works
[20:30:37] <duckinator> i want to redo that, but that'd at least work
[20:30:53] <shamanas> hm y
[20:31:06] <duckinator> https://github.com/stiff-lang/spec/blob/master/design.md
[20:31:07] <shamanas> but what about lambdas with pattern matching?
[20:31:13] <shamanas> my way supports this
[20:31:41] <duckinator> (arg1, arg2) -> { /* pattern matching with arg1 and arg2, but this would be a horrifying mess to parse */ }
[20:32:14] <duckinator> hmmm, wow
[20:32:19] <shamanas> also, the only reason i did not chose f arg1 arg2 calls is because the obj access is done with whitespace (surprise surprise!!)
[20:32:26] <duckinator> such a better idea i just had: using ~> for matching, -> for function
[20:32:40] <shamanas> y that is actually not bad :P
[20:32:44] <duckinator> er
[20:32:51] <duckinator> ~> (arg1, arg2) { /* pattern matching */ }
[20:33:14] <duckinator> it's not as obvious of a difference as i'd like, hm
[20:33:36] <duckinator> idk, that's a lot less shitty than what i have atm, regardless :P
[20:33:40] <shamanas> maybe -> and => ? :P
[20:33:53] <duckinator> => for functions?
[20:34:10] <shamanas> whatever you like best xD
[20:34:14] <duckinator> hm
[20:34:15] <shamanas> i would have kept -> for functions personally
[20:34:35] <duckinator> oh wow
[20:34:42] <duckinator> my local version is way different than what i committed last lmao
[20:35:12] <shamanas> also i like my idea of "chain calling" wich is basically
[20:35:17] <shamanas> a b()
[20:35:18] <shamanas>   c = 2
[20:35:24] <shamanas>   d(g())
[20:35:31] <shamanas> wich is equivalent to
[20:35:33] <shamanas> a b()
[20:35:35] <shamanas> a c = 2
[20:35:39] <shamanas> a d(g())
[20:35:54] <duckinator> so it's like an implicit form of ooc's . using whitespace?
[20:36:04] <shamanas> well its better :P
[20:36:10] <shamanas> i dont think you can do
[20:36:25] <shamanas> a b(). c=2. d(g()) in ooc
[20:36:32] <duckinator> ah, no you can't :P
[20:36:34] <shamanas> the assignement i mean
[20:36:44] <shamanas> also it can be brached further
[20:36:47] <shamanas> a b()
[20:36:49] <shamanas> a c = 2
[20:36:54] <shamanas> ups
[20:36:57] <shamanas> a b()
[20:37:10] <shamanas>   c doStuff()
[20:37:20] <shamanas>     a = b
[20:37:26] <shamanas>   d = 42
[20:37:34] <shamanas>   print("foobar")
[20:38:36] <duckinator> interesting :D
[20:38:41] <duckinator> also, apparently i have 2 designs for stiff now xD
[20:38:46] <duckinator> https://github.com/stiff-lang/spec/blob/master/design.md
[20:38:48] <duckinator> https://github.com/stiff-lang/spec/blob/master/old-design.md
[20:39:19] <duckinator> fwiw design.md hasn't been looked at since June so i have no clue if i finished
[20:40:27] <shamanas> hm i have to think about generics
[20:40:35] <shamanas> thought about doing it the stiff way
[20:40:51] <duckinator> stiff basically assumes it works for any type unless explicitly stated otherwise
[20:40:58] <duckinator> and it gives an error if you do something silly
[20:41:01] <shamanas> aka not typed functions, everything resolved on compilation
[20:41:19] <shamanas> but i think it must be too difficult to implement :P
[20:41:45] <duckinator> hm
[20:41:55] <duckinator> shamanas: fn (arg1, arg2) { } or -> (arg1, arg2) { } ?
[20:42:19] <shamanas> same to me
[20:42:21] <duckinator> i personally like both so i can't really decide xD
[20:42:29] <shamanas> but i guess -> would be better
[20:42:31] <shamanas> just because
[20:42:41] <shamanas> fn could then also be a variable name :D
[20:42:49] <shamanas> yay best reason ever
[20:43:24] <duckinator> mmm, that's true. and i think -> allows for nicer shorthand versions..like, foo(-> { bar }) is more readable than foo(fn { bar })
[20:43:40] <shamanas> yes true
[20:44:10] <shamanas> hmmm
[20:44:27] <shamanas> i guess after all i am going with full type transparency
[20:44:32] <shamanas> no types seen, no harm done :P
[20:44:35] <duckinator> haha
[20:44:40] <shamanas> all infered
[20:44:51] <shamanas> but still statically typed (ofc)
[20:44:59] <duckinator> i was thinking doing that, and if you specify types it's more of a sanity check
[20:45:04] <duckinator> like...
[20:46:35] <duckinator> well, it's functionally equivalent to that :)
[20:46:48] <shamanas> you forgot the ugly dots, its stiff ;o
[20:46:56] <duckinator> bah D;
[20:47:11] <shamanas> i see what you mean
[20:47:33] <duckinator> but yea, the type is more of a "oh hey, compiler, ONLY THIS IS VALID" than actually changing how it works
[20:48:05] <shamanas> any thoughts on operators btw?
[20:48:58] <shamanas> also, polymorphism? xD
[20:49:04] <shamanas> i thought about suffixes
[20:49:08] <shamanas> li9ke ooc :p
[20:49:09] <shamanas> like*
[20:49:50] <shamanas> but because of the fact any type can be passed as argument they will hhave to be specified manually every time if the functions have the same number of arguments
[20:50:13] <shamanas> also, function currying? :O
[20:50:37] <shamanas> too difficult (especially if i have C as a target language)
[20:51:39] <duckinator> currying doesn't sound fun if you generate C :P
[20:51:53] <duckinator> but, about this: <shamanas> but because of the fact any type can be passed as argument they will hhave to be specified manually every time if the functions have the same number of arguments
[20:52:04] <duckinator> generate required ones as needed
[20:52:06] <duckinator> ie:
[20:52:14] <duckinator> add: -> (one, two) { one + two }
[20:52:44] <duckinator> add("a", "b") // creates add__String_String(String one, String two)
[20:52:56] <duckinator> add(1, 2) // creates add__Int_Int(Int one, Int two)
[20:53:07] <duckinator> add("a", 2) // creates add__String_Int(String one, Int two)
[20:53:08] <duckinator> etc
[20:53:14] <shamanas> y that is what i had in mind for the c backend
[20:53:19] <shamanas> what i mean is
[20:53:22] <shamanas> e.g.
[20:53:46] <shamanas> dothing = (a,b) -> a + b
[20:53:59] <shamanas> dothing~woot = (a,b) -> a*b
[20:54:12] <shamanas> although in this case this is totally useless
[20:54:17] <shamanas> or
[20:54:32] <shamanas> add = (a,b) -> a+b
[20:54:46] <shamanas> add~retString = (a,b) -> (a+b) toString()
[20:54:55] <duckinator> ah
[20:55:02] <duckinator> just change ~ to __ or similar, i guess?
[20:55:30] <shamanas> y i guess >.<
[20:56:12] <shamanas> I have an urge to implement that now :P
[20:56:18] <shamanas> I will someday
[20:56:30] <shamanas> maybe write a grammar tomorrow?
[20:56:33] <shamanas> xD
[20:59:11] <shamanas> although if there are no types anywhere, how am i to define the type of an extern function ? :/
[20:59:20] <duckinator> hmm
[21:00:06] <duckinator> shamanas: the compiler could treat externs as a completely different type, which require conforming to certain types
[21:00:18] <duckinator> ...fail explanation, but do you get what i mean? :P
[21:00:41] <shamanas> that all types are accepted like other functions but some argument types are expected
[21:00:45] <shamanas> i mean
[21:00:52] <shamanas> f = extern(Int)
[21:00:57] <shamanas> f("lulz")
[21:01:10] <shamanas> Exception: expected Int, got String
[21:01:15] <duckinator> yea
[21:01:43] <shamanas> so i would write the type the Haskell way if currying is supported
[21:02:03] <shamanas> f = extern(Int->Int->CString)
[21:02:16] <shamanas> f(1,41) toString() println() :D
[21:02:24] <duckinator> that could work, yea :D
[21:03:34] <shamanas> btw supporting currying should not be THAT difficult
[21:03:39] <shamanas> it would mainly be heavy.
[21:03:42] <shamanas> very heavy.
[21:04:36] <shamanas> for example
[21:04:45] <shamanas> f = (a,b) -> a+b
[21:04:49] <shamanas> f(1)
[21:04:52] <shamanas> f(1,41)
[21:04:58] <shamanas> f('a')
[21:05:03] <shamanas> f("lol","haha")
[21:05:06] <shamanas> would generate
[21:05:16] <shamanas> 5 c functions :/
[21:05:46] <duckinator> oh wow xD
[21:06:26] <shamanas> 1 for the curried Int, 1 for the normal Int, 1 for the curried Char, 1 for the normal Char, 1 for the normal String
[21:06:32] <shamanas> assuming the compiler is that smart
[21:06:41] <duckinator> normal/curried could be combined
[21:06:50] <duckinator> like f(1,41) could be treated to f(1)(41)
[21:06:53] <shamanas> and does not generate every possible combination for each different type combo
[21:07:02] <duckinator> it depends on whether speed or binary size is more important to you
[21:07:23] <duckinator> also, it'd probably be easier to generate them as-needed than to generate every combination :P
[21:07:35] <shamanas> yes true :P
[21:07:40] <duckinator> until you get to imports. that's when you start getting into the "ow my brain hurts" area... :)
[21:07:48] <duckinator> but, you're a bit off from there ;)
[21:07:58] <shamanas> about f(1)(41) : lets look at it C-wise
[21:08:09] <shamanas> it would still create 2 functions
[21:08:12] <shamanas> my plan was
[21:08:25] <duckinator> yup, BUT f(1,41);f(1) creates 2 functions -- not 3
[21:09:04] <shamanas> well that was the plan
[21:09:12] <shamanas> the plain function with all arguments
[21:09:47] <shamanas> and then another one that takes one one argument and calls the plain one
[21:09:49] <shamanas> anyway
[21:10:13] <duckinator> i probably won't have currying in stiff, just because i have varargs
[21:10:19] <duckinator> and those two together are beyond painful
[21:11:04] <duckinator> head: [first, rest...] -> first // using the old pattern matching style
[21:11:21] <duckinator> head => [first, rest...]: first
[21:11:42] <duckinator> that's the one i'm considering^
[21:12:20] <duckinator> hmm
[21:12:25] <shamanas> eerm
[21:12:34] <duckinator> this is getting annoyingly inconsistent :(
[21:12:47] <shamanas> imho head: [first, rest...] => first would be better
[21:12:49] <shamanas> i mean
[21:12:51] <duckinator> yea
[21:13:05] <shamanas> here you are making a distinction between lambdas and ordinary functions
[21:13:05] <duckinator> that's more consistent, too
[21:13:19] <duckinator> er?
[21:13:26] <shamanas> well
[21:13:28] <duckinator> no, only between pattern matching and non-pattern-matching :P
[21:13:35] <shamanas> oh
[21:13:43] <shamanas> y got it >.<
[21:13:45] <duckinator> lol
[21:13:59] <duckinator> it's ok, it confuses me too because the original design was terrible in terms of pattern matching :D
[21:14:08] <duckinator> or..hm
[21:14:31] <duckinator> should vararg be available in normal functions, pattern matching, or both?
[21:14:33] <duckinator> bah, g2g. bai :P
[21:14:41] <shamanas> cya :D
[21:14:51] <shamanas> will show you what i end up with tomorrow :P
[21:33:32] *** shamanas has quit IRC
[21:38:34] *** mickael9 has quit IRC
[21:39:55] *** mickael9 has joined #ooc-lang
[21:40:12] *** mickael9 has quit IRC
[22:02:01] *** Jetbeard has joined #ooc-lang
[22:09:59] *** curtism has joined #ooc-lang





top