<<31-08-2012>>

---

00:01:37	EfTwelve	g'night
00:19:23	fowl	EfTwelve: the csfml wrapper isnt 100%, i have left out some of it like mutexes and the networking parts, you should be able to do raw opengl in it no prob
00:20:00	EfTwelve	thanks.
00:36:22	reactormonk	EfTwelve: I think there are ranges, but I'm not sure
00:36:37	reactormonk	and I'd call it ASCII_UPPER and _LOWER ;-)
00:37:34	EfTwelve	yeah, sampling from a range would be more elegant i think.
00:38:40	reactormonk	EfTwelve: there are subranges
00:38:47	reactormonk	overload random in such a way it takes a subrange
00:38:52	reactormonk	http://nimrod-code.org/tut1.html#subranges
00:39:08	reactormonk	you could even add that overload code to math.nim and submit a pull request
00:39:30	reactormonk	problem is that a subrange is a type, not a variable
00:40:29	reactormonk	there is indeed no range type
00:43:53	*	EfTwelve_ joined #nimrod
00:45:06	EfTwelve_	well, random should def be a float and take 2 args for min and max imo
00:47:20	reactormonk	EfTwelve_: tell Araq
00:48:24	EfTwelve_	ya i think i wil, i'll write the function first.
00:53:18	*	EfTwelve quit (*.net *.split)
00:53:18	*	silven quit (*.net *.split)
00:57:37	*	silven joined #nimrod
01:30:36	*	q66 quit (Quit: Quit)
02:32:50	*	EfTwelve joined #nimrod
02:35:29	*	EfTwelve_ quit (Ping timeout: 252 seconds)
04:40:51	EfTwelve	what is the equivalent argc argv in nimrod?
04:43:16	fowl	EfTwelve: os.paramCount and paramStr
04:43:52	fowl	also see parseopt module
04:44:47	EfTwelve	hmm, what about a c function that expects argc, argv? such as gluInit() http://force7.de/nimrod/glut.html#283
04:49:25	EfTwelve	arrrgg!! theres no documentation!!!!!
04:51:03	fowl	hmm i dunno, never tried glut
04:52:13	fowl	I think that should be a cstring
04:52:20	fowl	er cstringarray
04:53:13	fowl	what is that for anyways, sending command line args to glut?
05:00:44	EfTwelve	if the first function to initialize glut is glutinit() and takes argv,argc
05:00:50	EfTwelve	its*
05:03:36	fowl	EfTwelve: this seems to work https://gist.github.com/3549219 at least, it compiles and runs without error
05:06:05	fowl	Like argcp, the data for argv will be updated because glutInit extracts any command line options understood by the GLUT library. weird o_O
05:07:36	EfTwelve	dear lord! how would i even know that kind of syntax exists? there is nothing like that in the docs. lol
05:07:50	EfTwelve	thanks btw
05:08:26	fowl	EfTwelve: surprised about which syntax?
05:13:05	EfTwelve	the 'addr' statement
05:13:51	EfTwelve	i think if you hadn't shown me, there is no way i would that exists. ive never seen it in the tutorials or docs
05:14:16	EfTwelve	i would *know
05:15:36	fowl	o
05:21:09	EfTwelve	hmm, that code you posted wont compile for me. is that something in a later version than 8.14?
05:23:51	EfTwelve	binary or is 'or' ?
05:25:02	fowl	yes for binary or^
05:25:48	fowl	im not on 8.14 im on a week old HEAD
05:28:07	fowl	EfTwelve: what was the error
05:28:29	EfTwelve	the 'addr' needed parens around the var
05:31:40	Araq	good morning
05:31:53	Araq	yeah 'addr' requires parens in 0.8.14
05:32:18	Araq	and there is a way to get argv and argc but I forgot how
05:33:13	Araq	var
05:33:14	Araq	cmdCount {.importc: "cmdCount".}: cint
05:33:16	Araq	cmdLine {.importc: "cmdLine".}: cstringArray
05:33:17	Araq	there you go
05:33:38	Araq	but they can't work for a windows UI app
05:34:45	EfTwelve	fowls method works well
05:34:58	Araq	yeah fowl's method is preferable
05:35:45	Araq	and the tutorial doesn't mention 'addr' because it's unsafe :P
05:36:09	Araq	in general the manual is better if you can already program in C
05:40:57	EfTwelve	how is this supposed to be handled?: http://force7.de/nimrod/glut.html#327
05:41:12	EfTwelve	glutDisplayFunc wants a function pointer, doesnt like the one i give it
05:43:27	fowl	it needs a function like this: TGlutVoidCallback* = proc () no args, no return
05:44:43	*	XAMPP quit (Ping timeout: 245 seconds)
05:47:04	EfTwelve	hmm, nimrod doesnt like anything about that syntax
05:47:43	Araq	type T = proc () # a new *type*
05:47:57	Araq	proc p() = ... # a new *proc*
05:48:11	Araq	q(p) # pass p to q
05:58:26	fowl	or q(proc() = echo "hello") would work
06:01:13	EfTwelve	i dont understand any of that :(
06:02:04	fowl	EfTwelve: TGlutVoidCallback describes a proc that takes no arguments and returns nothing, any proc like that will be compatible
06:04:25	EfTwelve	except that nimrod wont even except that kind of syntax
06:05:19	EfTwelve	you mean a proc defined such as: TGlutVoidCallback* = proc display() =
06:05:21	EfTwelve	?
06:05:24	fowl	? can you paste your code somewhere
06:05:26	fowl	oh no
06:05:36	fowl	you dont have to use the type name at all
06:06:28	fowl	proc display() = ...
06:07:07	EfTwelve	gltest.nim(30, 18) Error: type mismatch: got (proc ())
06:07:09	EfTwelve	but expected one of:
06:07:11	EfTwelve	glutDisplayFunc(f: TGlutVoidCallback)
06:08:25	fowl	can you paste your code
06:08:42	fowl	not here, somewhere in the cloud
06:09:25	EfTwelve	https://gist.github.com/3549552
06:13:40	Araq	EfTwelve: you need to use the correct calling convention for display
06:13:42	fowl	EfTwelve: i figured it out, the type has cdecl pragma and apparently that doesnt come through the docs gen
06:14:00	Araq	I think it does in 0.8.15 :P
06:14:44	EfTwelve	hmm
06:14:55	fowl	EfTwelve: change your display func to proc display() {.cdecl.} =
06:15:33	fowl	Araq: i just generated docs locally and they didnt
06:15:35	EfTwelve	i see..
06:16:28	Araq	fowl: oh yeah the docgen
06:16:41	Araq	but the error message should mention the calling convention
06:17:18	fowl	i got the same error message he did
06:25:32	*	XAMPP joined #nimrod
06:29:06	EfTwelve	can a proc have static vars?
06:30:53	Araq	no, use globals instead
06:31:04	EfTwelve	wha!?
06:31:33	fowl	you have a variable local to the module outside the proc that you only use in the proc
06:31:42	fowl	same thing as a static var, i think
06:32:44	Araq	well you can also use 'var myStatic {.global.}: int' I think
06:32:49	Araq	but not in 0.8.14
06:36:40	EfTwelve	ok, i finally got triangles drawing on the screen..
06:36:55	EfTwelve	thanks for all the help with that..
06:38:46	EfTwelve	strange though.. this works: angle = angle + 0.5
06:39:21	fowl	angle += 0.5 should work
06:39:22	EfTwelve	but: angle += 0.5 complains about the var not being passed.
06:39:44	EfTwelve	"Error: for a 'var' type a variable needs to be passed"
06:41:04	EfTwelve	angle is defined globally as float32
06:43:13	fowl	hmm when i try it locally it works https://gist.github.com/3549682
06:44:11	Araq	I think there is no += for floats in 0.8.14 :P
06:50:18	EfTwelve	ok
06:51:35	fowl	EfTwelve: the problem with the documentation is that its boring to read so you skip sections of it without realizing
06:53:17	EfTwelve	ya, l'll go over the docs with more detail tomorrow.
06:53:30	EfTwelve	gotta get some sleep. Thanks for all the help!
06:53:42	fowl	no problem
06:54:01	Araq	fowl: which docs are particularly boring?
06:54:26	Araq	and how to fix it?
06:56:54	fowl	im not sure how to fix it, the tutorial looks like a big wall of text to me ._.
07:14:57	Araq	I dunno, I think the tutorial should be a big ball of examples instead
07:15:15	Araq	but I barely read anything anyway
07:15:40	Araq	I'm not the average tutorial reader ;-)
07:27:27	*	zahary joined #nimrod
07:31:32	Araq	hi zahary
07:32:21	fowl	yea i dont usually read them either
07:34:05	Araq	we need a cookbook
07:34:45	*	zahary quit (Ping timeout: 246 seconds)
08:33:00	shevy	I thought about the nimrod tutorial
08:33:09	shevy	Araq said that experienced users are bored by too much details
08:33:18	shevy	but newcomers need information desperately
08:33:31	shevy	and I think right now, a wealth of information is not available for newcomers
08:34:28	shevy	one addition that could be useful, would be extended and working .nim files in addition to the documentation
08:34:44	Araq	hey there is an examples/ folder :P
08:34:56	Araq	but the examples are not too good :D
08:35:01	shevy	yeah but take the gtk examples, without dom96's link, I am not sure I would have found them
08:35:21	Araq	well yeah that's the cookbook I'm talking about
08:35:33	Araq	it should start with basic snippets
08:35:34	shevy	the gtk examples were a big help to try and understand how things work btw
08:35:55	Araq	and then show some GTK examples and OpenGL examples
08:36:18	fowl	shevy: you could take a look at aporia's code
08:36:57	Araq	well aporia's code is - ugh - not the best way to learn :D
08:37:11	*	Araq is afraid of aporia's code
08:38:26	shevy	fowl yeah, I was too scared of it though, I like to digest in small snippets, aporia seemed daunting
08:39:16	shevy	for now that is :)
08:39:52	shevy	I know gtk a bit because I used ruby-gtk for two or three years, often had to look at the official C docu in Gtk
08:52:08	*	Boscop quit (Disconnected by services)
08:52:09	*	Boscop joined #nimrod
08:57:04	Araq	fowl: getting rid of forward declarations is a pita
08:57:31	Araq	I'm planning a hackish solution with yet another pragma:
08:58:21	Araq	{.foward.} # pull any proc headers that come afterwards in here
08:58:25	Araq	*forward
08:58:51	Araq	and yes, it can only work for procs
08:59:19	Araq	what do you think?
09:00:41	fowl	i dont get it.. i only forward procs when I have to
09:01:39	fowl	like if proc A calls proc B but im trying to keep them orderly
09:02:03	Araq	well yeah but people like order independence for procs
09:02:25	Araq	so you'd stick a {.forward.} pragma after your imports and type definitions
09:02:40	Araq	and the compiler would generate proc headers for you
09:02:54	fowl	that sounds awesome
09:02:57	Araq	and insert the forward declarations where the {.forward.} is
09:03:59	Araq	well it's not exactly "awesome" but better than nothing :-)
09:04:22	Araq	and seems the only solution that is feasable without lots of tinkering with all of the compiler's internals
09:04:48	Araq	*feasible
09:09:22	fowl	yea
09:09:26	fowl	sounds gr8 to me
09:10:26	Araq	alright
09:20:28	*	zahary joined #nimrod
09:20:38	zahary	hi Araq
09:20:45	*	Boscop quit (Disconnected by services)
09:20:46	*	Boscop joined #nimrod
09:20:55	Araq	hi zahary, I've implemented term rewriting macros :D
09:21:07	zahary	I noticed :)
09:21:11	Araq	still working on that feature though :-)
09:21:23	zahary	btw I studied the implementation of varargs and gensym and varags don't work the way I expected
09:22:08	Araq	well I have another feature in mind: tyParamList
09:22:20	Araq	maybe that's what you I expected?
09:22:24	zahary	haven't we talked about how varargs will be reduced to a possible heterogenous tuple?
09:22:42	Araq	well we talked about it
09:22:53	Araq	but that's tyParamList, aka '*'
09:23:14	zahary	I'd like to be able to say varargs[expr] or varargs[static{string}] or varargs[int or string] and so on
09:23:31	zahary	that's tyParamList?
09:23:38	Araq	well I dunno
09:23:50	Araq	tyParamList is supposed to be used for perfect forwarding
09:24:11	Araq	if you store it in an object, it'll transform to a tuple
09:24:29	Araq	however it will be unpacked for you again in: f(X)
09:24:33	zahary	is openarray obsolete now?
09:24:41	fowl	defShapeProp(CpFloat, e, Elasiticity, false) >_> <_<
09:25:01	Araq	no, openarray now means seq|array
09:25:18	Araq	except there are no generics involved
09:25:43	Araq	so openarray is just the way it always was but you can't pass multiple arguments to it
09:25:50	zahary	I see - do you agree about the interaction between varargs and the type classes I propose? I can try to implement it
09:26:49	Araq	well in fact, I'm still puzzled why I broke ttypedesc1.nim
09:27:24	zahary	hmm, haven't noticed. I'll look into it
09:27:48	Araq	and there is also bug 186 waitin' on you :-)
09:29:06	zahary	fowl, what was your goal in the example code?
09:29:06	zahary	https://github.com/Araq/Nimrod/issues/186
09:29:57	Araq	what's the difference between static{string} and expr{nkStrlit} ?
09:30:24	zahary	fowl, I think you meant to say t: typedesc{TestPkt}, but I'll look why such an error is produced
09:31:17	zahary	Araq, no difference right now - we talked once about changing expr{} to static{}, because it's more obvious for newcomers
09:31:26	fowl	zahary: i thought you could make a proc like that, i believe type(testpkt) would return typedesc{testpkt}
09:31:47	Araq	really? 'static' now means something completely different IMO
09:31:55	zahary	I does actually, but I never tested it this way
09:32:20	zahary	static = compile-time ?
09:32:22	Araq	"static" means "enforce compile time evaluation"
09:32:29	zahary	so compile-time param
09:32:49	Araq	but that's not what expr{nkStrLit} means
09:33:10	Araq	and I really need expr{nkStrlit} for TR macros
09:33:51	Araq	btw varargs[expr] already works
09:34:06	zahary	but only for macros?
09:34:20	zahary	didn't work for me in a simple example
09:34:22	Araq	don't think so, but I only tested it with macros
09:34:45	Araq	well it works for macros, it should work the same for procs?
09:34:56	Araq	oh wait
09:35:00	Araq	damn
09:35:27	zahary	I don't plan to change expr to static - It was just an example for a "match a category of parameters and not some concrete type"
09:35:28	Araq	well no, there is no special casing for varargs[expr]
09:35:44	Araq	good, I really prefer 'expr'
09:37:10	zahary	my plan about varargs was turn such params into implicit generics (maybe only when the underlying type is a type class) - so any va: varargs[int or string] proc will be instantiated once for any unique set of parameter types and va.len will be compile-time constant
09:40:05	Araq	what's the use case?
09:42:01	Araq	and I wonder whether is has anything to do with tyParamlist :D
09:42:03	Araq	iterator chain[S, T](a, b: *S->T, args: *S): T =
09:42:04	Araq	for x in a(args): yield x
09:42:06	Araq	for x in b(args): yield x
09:42:23	zahary	styledEcho comes to mind - it takes varargs[StyleEnum or Printable]
09:42:29	Araq	I use *S to mean "list of parameters"
09:42:33	zahary	I thing there are many use cases
09:44:03	Araq	the compile would transform *S into a tuple when you store it somewhere
09:44:17	Araq	and unpacks it in f(X)
09:44:52	Araq	I think C++ got the same feature?
09:45:09	Araq	can't think how its futures can work otherwise
09:45:11	zahary	implicit unpacking of varargs tuples is something I planned to talk about
09:45:46	Araq	well, maybe explicit pack and unpack primitives are easier to comprehend
09:46:09	zahary	yes, C++ has it, but there it's more needed, because generic varargs are handled only recursively
09:46:32	zahary	the nimrod way makes some use cases easier to handle
09:49:49	Araq	well we need something similar to *S for patterns:
09:50:16	Araq	template t{s[key] = f(X)} ...
09:50:32	Araq	it an important optimization for string tables
09:50:34	zahary	if you want me to generalize what's the use case for varargs conforming to some type class, such uses arise when you have some symbol-based DSL which produces configuration out of some expression tree
09:51:16	zahary	styledEcho is one example - in C++ I can also cite libraries such as http://www.rasterbar.com/products/luabind/docs.html
09:52:26	*	Boscop quit (Disconnected by services)
09:52:27	zahary	or http://www.boost.org/doc/libs/1_48_0/libs/spirit/doc/html/spirit/introduction.html
09:52:28	*	Boscop joined #nimrod
09:53:26	Araq	as it can take ownership if the expression is a function call
09:53:49	Araq	(thanks, was aware of both spirit and luabind but don't know how they work in detail)
09:55:43	zahary	hmm, wasn't this kind of varargs matching in patterns always in the plan?
09:56:08	Araq	sure but I'm cutting features ;-)
09:56:11	zahary	template t{ f(X) } (X: varargs[expr])
09:57:37	Araq	well that can't work with the current implementation
09:58:05	Araq	as f(1, 2, 3) doesn't match f(X) as a raw AST
09:58:14	Araq	we need to special case that in the matcher
09:58:34	Araq	and then we need nkArgList so that (1, 2, 3) can be captured properly
09:58:52	Araq	and template instantiation needs to consider nkArgList specially
09:59:39	zahary	what's the pipeline? we once talked about how f(X) is parsed first, then the param list is processed so X becomes argList at this step and finally the AST is matched
10:00:32	Araq	currently I reused the code that does template body semchecking
10:00:40	Araq	for {patterns}
10:01:00	Araq	and pattern matching is perfomed bottom up in semExpr
10:01:18	Araq	and in semStmt
10:01:32	Araq	and I guess it need to be done again after transform()
10:02:06	Araq	so patterns are "precompiled" in a fuzzy way
10:02:14	Araq	like template bodies are
10:02:22	zahary	so X got assigned to skParam symbol?
10:02:32	Araq	yes
10:02:34	zahary	nkIdent pointing to such symbol
10:02:51	Araq	it's simply an nkSym with skParam
10:02:59	Araq	with the proper owner
10:03:00	zahary	I see
10:03:08	Araq	and it has the proper type too
10:03:19	Araq	so it's not hard to make it match (1, 2, 3)
10:03:34	zahary	yes, and you could use that to implement the matching rules, I see
10:04:49	Araq	matching is a simple tree matcher with unification
10:05:20	Araq	which doesn't work for nkStmtList, but I'm implementing that right now
10:05:27	Araq	the problem is:
10:05:39	Araq	{write a; write b}
10:05:45	Araq	doesn't match:
10:05:58	Araq	{dummy; write a; write b}
10:06:13	Araq	as the pattern length is 2 and the actual tree's length is 3
10:06:26	Araq	the matching is really simplistic for now ;-)
10:07:20	zahary	I see - should be easy to fix
10:07:23	Araq	I figured that this fuzzy nkStmtList matching needs to be special cased everywhere and can not work recursively
10:07:41	zahary	hmm, why everywhere?
10:08:03	Araq	you need to split up the nkStmtList into prefix, middle and suffix
10:08:12	Araq	and then pass only middle to the macro
10:08:24	Araq	as it only deals with the middle which matched
10:08:27	zahary	you mean after it's matched?
10:08:31	Araq	yes
10:08:40	Araq	and then you need to merge it again
10:09:01	zahary	I'm already doing splicing on the nkStmtList because of destructors and finally, etc
10:09:45	Araq	ha, true it's needed there too
10:10:47	Araq	well it's simple to fix as it doesn't need to be done recursively
10:11:20	Araq	performance will be absymal I guess
10:12:32	zahary	in the very distant future we can compile the multiple patterns in the DFA so the scan can be linear
10:13:11	Araq	I dunno if that works for arbitrary patterns
10:13:18	Araq	does it?
10:13:32	zahary	kind of, if your alphabet is node kinds
10:13:46	zahary	… and symbol names (a bit harder)
10:14:38	Araq	yeah well we have side effects on patterns, order does matter
10:14:50	Araq	but I guess it works nevertheless
10:14:54	zahary	but let's see the performance hit first :)
10:15:05	Araq	lexer generators have the same problem after all
10:15:48	zahary	so what about varargs[type class] ?
10:16:15	Araq	well it should work without introducing special rules IMO
10:16:26	Araq	much like it does for varargs[expr]
10:16:51	zahary	the main difference is how it produces implicit generics - I'll have to make sure that works right
10:17:20	Araq	well about the generics ...
10:17:30	zahary	where is the missing special case for varags[expr] you mentioned?
10:17:48	Araq	no I mean, it shouldn't require special casing
10:17:55	Araq	and it already works for macros
10:18:12	Araq	and there is no special casing in sigmatch for it
10:18:15	zahary	well, macros are inlined - no instantiations there
10:18:33	zahary	the sigmatch part is probably pretty close to working
10:18:45	Araq	oh I see
10:19:07	Araq	you've been talking about the instantiation process all the time
10:19:16	zahary	yes
10:19:25	Araq	there is another generics bug
10:19:30	Araq	which I haven't yet looked into
10:19:42	Araq	let me create a proper bug report ...
10:21:18	Araq	bug #194
10:21:55	Araq	well I don't care much about the instantiation process so go ahead
10:22:07	Araq	however
10:22:44	Araq	I really dislike symbol binding in generics
10:23:02	Araq	and we need to come up with a solution
10:24:08	zahary	do we want the optimization that concrete types are still handled as the old openarray? (it reduces code bloat, but produces the inconsistency I mentioned before args.len is compile-time value with type classes and run-time value with concrete types)
10:24:35	zahary	symbol binding? you mean the koenig lookup?
10:24:49	Araq	hu? len is already sometimes a compile time value and sometimes not
10:25:18	Araq	yeah I mean the koenig lookup
10:25:38	Araq	(which I think isn't really koenig lookup ...)
10:25:45	zahary	yeah
10:26:34	zahary	well, what about it? one solution could be to just scratch it - always require distinct types
10:27:39	Araq	proc find[T, S]{eq=`==`, items}(container: T, e: S): int =
10:27:41	Araq	for x in items(container):
10:27:42	Araq	if eq(x, e): return
10:27:44	Araq	inc(result)
10:27:45	Araq	return -1
10:27:50	Araq	is an old idea of mine
10:28:23	Araq	so every symbol is bound at definition time but you can have explict "open" symbols like 'items' and '=='
10:28:40	zahary	aha, so you both document the requirements and provide means to capture them from the outer scope
10:28:50	Araq	yes
10:29:04	zahary	still doesn't solve the conflict problem, which is the bigger issue for me
10:29:22	Araq	and it's not overspecified like 'items(x: T): S'
10:29:51	Araq	(what if it's 'items(x: T, default = 0): var S' instead?
10:30:12	Araq	and then a hash table declaration would look like:
10:30:37	Araq	var t: TTable[string, string]{eqIgnoreCase, hashIgnoreCase}
10:31:07	Araq	and we need generic type and symbols inference for:
10:31:21	Araq	proc put(t: TTable, key: TKey, val: TValue)
10:32:46	zahary	I didn't quite follow the last remarks
10:33:01	zahary	I get your frustration with overspecified requirements
10:33:18	zahary	but you don't want to repeat them on each proc I think
10:34:22	Araq	yeah that was my point
10:34:34	Araq	well my original idea was to have:
10:34:56	Araq	proc put(t: TTable, key: TKey, val: TValue) # compile recognizes generic type TTable
10:35:01	Araq	*compiler
10:35:02	zahary	if the HashKey type class lists everything needed with proper error messages, then the distinct type solution is clean enough - you create a new borrowAll key type with hash and equals overridden
10:35:44	Araq	and so inserts [Tkey, TValue]{eq, hash} in the param list
10:36:14	Araq	and I prefer {eq, hash} over the distinct type solution tbh
10:37:57	Araq	however I don't know at all how that {list_of_symbols_here} syntax works out with more complex generics
10:39:00	zahary	but then you need a whole new set of semantics for specifying which symbols will be captured (and from which scope, etc) - you are much closer to the abandoned C++ concepts effors
10:39:42	zahary	what worries me personally is that even these (both distinct types and {hash, equals}) are not enough to capture all use cases
10:40:07	Araq	why? {hash, equals} capture all use cases for me
10:44:07	*	zahary quit (Ping timeout: 240 seconds)
10:46:26	*	Trix[a]r_za is now known as Trixar_za
10:57:48	dom96	hello
10:59:59	Araq	hi dom96
11:04:20	*	q66 joined #nimrod
11:18:34	*	Trixar_za is now known as Trix[a]r_za
11:27:37	*	Boscop quit (Disconnected by services)
11:27:38	*	Boscop joined #nimrod
11:57:11	*	Boscop quit (Disconnected by services)
11:57:13	*	Boscop joined #nimrod
12:57:26	*	Boscop quit (Disconnected by services)
12:57:28	*	Boscop joined #nimrod
13:07:21	*	Boscop quit (Disconnected by services)
13:07:22	*	Boscop joined #nimrod
13:52:46	*	zahary joined #nimrod
13:54:00	Araq	wb zahary
13:54:33	zahary	sorry, I have connection issues today
13:54:45	Araq	np
13:58:33	Araq	so, I wonder how explicit symbol binding like {`+`, `-`, `/`} etc. would scale for generic numerical code
14:05:57	zahary	sounds painful if you have to specify it everywhere in order to solve the not so common problem of per-client customization of generics
14:06:48	Araq	well as I said it would be bound to the generic type and infered
14:07:35	*	Boscop quit (Disconnected by services)
14:07:37	*	Boscop joined #nimrod
14:07:51	zahary	so, you walk over all usages and implicitly bind any used procs?
14:08:48	zahary	where is the point where it gets different from the current design?
14:19:45	zahary	also, it's not clear to me what happens when multiple generic types are involved:
14:19:46	zahary	if I have a proc that depends on a generic like AreIntersected (accepting shape types such as lines, circles, rectangles, etc)
14:19:46	zahary	proc GeometricAlgorithm(a, b: Shape) =
14:19:46	zahary	…
14:19:46	zahary	if AreIntersected(a, b): …
14:19:46	zahary	will the correct AreIntersected overload somehow be bound to the pair of types?
14:19:47	zahary	also, the "interface" of a type have to be open after the type is defined, because it's not possible to know upfront all the generic operations that would be defined over it
14:21:03	zahary	why do you dislike distinct btw? it adds exactly one line to the program
14:26:25	Araq	hrm, I'd simply use a union of type params and symbol lists for muiltiple generic types
14:26:27	Araq	brb
14:33:54	Araq	well you may want to check how it's currently done:
14:34:19	Araq	there is a pass over the generic's body that captures symbols
14:34:43	Araq	which has issues because it resolves templates and macros
14:35:03	Araq	to gain information about possibly injected symbols
14:35:33	Araq	and you can use 'bind' to close over a set of symbols so that helper procs can't be redefined
14:35:45	Araq	accidently in client code
14:36:33	Araq	it's really quite like the pass that is now done over a template's body except that for templates we don't invoke templates/macros
14:37:09	Araq	and it's the wrong default, it should 'bind' every symbol that's not explicitely declared "open"
14:37:38	Araq	the open symbols are exactly which should turn up in my proposed {symbol_list}
14:37:56	Araq	as they are part of the interface of a generic proc
14:39:22	Araq	we can't really resolve templates/macros in a generic body anymore btw because they are now part in overloading resolution
14:39:33	Araq	we can only do that for immediate macros
14:40:00	Araq	or for macros with 0 parameters for compatibility with tables.nim etc.
14:44:03	Araq	it's really messy and needs to be fixed ...
14:45:19	zahary	and this pass is not equivalent to just calling semStmt on the generic body?
14:46:52	Araq	yes it's not
14:46:55	zahary	you say "open is the wrong default, because the client can accidentally have a symbol with the same signature as what would have been bound if bind was the default"
14:47:02	zahary	but that should produce ambiguity error, no?
14:47:20	Araq	true
14:48:31	Araq	I played with the code a bit and it turned into an ambiguity error for 'nextTry'
14:48:50	Araq	as both astalgo.nim and tables.nim have that
14:49:41	Araq	in fact the current implementation turns an nkOpenSymChoice of length 1 into the concrete symbol
14:49:54	Araq	so that 'nextTry' is bound
14:50:27	Araq	if 'nextTry' in tables.nim would have been overloaded it fails
14:50:49	Araq	it works by chance :-)
14:51:06	Araq	as nextTry is not overloaded but == and 'hash' are
14:51:23	zahary	it seems to me that explicitly stating open symbols falls into the realm of what I call "babysitting the compiler" - most of the time my intentions are obvious from the code and if the accident happens, there is still the safety net provided by the ambiguity error
14:52:22	zahary	what is nextTry problematic here?
14:52:57	Araq	it's the code that made me realize how broken the compiler is IMO
14:53:18	zahary	but what will happen if I provide a local overload?
14:53:30	Araq	ambiguity error
14:53:44	Araq	the problem is however not a "local" overload
14:54:12	Araq	import tables, astalgo # assume astalgo has a public 'nextTry' too
14:54:40	Araq	t["key"] # wtf? ambuity error for 'nextTry'?
14:54:47	zahary	I see
14:55:35	zahary	but this doesn't get fixed under any regime - your {boundSymbol} have the same problem?
14:55:51	zahary	there would be less such symbols, that's your point?
14:55:58	Araq	now of course tables.nim could use 'bind nextTry' to get around the problem
14:56:32	Araq	{boundSymbol} don't have the problem because it's now explicit
14:56:50	Araq	the problem is that open per default, closed via 'bind' is wrong
14:57:00	zahary	the old closeness rule could kick in here - the tables module's scope is closer to the user's scope, so its implementation for nextTry is picked up
14:57:21	Araq	it should be closed per default and open explicitely
14:57:29	Araq	either via {boundSymbol}
14:57:33	Araq	or via:
14:57:51	Araq	mixin symbolA, symbolB
14:58:31	Araq	but yeah the old closeness rule would work too and would be consistent with template overriding, right?
15:02:12	zahary	even if I agree about the open vs closed question, I guess this is not what worries me. open vs closed affects lexical scoping and symbol resolution in the code - what's not clear to me is how bound symbols become part of the generic type when it comes to the instantiation cache
15:03:13	zahary	are the bound symbols examined on a per-proc level or on a per-type level?
15:03:40	Araq	currently they are not examined at all
15:03:48	zahary	alright, but what's the plan?
15:03:52	Araq	but in my mind they would be per-proc level
15:04:04	zahary	ok, that's better - I imagine how it can work that way
15:04:26	zahary	each proc is only concerned with the symbols it actually used
15:08:08	*	Boscop quit (Disconnected by services)
15:08:10	*	Boscop joined #nimrod
15:08:30	zahary	my vote would go for a mixin statement that could be used both at top level and inside a proc
15:09:07	Araq	I'm thinking about merging type params and symbol params as I think [T, S]{symA, symB} is a bit overkill
15:09:22	Araq	making it exactly like C++'s <> I think
15:09:31	zahary	hmm, but bound symbols are not part of the type I think
15:09:42	Araq	yeah I dunno
15:09:50	Araq	it's wrong to mix up types and symbols
15:10:14	zahary	instead the cache criteria looks like this - generic types: T = string, U = seq[int], bound procs = user.hash, user.equals
15:10:28	zahary	and that's on a proc level
15:10:52	zahary	this can work for my AreIntersected example
15:11:04	Araq	but the bound symbols need to be attached to the type so that {eq, hash} does not need to be repeated again and again
15:11:22	Araq	but hrm that would be your module wide 'mixin' statement, right?
15:11:40	zahary	that's why I propose that you just write once at top level in the module
15:11:40	zahary	mixin hash, equals
15:11:57	zahary	ah, you beat me to it :)
15:12:20	Araq	I always had the idea of:
15:12:28	Araq	generic [TKey, TValue]:
15:12:37	Araq	# lots of generic code here
15:13:14	Araq	to avoid the excessive type lists that plague the current design
15:13:25	Araq	it's easy to generalize to:
15:13:41	Araq	generic [TKey, TValue]{eq = `==`, hash}:
15:13:50	Araq	('generic' is a keyword)
15:14:20	zahary	lots of generic code - you mean lots of procs?
15:14:38	Araq	and types
15:14:54	zahary	what about my shorthand syntax:
15:14:54	zahary	proc get(t: TTable, k: TTable.key) =
15:15:04	zahary	not a lot of types here
15:15:43	Araq	well excuse me, it's the first time you showed me that syntax ;-)
15:16:09	zahary	that's the implicit generics? you haven't seen the TTable.Key part probably?
15:16:57	zahary	when you have type = TTable[Key: Hashable, Value] - you can use Key and Value later as nested types
15:18:23	Araq	I see
15:20:01	Araq	how does that all work out with:
15:20:13	Araq	proc get(t, k) = ...
15:20:19	Araq	?
15:20:37	zahary	well, that just get[T, U](t: T, k: U)
15:20:50	zahary	no any interdependencies here
15:21:19	Araq	hm
15:21:31	zahary	get(t: Table, k: Table.Key) will be different
15:21:31	zahary	get[T](t: Table[T], k: T)
15:22:16	Araq	I suppose 'proc get(t,k)' is useful only if it's not exported
15:23:58	zahary	yes - when you are lazy
15:29:07	Araq	well hrm so we agree 'bind' should be the default and 'mixin' be explicit (somehow)?
15:29:44	zahary	yes, I can see your point there
15:32:17	zahary	but's since it's symbol lookup thing (which is connected to lexical scoping), I think the mechanisms to control it should be concerned with scopes, not types (i.e. similar to the bind statement)
15:34:41	Araq	oh well for a start, an unknown symbol should trigger a compilation error :D
15:35:10	Araq	currently an unknown symbol in a generic is no error ...
15:35:20	Araq	I think
15:35:44	zahary	hu? can't imagine how that works :)
15:36:08	Araq	it's an nkIdent that will be looked up at instantiation time I think
15:36:34	zahary	ah, you mean the error will be produced later
15:36:54	Araq	yeah
15:37:34	Araq	hrm I like this {} stuff:
15:37:58	Araq	sort{cmp}(a) # no need for a proc var now
15:38:44	zahary	well, this is a code bloat decision - generics vs run-time dynamism
15:39:04	zahary	you could have had sort(a) right now too
15:40:22	Araq	true
15:41:43	Araq	now some different topic: about constructors
15:42:11	zahary	gotta go btw, we should leave it for tommorow
15:42:23	Araq	well I now think a constructor is a nullary function
15:42:34	Araq	so that reserveSpace(mySeq, 10)
15:42:41	Araq	can construct the elements
15:42:56	Araq	and 'var v: T' continues to work
15:43:07	Araq	think about it ;-)
15:43:11	zahary	nullary? you mean it never accepts arguments?
15:43:16	Araq	yeah
15:43:23	zahary	what's wrong with C++ default constructors?
15:43:32	Araq	nothing
15:43:40	Araq	but it's the only *constructor* there is
15:43:49	zahary	there just may be some types for which var v: T is not allowed
15:43:50	Araq	the other things are just weird functions
15:44:05	Araq	:P
15:44:47	zahary	I liked your previous "everything is constructor" mindset better :)
15:45:20	zahary	but if you mean - the nullary constructor is the only one where you'll use the constructor keyword/pragma - then ok, I guess that's right
15:48:03	zahary	another topic that I haven't mentioned in a while is placement constructors - or rather in-place construction of the return value of any proc
15:48:04	zahary	mem = alloc(sizeof(T))
15:48:04	zahary	mem <-- someProcReturningT()
15:49:44	Araq	well we can talk tomorrow, but only I won't have much time tomorrow
15:55:59	zahary	I'll be more frequently around next week
15:56:14	zahary	I'm still recovering from my vacation habits - bye for now :)
15:57:31	*	zahary quit (Quit: Leaving.)
16:08:23	*	Boscop quit (Disconnected by services)
16:08:25	*	Boscop joined #nimrod
16:36:00	*	shevy quit (Ping timeout: 252 seconds)
16:48:18	*	shevy joined #nimrod
17:05:42	reactormonk	Araq: what if I need a random float?
17:31:19	shevy	I shall give you 42.0 !
17:54:55	dom96	We should just hire humans to randomly generate numbers for us :P
18:03:45	shevy	hehe
18:05:28	reactormonk	they will suck
18:05:47	reactormonk	which might be good or bad, depending on who you hire
18:06:26	reactormonk	I suppose you know the part where humans can't generate random numbers
18:58:52	reactormonk	/join lisp
19:24:30	shevy	/join #pls-dont
19:26:25	*	mal``` quit (Ping timeout: 265 seconds)
19:26:34	reactormonk	shevy: had a space left in the buffer :-P
20:05:42	*	mal`` joined #nimrod
20:53:28	Araq	reactormonk: find and wrap the C proc that does it
20:59:35	fowl	Araq: i wrote template filterIt(seq, cond: expr; body: stmt): stmt but its clashing with the one from sequtils that only takes two args
21:00:19	Araq	I'm working on overloading resolution for templates that take a 'stmt' as last param
21:00:45	Araq	it's very easy to do, but term rewriting macros are much more fun :P
21:01:04	fowl	ah
21:01:16	Araq	for now you can simply do:
21:01:26	Araq	from sequtils import the_others_I_need
21:01:29	Araq	right?
21:01:54	fowl	i didnt need anyhting from sequtils at the moment i just didnt want it to clash
21:02:10	Araq	alright
21:02:29	fowl	im going to start compiling useful scripts and examples on gist.github
21:03:33	Araq	I consider TR macros Nimrod's killer feature btw
21:03:52	Araq	you simply can't do what they enable in C++ or D
21:04:18	Araq	and most Lisps don't come close either
21:05:51	fowl	I was going to do a STFL wrapper
21:06:00	fowl	but i dont feel like doing a wrapper for wchar >_>
21:06:18	Araq	there already is a wrapper for wchar
21:06:24	Araq	but it's hidden :P
21:06:39	Araq	I needed that for nimrod's unicode support on windows
21:06:52	fowl	o
21:08:38	fowl	so its only in windows.nim?
21:08:45	Araq	no
21:08:52	Araq	still searching, wait a sec
21:09:57	fowl	cast[LPTSTR](cast[ULONG_PTR](ToU16(i)))
21:10:04	fowl	im starting to regret opening windows.nim
21:10:19	Araq	don't use windows.nim
21:10:23	Araq	use winlean.nim
21:10:38	Araq	and copy what's really needed from windows.nim to something else
21:10:56	Araq	windows.nim is a disease
21:12:07	Araq	finally found it
21:12:15	Araq	it's in lib/system/widestrs.nim
21:12:22	Araq	and already exported for you:
21:12:31	Araq	allocWideString
21:13:08	fowl	aha cool
21:13:44	Araq	and yeah you need to dealloc the string
21:13:49	Araq	no GC for it :P
21:16:01	Araq	looking at the code it's not windows specific
21:16:16	Araq	but it assumes wchar_t == utf-16
21:16:25	Araq	which is wrong on linux I guess :-/
21:17:10	fowl	i cant find wchar_t wchar.h says to look in stddef.h but i dont have it
21:29:20	fowl	is there wrappers for langinfo.h and locale.h? :D
21:29:35	Araq	no and I don't want them
21:29:42	Araq	locale.h is braindead
21:30:32	Araq	strtod("1.3") # what do you mean, it depends on the locale? o.O
21:30:59	Araq	how am I supposed to use that for parsing numbers in a configuration file then?
21:31:18	Araq	oh right, you can hack around it with setlocale
21:31:25	Araq	oh wait, that's not threadsafe ...
21:31:44	Araq	locale dependency is a bug, not a feature
21:32:06	Araq	especially in an otherwise barebones stdlib
21:33:11	fowl	stfl is too much work then
21:33:23	Araq	why?
21:33:35	Araq	what has it to do with locale.h anyway?
21:36:06	Araq	and don't get me wrong, you can of course wrap locale.h and langinfo.h
21:36:25	Araq	I don't really want them in the stdlib though
21:36:52	fowl	stfl needs it to initialize http://svn.clifford.at/stfl/trunk/example.c
21:37:26	Araq	omg
21:37:39	Araq	lol
21:37:44	Araq	"STFL is a library which implements a curses-based widget set for text terminals. The STFL API can be used from C, SPL, Python, Perl and Ruby. Since the API is only 14 simple function calls big and there are already generic SWIG bindings it is very easy to port STFL to additional scripting languages. "
21:37:54	Araq	only 14 simple function calls
21:37:58	Araq	that's good
21:38:38	Araq	it would be better if those 14 function calls wouldn't use obscure C features like langinfo and wide strings ...
21:39:11	fowl	yea it translated over with no issues https://gist.github.com/3559478
21:39:37	fowl	yes damn near every function takes widestring
21:40:39	Araq	does stfl work on windows?
21:40:56	Araq	there are also ncurses wrappers somewhere
21:41:11	fowl	i dont think so
21:43:01	Araq	lib/wrappers/pdcurses.nim
21:43:10	Araq	but it needs a cleanup
21:54:25	fowl	is ncurses the same thing as pdcurses?
21:55:37	Araq	pdcurses is the portable version of it
21:55:43	Araq	with minor api changes I think
21:56:22	fowl	ok ill check it out in a few mins