<<04-09-2012>>

---

04:16:38	*	Boscop quit (Disconnected by services)
04:16:40	*	Boscop joined #nimrod
05:16:54	*	Boscop quit (Disconnected by services)
05:16:56	*	Boscop joined #nimrod
06:14:49	*	q66 joined #nimrod
07:18:58	*	silven joined #nimrod
07:30:00	fowl	http://i.imgur.com/EtN3e.gif :D
07:32:04	*	Boscop quit (Disconnected by services)
07:32:06	*	Boscop joined #nimrod
07:39:47	*	Araq_ joined #nimrod
07:48:03	*	Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
08:06:07	*	Boscop quit (Ping timeout: 240 seconds)
08:15:09	*	Boscop joined #nimrod
08:32:19	*	Boscop quit (Disconnected by services)
08:32:21	*	Boscop joined #nimrod
08:36:37	*	Boscop quit (Disconnected by services)
08:36:38	*	Boscop joined #nimrod
08:48:56	*	banisterfiend joined #nimrod
09:01:43	*	statarb3 joined #nimrod
09:03:05	*	statarb3 left #nimrod ("Leaving")
09:12:06	*	Araq_ joined #nimrod
09:12:24	Araq_	hi banisterfiend
09:12:34	banisterfiend	Araq_: hey
09:12:53	Araq_	most action happens here at night ;-)
09:14:38	banisterfiend	what's the action?
09:14:41	banisterfiend	night where? :)
09:14:45	banisterfiend	isn't this an internatinoal channel? :D
09:14:59	Araq_	sure but most of us are europeans
09:15:23	Araq_	the action is sometimes language feature discussions
09:15:25	banisterfiend	oh ok
09:15:29	banisterfiend	im from amurca, the bronx
09:15:45	Araq_	sometimes ramblings
09:26:30	Araq_	I have to go, see you later
09:26:45	*	Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
09:31:13	*	XAMPP_ quit (Read error: Connection reset by peer)
09:37:18	*	Boscop quit (Disconnected by services)
09:37:20	*	Boscop joined #nimrod
09:43:59	*	Boscop quit (Disconnected by services)
09:44:01	*	Boscop joined #nimrod
10:14:57	*	Araq_ joined #nimrod
10:16:48	*	Araq_ quit (Client Quit)
10:32:20	*	Boscop quit (Ping timeout: 248 seconds)
10:44:16	*	Boscop joined #nimrod
11:06:51	*	Boscop quit (Disconnected by services)
11:06:53	*	Boscop joined #nimrod
11:23:34	*	banisterfiend quit (Read error: Connection reset by peer)
11:50:42	*	XAMPP joined #nimrod
11:58:43	*	Araq_ joined #nimrod
11:59:23	*	Araq_ quit (Client Quit)
12:07:07	*	Boscop quit (Disconnected by services)
12:07:10	*	Boscop joined #nimrod
13:07:14	*	Boscop quit (Disconnected by services)
13:07:16	*	Boscop joined #nimrod
13:31:52	*	Araq_ joined #nimrod
13:32:14	*	Araq_ quit (Client Quit)
14:07:56	*	Boscop quit (Disconnected by services)
14:07:58	*	Boscop joined #nimrod
15:12:08	reactormonk	fowl: almost ;-)
16:07:26	*	Trix[a]r_za is now known as Trixar_za
16:33:17	dom96	Awesome. This will be perfect for Nimbuild: https://github.com/blog/1227-status-api
16:34:01	dom96	fowl: The poo ship is spinning :D
16:36:12	Araq	hi dom96
16:36:29	dom96	hello Araq
16:36:37	Araq	we need NimBot to say hello to new guests
16:36:55	Araq	so we fake some activity :-)
16:38:47	dom96	That will be annoying though
16:38:59	dom96	I think you've already suggested this
16:41:51	dom96	Every time you rejoin "Hello Araq!"
16:42:46	Trixar_za	Maybe make it remember people
16:44:07	Trixar_za	Simple array of strings. I use it all the time to cheat.
16:46:01	dom96	hrm, well in fact.
16:46:05	dom96	!seen Araq
16:46:05	NimBot	Araq was last seen on Tue Sep 4 17:36:55 2012 in #nimrod saying: so we fake some activity :-)
16:46:13	dom96	NimBot already remembers :P
16:46:18	dom96	Trixar_za: Good idea.
16:50:29	*	shevy quit (Ping timeout: 248 seconds)
16:52:43	Trixar_za	I'm the master of half-arsing stuff
16:56:06	dom96	lol
17:02:57	*	shevy joined #nimrod
17:18:23	Araq	damn ... I figured out how Nimrod should work
17:18:33	Araq	but we need to get 0.9.0 out
17:18:59	Araq	so what to do?
17:19:12	Trixar_za	Pull a Microsoft
17:20:04	Araq	what's that?
17:21:14	*	zahary joined #nimrod
17:21:43	Trixar_za	Release even if you're not ready for a release. Generally if the change needed for a true release is too complicated and require rewriting large amount, they just release what they have
17:21:51	Trixar_za	That's how we got Windows Vista
17:21:51	Trixar_za	:P
17:22:08	Trixar_za	large amounts of code*
17:22:15	Araq	I see, ok
17:22:28	Araq	zahary: turns out I'm stupid
17:22:40	zahary	about what?
17:22:47	Araq	and most of what TR macros can do can also be done with ordinary macros
17:23:11	Araq	a = b + c * d
17:23:26	Araq	make + and * overloaded macros
17:23:53	Araq	and you can achieve quite the same as they can analyse the structure of their arguments
17:25:15	zahary	well, ok, but it's supposed to make some things more convenient. and as I said before, the capability to merge multiple statements is the most useful part
17:25:29	Araq	really? I don't know yet
17:26:03	Araq	the examples I looked at really benefit from AST overloading
17:26:10	Araq	not so much from term rewriting
17:26:28	Araq	template re(pat: string{lit}, flags): TRegex =
17:26:43	Araq	var cached {.global.} = re(pat, flags)
17:26:45	Araq	cached
17:27:07	Araq	the typ{pattern} stuff is really good
17:27:16	Araq	and needs to be done in sigmatch too
17:27:30	zahary	yep
17:27:40	Araq	in fact, we're almost there, passing nOrig around
17:28:15	zahary	expr{string} is nicer for re specifically IMO
17:28:38	Araq	expr{string} is the same as string{lit}, right?
17:29:10	zahary	does string{lit} try to evaluate more complex expressions?
17:29:24	Araq	not yet, but it's planned
17:29:30	zahary	that's what I meant
17:29:42	Araq	well yeah they will become the same
17:29:54	Araq	and string{lit} is clearer IMO
17:30:41	zahary	I don't really care - static{string} would be my vote
17:31:12	zahary	TMyType{lit} is somewhat confusing
17:32:42	zahary	could be string{static} too
17:37:48	Araq	and actually the AST constraint shouldn't be part of the type
17:38:10	Araq	it is right now, but that leads to all sort of problems
17:38:33	Araq	TObject{X} vs. TObject can only be done by cloning TObject
17:38:40	Araq	and keeping the ID the same
17:38:48	Araq	that's a recipe for desaster
17:39:15	Araq	we need to use (type, pattern) tuples
17:39:34	Araq	or maybe even (type, pattern, effect) for the planned effect system
17:40:42	Araq	overloading resolution would work over (type, pattern) of course, not over the types only
17:41:27	Araq	and I wonder how many second class types like 'tyTypeDesc' can we get rid of with this approach
17:42:07	Araq	currently we use tyInt + typ.n to denote the special tyIntLit type for instance
17:43:43	Araq	the "l-value" property is also a special pattern that could be abstracted over
17:44:37	Araq	currently we already perform a second semcheck pass over an nkCall to check against l-value violations
17:45:09	Araq	this pass should do additional work like side effect analysis and alias analysis
17:46:56	zahary	can you describe the planned effect system btw? we haven't talked about it I think
17:47:23	Araq	it's really simple, you introduce an effect like:
17:47:29	Araq	{.effect: io.}
17:47:42	Araq	and then mark some procs io
17:47:56	Araq	and procs that call io procs are marked io by the compiler too
17:48:12	Araq	and then you can do:
17:48:24	zahary	are effects further parametric? like writing(foo)
17:49:08	Araq	proc no_IO {. ~ io.} # syntax debatable
17:49:49	Araq	the effects list will also do exception tracking
17:50:02	Araq	parametric effects are not planned
17:50:33	Araq	if you have code like:
17:50:36	Araq	try:
17:50:38	Araq	...
17:50:41	Araq	except EIO:
17:50:43	Araq	...
17:50:45	zahary	well, exception tracking requires them, no? throws(Error1, Error2)
17:51:09	Araq	then of course the EIO exception will be removed of the list of possible effects
17:51:41	Araq	in fact, we can instead conflate effects and exceptions completely:
17:51:59	Araq	type TMyEffect = object of EIO
17:52:31	Araq	btw I found a way to make this analysis work with procvars
17:53:14	zahary	without full program analysis?
17:53:39	Araq	no ... ;-)
17:54:34	Araq	but it's a minor point anyway IMO type T = proc {.nosideffect.} works nicely
17:55:07	Araq	basically giving up inference when dynamic binding is involved
17:55:23	Araq	but should work well enough in practice
18:04:38	Araq	so what do you have in mind for multi statements patterns?
18:05:14	Araq	even basic copy propagation can't be done with it ...
18:06:07	Araq	I can only think of the 'write' optimization (which btw already works ;-) )
18:09:21	*	Trixar_za is now known as Trix[a]r_za
18:10:54	zahary	well, indeed there are not so many examples besides the merging of statements like write - I probably can come up with something about merging network sends or graphics API calls, but they would be hardly realistic
18:11:27	zahary	how does it look like right now (merging writes) ?
18:12:42	Araq	see tests/patterns/tstmtlist.nim
18:13:31	Araq	more advanced it would look like:
18:14:32	Araq	template optWrite{
18:14:34	Araq	write(f, x)
18:14:35	Araq	((write|writeln){w})(f, y)
18:14:37	Araq	}(x, y: varargs[expr], w, f: expr) =
18:14:38	Araq	w(f, x, y)
18:15:33	Araq	I should test that :D
18:17:36	zahary	and does it slow down compilation?
18:18:31	Araq	yes
18:18:37	zahary	how much?
18:18:55	Araq	bootstrapping is 2.5s vs 2.6s I think
18:19:07	zahary	it's not that bad
18:19:08	Araq	but that measures only the check against an *empty* pattern list
18:19:14	zahary	aha
18:19:47	Araq	I can speed it up this test a bit
18:20:12	zahary	test instead what will happen if you add the write pattern to the compiler
18:21:46	Araq	later, brb
18:31:48	*	Reisen quit (Ping timeout: 276 seconds)
18:33:06	*	Reisen joined #nimrod
18:36:12	Araq	I've also gathered experience with tyProxy btw and it doesn't work the way I imagined
18:36:34	Araq	I needed that for better IDE support
18:36:53	Araq	where I mapped tyError to tyProxy
18:37:25	Araq	as an errornous type should match everything
18:37:51	Araq	so that 'suggest' works
18:40:13	zahary	I think we are imaging tyProxy in a different way - xmlNode is a proxy type for me or luaObject
18:40:28	zahary	procs accepting these type doesn't match anything
18:41:27	zahary	I thing I got what you want you mean by tyProxy at some point, but I can't quite recall now
18:41:42	Araq	to me it's the opposite of tyExpr
18:41:57	Araq	it tyExpr is a *param* everything matches against it
18:42:15	Araq	if tyProxy is an *argument* it matches every parameter
18:42:25	zahary	ah, I think I recall now
18:42:35	Araq	and a macro is attached to it
18:42:46	Araq	so that it's rewritten to:
18:43:06	Araq	f(proxy[m]) --> m(f, proxy)
18:44:12	zahary	the rewrite part is what is certain
18:45:34	zahary	you mean that if I have a proc like foo(f: TFile) and I can pass some proxy object instead of TFile?
18:45:43	Araq	yes
18:46:12	zahary	and somehow you create a false TFile type that have it's functions rewritten to the proxy's macro?
18:46:25	zahary	is there some dynamic dispatching here
18:46:50	Araq	no
18:47:07	zahary	do you compile foo twice then?
18:47:12	Araq	in sigmatch.nim every ty* comparison also checks against tyProxy
18:47:20	Araq	and tyProxy is a match
18:47:47	zahary	I ask what C code is generated in the end?
18:47:50	reactormonk	\o/ proxy objects
18:48:31	Araq	C code is determined by the macro
18:49:32	zahary	let's get back to foo(f: TFile) - obviously this function can be called with a real TFile, so it will be compiled with a concrete calls to the real TFile related procs
18:49:33	Araq	m(foo, args)
18:49:42	zahary	what happens when I call it with a proxy object instead
18:49:52	Araq	m(foo, args)
18:49:58	Araq	'foo' lost control
18:50:09	reactormonk	do you get message call objects?
18:50:16	Araq	'm' says what to do
18:50:59	zahary	ah, I ask about the calls involving the proxy object inside foo
18:51:19	Araq	well that's indeed one problem :D
18:51:20	zahary	but the rewrite is never supposed to get to there..
18:51:42	Araq	another is that we need to suppress ambiguity checking for tyProxy
18:52:17	zahary	well, do you understand how my views about proxy objects are different?
18:52:18	Araq	and it suppresses generic instantiation too
18:52:52	zahary	or should I give some examples
18:53:06	Araq	well you seem to have Go-like interfaces in mind
18:53:15	zahary	nope
18:53:17	Araq	except that you
18:53:22	Araq	don't start with them
18:53:36	Araq	;-)
18:53:51	zahary	let's take luaObject for examples
18:54:14	zahary	that's a regular value that can be stored in a variable, can be passed around in functions, etc
18:54:32	Araq	yeah and tyProxy turns it into an interface
18:54:53	Araq	and then you can pass something else fitting that interface
18:55:09	zahary	… except that when I try to call some unknown proc over it, the macro kicks in and rewrites it to placeLuaCall(luaObject, "ProcName", arguments)
18:55:51	zahary	there is no part about "something else fitting the interface"
18:55:54	Araq	ah! now I remember. :-)
18:55:56	Araq	yeah
18:56:06	Araq	I thought you want interface injection for concrete types
18:56:32	Araq	which is another cool idea breaking modularity and everything else ;-)
18:57:16	zahary	you mean something like implicit interfaces (dynamic dispatch with inferred vtable) and stuff along the lines of existential types
18:57:51	Araq	yeah but taken one step further:
18:58:09	Araq	the code doesn't have to be changed to work with interfaces
18:58:32	Araq	instead you inject everything later
18:59:26	zahary	what do you mean by inject here?
18:59:26	Araq	but back to your idea: so you want x.f() to compile if 'f' is unknown
18:59:59	zahary	if x is a proxy type
19:00:05	Araq	so x.f(args) transforms into x("f", args) ?
19:00:17	Araq	and x' has an overloaded operator() ?
19:00:34	zahary	as I suggested before, terms rewriting is equivalent and gives you the ability to further filter when the rewrite will happen (but requires more cumber-some syntax)
19:00:52	Araq	term rewriting is not equivalent
19:00:56	zahary	the transformation is the old proxyMacro(x, f, args)
19:01:08	Araq	term rewriting happens too late
19:01:27	Araq	if x.f(args) does not semcheck, it does not semcheck
19:01:37	Araq	TR doesn't help with that
19:01:37	zahary	about TR: it is if the pattern is { x.OP(args) } (OP: Ident ...)
19:01:56	zahary	don't know whether you can say that right now
19:02:24	Araq	well it's easy to support ;-)
19:02:40	Araq	and will slow down everything even more
19:02:51	zahary	:)
19:03:15	Araq	you need to do the TR at the beginning of semExpr()
19:03:26	Araq	right now I do it only at the end of semExpr()
19:03:32	zahary	I can live with specialized faster-to-compile tyProxy handling
19:04:13	Araq	well there is already --patterns:off ;-)
19:04:28	Araq	and you can turn it on and off just like array index checks
19:04:31	zahary	but proxy types are not merely optimization
19:04:38	Araq	{.push patterns:on.}
19:04:40	zahary	they must execute always
19:04:43	Araq	I know
19:04:58	Araq	just like some overflow checks
19:05:31	Araq	we can turn them off for the stdlib for instance, right?
19:06:01	*	Zerathul joined #nimrod
19:07:22	zahary	the patterns?
19:07:48	zahary	I think each pattern should control its own application
19:07:49	zahary	when release:
19:07:49	zahary	complex optimization rule
19:09:43	Araq	btw compile time is not affected with a simple optWrite rule in system.nim
19:10:08	zahary	so it's not that bad after all
19:13:06	Araq	dunno 'write' is not a common call
19:13:35	zahary	throw in the concat optimisation too :)
19:14:33	zahary	it's looking nice btw - would be harder without patterns (although I remember the specialised merge pragma alternative too)
19:15:13	Araq	it also doesn't work the way you think it does ;-)
19:15:33	Araq	because in x & y & z
19:15:44	Araq	(x & y) is "optimized" already
19:15:58	Araq	and then (x & y) & z matches later
19:16:12	Araq	so you have to ensure it remains sane
19:16:52	zahary	you mean the pattern matches (x & y) initially?
19:17:14	Araq	it matches `&`*a already
19:17:28	Araq	and gets transformed
19:17:42	zahary	it's not greedy?
19:17:43	Araq	and then (x & y) & z matches too
19:17:53	Araq	it is greedy
19:18:07	*	Zerathul quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
19:18:10	Araq	but the bottom up recursion works that way
19:18:30	Araq	and I can't help it
19:18:39	Araq	you wanted it in semExpr ... :P
19:18:59	zahary	but what's the aftermath - do I end up with two calls to the optimised concat proc?
19:21:54	Araq	yes
19:21:59	Araq	if you're not careful ;-)
19:22:19	zahary	I see that in the test case there is a single call
19:22:39	zahary	does the parenthesis have something to do with it?
19:23:21	Araq	no there is special logic with 'varargs'
19:23:28	Araq	and nkArgList
19:23:30	Araq	so that it works
19:24:36	Araq	well I guess ordinary users of the * feature don't need to be careful anymore
19:24:52	Araq	but it was a puzzle to get it to work
19:25:03	zahary	I'm still not quite understanding the issue, but I can look at the code later
19:26:07	zahary	it seems to me that what you said will always be true (any binary operator will match the initial two arguments and apply the rule early)
19:26:43	Araq	yes
19:28:57	Araq	ouch!
19:29:09	Araq	I didn't export the template for the speed test ...
19:29:26	zahary	can I skip the second varargs template?
19:29:26	zahary	template optimizeConcat { `&&`* args } ( args: varargs[string] ) = ...
19:30:07	Araq	good question ...
19:31:36	Araq	well it's a bit slower but not much, 2.65s vs. 2.60s
19:31:40	Araq	for this pattern:
19:31:42	Araq	template optWrite*{len(x)}(x: expr): expr = len(x)
19:31:51	Araq	and 'len' is very common ;-)
19:34:16	Araq	and yeah there is special logic so that it doesn't recurse endlessly
19:43:57	zahary	I'm getting 1.433 -> 1.5
19:44:11	zahary	it's interesting that adding more patterns doesn't seem to slow it much further
19:45:19	zahary	also, most time is spent in the C compiler usually (which is not even measured here)
19:46:22	zahary	so how do my views about tyProxy fit in your picture?
19:53:01	Araq	you need to add the pattern stuff to the begin of semExpr
19:53:08	Araq	and then it may already work
19:54:41	Araq	most patterns are nkCall(ident, ...)
19:54:52	Araq	and you have a mismatch already with 'ident'
19:55:08	Araq	I guess we could special case that for better performance
19:59:10	Araq	er, zahary, you need to do --hint[Pattern]:off for better results
19:59:24	Araq	console output is always significant
19:59:40	Araq	unless your patterns never match ;-)
20:03:41	zahary	ah, didn't know how to do that - it shaved off another 0.1s
20:13:15	Araq	we also need an order for ASTs for canonicalization of commutative ops
20:13:58	Araq	template commPlus{ a + b}(a: expr{lit}, b: expr) = b + a
20:14:17	Araq	is already quite nice but it'd better be done with some builtin
20:15:17	Araq	luajit uses some arbitrary order based on variable slots etc. if I understood the code correctly ...
20:32:17	Araq	o.p(args) --> m(o, "p", args)
20:33:08	Araq	nkCall(nkDotExpr(o, p), args)
20:33:28	Araq	but you want 'o' to be semchecked
20:33:33	Araq	before kicking in ... hm
20:35:05	zahary	my plan was always to determine the types of expressions lazily - if the rule matches nkCall, but requires some of the sub-expressions to be typed, then determine their type on the spot
20:35:56	Araq	that's basically my "two phase type system" that plays nicer with macros
20:36:28	fowl	whats the lambda keyword or
20:36:30	fowl	for*
20:36:48	Araq	so 'unknownIdent' would get a type 'tyUnkown' and can be passed to a macro can use it
20:37:08	Araq	fowl: it's not used
20:37:32	fowl	o
20:42:50	Araq	but if 'p' doesn't exist you can use that to do the transformation
20:43:46	Araq	no need for 'o' to be of tyProxy, right?
20:48:39	Araq	er .. never mind, I got it now
20:52:09	*	zahary quit (Quit: Leaving.)
21:22:36	fowl	Araq: what doyou think about a special symbol like thisModule to refer the current module
21:22:53	reactormonk	fowl: what would it be used for?
21:23:18	fowl	otherwise if you change the name of your file you have to change uses of your module name in the file. good example of this is the gtk examples that all refer to ex1.destroy
21:24:04	fowl	reactormonk: only valid during symbol resolution phase
21:24:12	fowl	if that is a phase
21:24:35	Araq	kind of
21:24:51	Araq	it's also intermixed with type checking
21:25:17	Araq	and a bunch of adhoc analysis which start to bite me ...
21:59:05	Araq	well fowl, to answer your question some builtins like 'currentmodule', 'currentfile' are nice, yes
21:59:16	Araq	but I'm overwhelmed with work :P
22:00:02	Araq	and I have to sleep now, good night
22:00:27	*	EfTwelve quit (Quit: ChatZilla 0.9.88.2 [Firefox 15.0/20120824154833])
22:04:09	fowl	bye
23:04:57	*	q66 quit (Quit: Quit)