<<22-09-2012>>

---

00:40:27	*	q66 quit (Quit: Quit)
01:49:11	*	Boscop quit (Disconnected by services)
01:49:13	*	Boscop joined #nimrod
01:53:34	*	Boscop quit (Disconnected by services)
01:53:39	*	Boscop joined #nimrod
04:47:38	*	Trix[a]r_za is now known as Trixar_za
06:32:57	*	Trixar_za is now known as Trix[a]r_za
07:18:55	*	XAMPP quit (Ping timeout: 252 seconds)
10:00:26	*	q66 joined #nimrod
10:57:13	dom96	I think continuations would really help working with ftpclient.
11:00:27	*	zahary joined #nimrod
11:39:04	*	Trix[a]r_za is now known as Trixar_za
12:05:23	*	Trixar_za is now known as Trix[a]r_za
13:24:53	*	exhu_ joined #nimrod
13:25:41	exhu_	Hi there! does anyone know what is the "interface" keyword in nimrod for?
14:17:03	fowl	exhu_: i think its just reserved at the momnet
14:17:09	Araq	hi exhu_
14:17:20	Araq	I reserved it for future growth
14:18:06	exhu_	is it related to OOP?
14:18:25	Araq	yes
14:18:43	exhu_	nice -)
14:20:48	Araq	well currently my plan is to make interface[...] the same as a tuple of closures but the environment will be shared
14:24:33	Araq	I also want to support proc p[T: myInterface](x: T) ...
14:26:00	Araq	dom96: you could use continuation passing style as a workaround ;-)
14:27:12	dom96	Araq: mmm
14:29:28	dom96	I would like a nice way to express the build process in nimbuild.
14:29:36	dom96	Something like:
14:29:51	dom96	exec "git pull"
14:30:24	dom96	if existsFile("csources.zip"): exec "unzip csources.zip"
14:30:33	dom96	exec "nimrod c koch"
14:30:36	dom96	.. etc
14:30:42	Araq	well?
14:30:43	dom96	But it should be asynchronous.
14:30:46	Araq	aha
14:30:54	Araq	use a macro
14:31:02	dom96	Yeah, that's my plan :)
14:31:26	dom96	Currently I have a big enum :P
14:31:40	dom96	Which gets very confusing, because steps can be skipped etc.
14:39:17	shevy	my enum is bigger than yours!
14:47:25	Araq	really? how is that more confusing than any web app?
14:47:40	Araq	it's a state machine in any case ...
14:48:37	fowl	dom96: use nake ;)
14:49:27	dom96	I might :P
15:01:39	Araq	dom96: instead of async io you could also use threads
15:01:57	dom96	Would that really make the job easier?
15:02:23	Araq	sure why not?
15:03:23	Araq	do the blocking call in a worker thread
15:04:03	dom96	hrm, yeah. That will probably work.
15:17:55	Araq	exhu_: any experience with Nimrod's templates?
15:19:32	Araq	I still wonder if .immediate shouldn't be the default for them
15:22:16	exhu_	Araq, tried to apply c++ experience using generics. Still not sure what the proper way is to implement similar stuff using Nimrod.
15:23:06	Araq	well Nimrod's templates have nothing to do with C++'s ...
15:23:23	*	zahary quit (Quit: Leaving.)
15:25:13	exhu_	I can tell that macros being very effective and advanced stuff are too hard to write.
15:28:37	Araq	a 'template' is a way to construct an AST in a declarative way
15:28:58	Araq	you can use them to do quasiquoting in macros
15:31:35	exhu_	yes, but i could not manage to use templates to pass a variable declarations block, that's why had to use a macro.
15:36:05	fowl	you have to use {.dirty.} on the template or {.inject.} each var
15:41:58	exhu_	I've just looked into http://build.nimrod-code.org/docs/manual.html and think more examples with comments needed there in the templates section.
15:42:25	Araq	true but then what should my book contain? :D
15:42:39	exhu_	ha-ha -)
15:46:32	exhu_	wish I lived in the western world because it's pain to get any books here unless some colleagues travell to US or Germany for duty jorney.
15:50:46	Araq	so where are you from?
15:51:56	exhu_	belarus
15:52:19	exhu_	between poland and russia
15:52:35	Araq	yeah just looked it up ;-)
15:53:04	Araq	didn't know belarus means weißrussland
15:53:59	exhu_	ok, so you are from germany? -)
15:54:12	Araq	yes
15:55:49	exhu_	i was learning the german language 5 yrs ago. the new books used Belarus, the older ones -- Weissrussland.
15:56:57	Araq	yeah quite possible, I read "Belarus" is now often used officially
15:57:09	dom96	oh hey exhu_. I'm originally from Poland but live in Ireland :)
15:57:47	exhu_	dom96, czesc -) learned some polish about 7 yrs ago -)))
15:58:26	dom96	exhu_: Dzieńdobry przyjacielu :)
15:58:30	dom96	exhu_: Cool cool
16:03:15	*	zahary joined #nimrod
16:28:01	Araq	dom96: please make that "output/error list" bottom window optional for the next release
16:28:12	Araq	it takes up lots of valuable screen space ...
16:28:31	dom96	huh?
16:28:41	dom96	You don't want it to show up when you hit F5?
16:28:57	Araq	it shows up permanently for me
16:29:10	Araq	omg
16:29:15	Araq	I feel stupid
16:29:16	Araq	sorry
16:29:18	dom96	lol
16:29:41	dom96	You can hide it with Ctrl + Shift + B :P
16:29:54	Araq	hey I didn't expect "View" to actually contain useful icons :P
16:30:07	dom96	;)
16:34:41	dom96	hrm, I just thought of another feature for Nimbuild :P
16:34:56	dom96	Cross-platform/architecture test result comparisons on a single page.
16:35:16	dom96	Too much work :P
16:38:03	Araq	but it would be very useful
16:38:20	dom96	oh, so you do like that idea.
16:39:39	*	zahary quit (Read error: Operation timed out)
16:39:47	*	zahary joined #nimrod
16:40:01	*	shevy quit (Ping timeout: 260 seconds)
16:40:36	exhu_	what is nimbuild?
16:42:04	dom96	It's a build farm; a website which builds nimrod, tests it on multiple platforms and displays the results.
16:52:37	*	shevy joined #nimrod
16:59:24	*	zahary quit (Ping timeout: 246 seconds)
16:59:33	*	zahary joined #nimrod
17:22:04	Araq	ping zahary
17:23:24	zahary	pong Araq
17:23:41	Araq	what's the status of 'auto' as return type?
17:23:55	zahary	nothing new there
17:24:07	Araq	what was the status? I'm working on: proc p: int = 34
17:24:28	Araq	aka "implicit return" for proc bodies
17:25:04	*	exhu_ quit (Quit: Ex-Chat)
17:28:17	zahary	nothing about it is implemented yet - we have talked about how proc foo[T](a, b: T): type(a+b) cannot work, because the compiler tries to determine the return type too early in the pipeline
17:28:45	Araq	but ': auto' can work easily
17:28:58	Araq	and 'type(a+b)' is redundant anyway
17:29:17	zahary	yep
17:30:30	zahary	the implicit return will be limited to single expressions or it will just look at the last expression in each code path?
17:31:49	Araq	well it will look if the body has a type and if so transform it to 'result = body'
17:32:20	Araq	and then once 'case' supports types this will be supported automatically
17:32:36	Araq	I mean it will be done incrementally
17:33:00	Araq	'case'/if are the obvious next candidates for expr support
17:34:03	zahary	so the body must be a single expression?
17:35:36	Araq	yeah
17:35:51	Araq	but nkStmtListExpr is also a "single" expression ;-)
17:40:01	zahary	I'm asking about the style you prefer - some languages choose "last expression in the body", others "body must be single expression"
17:40:48	Araq	it's "last expression in the body" then I guess
17:41:26	zahary	ok, me too :)
17:42:41	Araq	another minor problem: binding `[]=` doesn't work due to a bug currently
17:43:15	Araq	but templates will default to 'bind' soon and there is a 'mixin' statement for open symbols
17:44:07	Araq	however this cannot work for: x[i] = y
17:44:16	Araq	well it can work I guess
17:44:24	zahary	why so?
17:44:30	Araq	but it's a special case
17:44:46	Araq	we have no types when processing a template's body
17:45:10	Araq	so whenever it encounters a[i] it needs to bind `[]`
17:45:37	Araq	(a[i] is still nkBracketExpr)
17:45:49	zahary	aha, it's not clear whether you mean (a[]) = or a([]=)
17:46:02	Araq	yeah
17:46:21	Araq	so for nkAsgn(nkBrackeExpr ...) it needs to bind `[]`, `[]=`
17:46:36	zahary	I noticed that you want to support better the C++ style of return var from the [] indexer
17:47:00	Araq	yes
17:47:11	zahary	it's a good idea I think, because there are some situations where []= doesn't compose well
17:47:21	Araq	indeed
17:47:28	zahary	for example, say I want to pass some element to a var taking function
17:47:40	zahary	modify(a[10])
17:47:48	zahary	doesn't work with []=
17:48:00	Araq	it does with a special rule:
17:48:17	Araq	var tmp = a[10]; modify(tmp); a[10] = tmp
17:48:27	Araq	C# does that afaik
17:48:58	Araq	when passing a get/set property to a 'ref' parameter
17:49:11	zahary	nice workaround, but still doesn't work for non-copyable type
17:49:51	Araq	I think there is no such thing as a "non-copyable" type in this context
17:49:58	Araq	raw bit copy should do
17:50:10	zahary	another good idea is to have the clay's "forward" type
17:51:00	zahary	instead of writing two functions - one taking var and returning var and one non-var, have a single function written to use the forward type
17:51:55	Araq	I always wanted to use templates for forwarding
17:52:18	Araq	and I think they work good enough there
17:52:35	Araq	except for visibility rules
17:52:48	zahary	what do you mean? have the implementation in a template that is used in both functions?
17:53:24	Araq	template myProperty(x: TMyObject): int = x[0].prop
17:53:53	Araq	due to the inlining semantics it's like a 'var int'
17:54:57	zahary	hmm, what about the forwarding optimisations we have talked about?
17:55:39	Araq	how do they apply here?
17:56:44	Araq	template `myProperty=` (x: TMyObject, y: someType{call}) = shallowCopy(x[0].prop, y)
17:57:02	zahary	sorry, I was afk for a moment. I got what you mean
17:58:07	zahary	maybe that solution is good enough indeed - it's rare that such duplicated accessors are long functions
17:58:40	Araq	accessors shouldn't be long functions
17:59:13	Araq	but you can do things like longFunction(x)[] # returns a 'ptr'
17:59:22	zahary	well, container acessors will implement some algorithm
17:59:37	zahary	so they can be longer, but still rare case
18:00:11	Araq	yeah but they can easily delegate to a "real" function
18:01:44	zahary	well, we are talking about conveniences here - in C++ you just use const_cast after all - 1 line of code
18:02:38	fowl	are there plans to make var and ptr types compatible
18:02:53	Araq	fowl: indeed there are
18:03:20	fowl	cool
19:55:19	Araq	zahary: did you read my thoughts about improving nimrod's message passing?
20:00:38	zahary	where can I read them?
20:01:05	Araq	http://build.nimrod-code.org/irclogs/21-09-2012.html
20:01:24	Araq	from 18:27
20:04:47	zahary	the read-onliness of the messages is reasonable assumption
20:05:39	Araq	the effect system tracks writes per type
20:05:57	Araq	and I want 'distinct {.noalias.}'
20:06:27	Araq	so you can write in a task, but the types must be distinct
20:07:14	Araq	it's easy to do better and indeed the thread heap analysis already does so :D
20:07:17	zahary	very long term, it would be nice if nimrod gets some of the features of spec# (the singularity OS compiler) - the effect tracking you describe here is what's needed there for the super-efficient IPC mechanism
20:07:57	Araq	but the thread heap analysis a whole program analysis
20:08:04	Araq	*is a
20:08:44	Araq	basically it annotates expressions/paths/locations with a heap region
20:09:22	Araq	but these things cry for formal proofs of correctness :D
20:09:29	zahary	well, how much harder becomes the problem of tracking effects if it's per locations?
20:09:41	Araq	we'll see ;-)
20:10:03	Araq	but it can't be done locally anymore then
20:10:29	Araq	as a proc's body is polymorphic wrt a heap region
20:11:00	zahary	I guess I must see the tracking per type in action - I can't really imagine how often I will be burned by it
20:11:29	Araq	ha, me neither
20:12:01	Araq	but using specialized TMsg types may help
20:17:59	Araq	btw I'm also working on a new grammar/parser
20:18:43	Araq	the current indentation handling is quite complicated because I cared about a formal LL(1) grammar
20:19:23	*	Trix[a]r_za is now known as Trixar_za
20:19:25	Araq	I'm quite sure it's not LL(1) anymore so I want to do it differently
20:20:11	Araq	I don't care about a traditional grammar anymore, instead the spec will use a PEG
20:20:48	Araq	and the pseudo tokens IND, SAD and DED will become IND(x)
20:20:59	Araq	denoting an indentation of 'x' spaces
20:25:00	Araq	however I'm struggling with the notation a bit:
20:25:06	Araq	stmt ::= singleStmt
20:25:08	Araq	| IND{x} singleStmt (IND(x) singleStmt)*
20:26:03	Araq	IND{x} means "if there is indentation > then the tos (top of indentation stack), then bind the number of spaces to 'x'"
20:26:25	Araq	and IND(x) means: "if there is an indentation with the same number of spaces as in 'x' "
20:27:18	Araq	but the grammar rules become tedious because you have:
20:27:40	Araq	IND{x} ruleA (IND(x) ruleA)*
20:27:59	*	XAMPP joined #nimrod
20:28:12	Araq	so you have to write ruleA twice
20:31:11	Araq	I guess I can simply define an ** operator so it becomes:
20:31:16	Araq	ruleA**
20:33:18	*	Trixar_za is now known as Trix[a]r_za
20:33:57	Araq	any opinions?
21:08:59	zahary	is your question about the documentation or about the implementation?
21:09:30	zahary	are you planning to throw away the recursive-descent parser?
21:12:10	zahary	I personally don't care about formal definitions of the grammar. These are useful only for languages with proprietary implementations where you expect other vendors to provide their own implementation for their OSes, etc
21:13:44	zahary	I don't care about PEGs much either, because modifying the recursive parser is one of the easier tasks in compiler hacking
21:18:18	zahary	that said, what kind of changes in the syntax are you planning? that's more interesting question
21:23:22	Araq	my question is about the documentation
21:23:42	Araq	the implementation stays a recursive descent parser
21:23:54	Araq	it should get a bit easier though ;-)
21:24:30	Araq	planned syntactic changes are minor
21:24:37	Araq	I want to allow:
21:24:42	Araq	proc p()
21:24:49	Araq	{.pragmas_here.}
21:25:09	Araq	and change the comment handling
21:25:32	Araq	oh and I want to specify the AST with each grammar rule
21:26:01	zahary	dumpTree is the spec I currently use :)
21:26:12	Araq	I know ;-)
21:27:34	zahary	well, if it's just about the documentation I guess adopting pegs could backfire, because from my experience very few developers know them well
21:30:03	Araq	I misuse the term PEG for "deterministic grammar" :D
21:30:21	Araq	which is what most devs have in mind anyway
21:30:30	zahary	aha, I see
21:30:45	Araq	s ::= 'if' s | expr
21:30:57	Araq	expr ::= ..... | 'if' expr ...
21:30:58	zahary	well adopt some custom notations then - shorter grammars are easier to read
21:31:20	Araq	is ambiguous but nobody notices ;-)
21:31:35	Araq	because | is read as / (ordered choice)
21:32:03	zahary	yeah, I got it
21:32:42	Araq	and yeah we need custom notations anyway as traditional notation cannot deal with an indentation based grammar
21:33:57	Araq	btw traditional notation sucks; it doesn't support parametrized rules
21:34:18	Araq	nor anything that can be done in a real parser with higher order functions
21:34:52	Araq	it can easily be more verbose than an implementation
21:35:06	zahary	I've studied more than 50 languages probably and I never find myself reading the formal grammar
21:36:11	Araq	true but if you don't have a formal grammar, you quickly don't know what the parser actually implements
21:36:32	Araq	in fact, that always happens if you don't use a parser generator
21:37:51	Araq	recursive decent is "simple" to implement until you notice that you need to compute first and follow sets in your mind
21:38:11	zahary	what is the meaning of "know" here? I can correctly imagine what is possible within the grammar?
21:38:26	Araq	and nobody does that properly
21:38:52	Araq	you can imagine what's possible, true
21:39:03	Araq	but you'll get it wrong what shouldn't be allowed
21:39:15	zahary	no, I was going to say that the formal grammar doesn't help you in that regard really
21:39:27	Araq	I think it does
21:39:41	Araq	well if you use a tool for it
21:39:53	Araq	otherwise not really, that's true
21:40:26	zahary	can you tell me for example just looking at the grammar why it's not possible foo: block to be expression in nimrod?
21:41:51	Araq	exprStmt ::= lowestExpr ['=' expr | [expr (comma expr)*] [macroStmt]]
21:41:59	Araq	macroStmt ::= ':' [stmt] ('of' [exprList] ':' stmt
21:42:01	Araq	|'elif' expr ':' stmt
21:42:02	Araq	|'except' exceptList ':' stmt )*
21:42:04	Araq	['else' ':' stmt]
21:42:33	Araq	blockStmt ::= 'block' [symbol] ':' stmt
21:42:41	Araq	so yeah, I can :P
21:42:54	Araq	'block' is always followed by a colon
21:45:36	zahary	I meant code block, not the block keyword (are you referring to this?)
21:45:56	Araq	oh I see
21:46:34	Araq	well foo: blck is an expression soon, but I get your point
21:47:01	Araq	but you can figure this stuff out by studying the grammar
21:47:13	zahary	nah, I tried to implement it once - it cannot work in the general case
21:47:37	zahary	if foo:
21:47:37	zahary	block
21:48:02	Araq	it's ambiguous then, yes
21:49:04	Araq	but we could make the ':' optional for passing a block and then this would work:
21:49:07	Araq	if foo
21:49:10	Araq	block:
21:49:29	Araq	which was your idea iirc
21:50:02	Araq	but that doesn't really work either:
21:50:19	Araq	m foo
21:50:21	Araq	block
21:50:34	Araq	is 'block' passed to 'foo' or to 'm'?
21:53:47	zahary	in my hypolang, this will be call to m with 2 params - I had to adopt the haskell $ operator to get the other meaning
22:26:40	*	Trix[a]r_za is now known as Trixar_za
22:58:48	Araq	sorry, dom96, no capturing of 'result'
22:59:01	Araq	would require special logic in the backend :P
22:59:17	dom96	np
22:59:21	dom96	easy enough to workaround
22:59:41	Araq	yeah and I did it for tirc
23:00:59	dom96	thanks
23:23:16	*	zahary quit (Quit: Leaving.)