00:04:50 -!- puzzlet has quit (Read error: 104 (Connection reset by peer)).
00:05:02 -!- puzzlet has joined.
00:07:18 -!- Corun_ has quit ("This computer has gone to sleep").
00:08:18 -!- pgimeno has left (?).
00:09:33 -!- Corun has joined.
00:22:36 -!- RockerMONO[enfr] has changed nick to RockerMONO.
00:31:40 -!- immibis has joined.
00:44:40 -!- dbc has quit (Client Quit).
01:08:55 -!- ehird_ has joined.
01:09:30 -!- ehird has left (?).
01:09:44 -!- ehird_ has changed nick to ehird.
01:17:35 -!- Corun has quit ("This computer has gone to sleep").
01:26:28 -!- immibis_ has joined.
01:26:43 -!- immibis_ has quit (Read error: 104 (Connection reset by peer)).
01:37:50 -!- ehird has quit ("This computer has gone to sleep").
02:19:57 * RockerMONO made an irc bot in brainfuck (using my interpreter that has networking) that can parse brainfuck
02:26:06 -!- immibis has left (?).
02:37:30 -!- RockerMONO has changed nick to Rocker[box].
03:24:40 <GregorR> You shouldn't need an interpreter with networking, just netcat :P
03:25:00 <GregorR> That being said: Really? An IRC bot written IN BF that INTERPRETS BF? That's pretty cool.
03:27:35 <GregorR> This isn't relevant, but it's insanely awesome: http://www.nongnu.org/sps/
03:28:36 <pikhq> You did more stuff to it.
03:28:39 <pikhq> That's damned awesome.
03:30:21 <GregorR> I didn't just do more to it, I rewrote it from scratch as a FUSE filesystem utilizing Debian packages.
03:48:22 -!- Insane has joined.
03:48:39 <Insane> Somebody do me a favor and randomly link me to a fun language
03:49:04 <pikhq> ERROR: I DON'T WANNA.
03:49:23 <Insane> Let's invent ERRORCODE
03:49:37 <pikhq> What, where everything is a Kimian quine?
03:49:37 <Insane> you program in error messages
03:50:07 <Insane> What's a kimian quine?
03:50:53 <pikhq> A quine which depends upon the error reporting facilities of a language.
03:51:11 <pikhq> In some BF interpreters, "Mismatched ]." is a Kimian quine.
04:10:42 -!- adu has joined.
04:15:51 <RodgerTheGreat> could somebody explain a "Kimian quine" to me? I've heard this obscure fact, but I could never find a more detailed explanation
04:16:35 <RodgerTheGreat> is the idea that mismatched brackets will output an error message containing "]" somehow?
04:19:14 <RodgerTheGreat> and Insane- your idea sounds intriguing. Like a language in which you "program" to some extent by purposely producing various types of errors?
04:19:50 <RodgerTheGreat> You'd probably want a nearly TC base language with some key features missing, and then use bizarre side effects of error messages to fill in the gaps
04:27:50 <Insane> Maybe something like dividing by zero to output memory
04:37:50 <RodgerTheGreat> if it was interpreted in some fashion you could use nullpointer exceptions and array index out of bounds violations
04:38:44 <RodgerTheGreat> there are a number of nonfatal things, like conversions that lose precision, that could fail predictably to provide rudimentary math or something
04:43:21 <pikhq> Basically, you create a program whose *error messages* are the program.
04:46:33 <Insane> Maybe you can simply "emulate" error messages
04:46:50 <GreaseMonkey> counter from 1 to 10: i = 1; LOOP { i = i + 1; peek(0); 1/(0-i); }, EXCEPT (DivZero) { BREAK; }, EXCEPT (NullRead) { ErrStr = str(i) + chr(10); COMPLAIN; CONTINUE; };
04:46:59 <Insane> eg. instead of really dividing by 0 and catching an error, you could pretend to
04:47:11 <GreaseMonkey> counter from 1 to 10: i = 1; LOOP { i = i + 1; peek(0); 1/(0-i); }, EXCEPT (DivZero) { BREAK; }, EXCEPT (NullRead) { ErrStr[NullRead] = str(i) + chr(10); COMPLAIN; CONTINUE; };
04:49:14 <GreaseMonkey> DO { 1/0; }, EXCEPT (DivZero) { DivZero = "Hello World!" + chr(10); COMPLAIN; CONTINUE; };
04:49:47 <RodgerTheGreat> this could tie into the idea we had earlier about a language where all logic, variables and flow control was a twisted mass of exception throwing and catching
04:50:04 <RodgerTheGreat> exceptions themselves formed the mechanism for storing variables
04:50:52 <RodgerTheGreat> and with some kinda nasty object oriented stuff it was possible to do recursion with them
04:51:54 <Insane> I'm still working on writing an irc bot in NetBrainFuck
04:52:08 <Insane> NetBrainFuck provides 4 more instructions
04:52:09 <RodgerTheGreat> or name it after the big iron OS "NonStop", legendary for it's reliablility
04:52:18 <Insane> connecting using data from memory, reading, writing, d
05:07:36 <Insane> Let's make SLOCODE where every instruction takes a while, forcing programmers to write efficient code or wait forever
05:11:38 -!- Insane has quit (Remote closed the connection).
05:33:38 <RodgerTheGreat> no, SLOCODE should turn conventions of cost and speed on their heads
05:34:22 <RodgerTheGreat> we could essentially accomplish this with a hideously complex "optimizer" routine
05:38:50 -!- adu has left (?).
05:45:01 <oklofok> i read somewhere that any universal lang can simulate any other efficiently, meaning running in polynomic time compared to the original prog in the other language, anyone know if this is true?
05:45:37 <oklofok> was just thinking about ais's O(2^2^n) simulation of a utm, unless i remember that wrong too
05:50:34 <oklofok> that is a bit hard to google : D
05:51:54 <RodgerTheGreat> I now challenge you to write a lisp (or scheme) interpreter for the Z1.
05:56:55 <GreaseMonkey> e.g. v++ goes to v += 0xFF; for(i=0;i<0xFF;i++) v--;
05:56:59 <oklofok> i was just thinking, in case that polynomic time is *not* true, might be interesting to try and make the slowest language ever
05:58:19 <RodgerTheGreat> the Z1 was one of the first computers, created by Konrad Zuse.
05:58:24 <oklofok> if there's no polynomic bound, you can probably make a language, in theory, that can actually be parametrized to be infinitely slow
05:58:43 <oklofok> oh, right, i was assuming that had to do with the proof :D
06:01:07 <oklofok> what i meant was a limit of infinite running time
06:01:45 <oklofok> when growing a param of the language
06:02:45 <oklofok> something like 2^2^2^...^n where you can choose the number of 2's by slightly modifying the language
06:04:54 <oklofok> since i don't think you can assume any optimization when calculating that, doesn't seem impossible really
06:33:20 -!- calamari has joined.
06:46:54 -!- calamari has quit ("Leaving").
07:36:13 -!- puzzlet has quit (Remote closed the connection).
07:36:21 -!- puzzlet has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
09:19:30 -!- GreaseMonkey has quit ("night").
09:36:06 -!- puzzlet has quit (Remote closed the connection).
09:36:14 -!- puzzlet has joined.
09:47:19 -!- sebbu has quit ("bye").
12:23:18 -!- ehird has joined.
12:38:37 -!- ehird has set topic: Continuing the tradition of me changing the topic when I get up, the topic is now "Conti.
13:05:03 -!- jix has joined.
13:45:45 -!- helios24 has joined.
13:59:44 -!- Tritonio_ has joined.
14:01:25 -!- sebbu has joined.
14:05:25 -!- Hiato has joined.
14:19:23 <ehird> I am trying to pervert Hofstadter's "GOD Over Djinn" into an esolang name.
14:20:04 <Hiato> Hrmm... GOD Over Gin ? Naah, nevermind....
14:20:21 <ehird> He already made that joke, in the same story.
14:20:38 <Hiato> Oh well.. I tried ;)
14:20:59 <ehird> The characters (The Tortoise and Achilles) had entered an M.C. Escher painting using pushing & popping tonics (used to explain call stacks).
14:21:26 <ehird> That was where they met the infinite chain of Djinn (Djii?), collectively referred to as the recursive acronym "GOD Over Djinn".
14:21:35 <ehird> The dialogue, of course, was called "Djinn and Tonic".
14:22:26 <Hiato> Ah, I see. Wel,, I'm out of suggestions (yes, after but one), but I'll keep thinking about it - if that helps :)
14:45:47 -!- jix has quit (Read error: 104 (Connection reset by peer)).
14:46:24 -!- jix has joined.
14:59:57 <ehird> Someone name my concatentative esolang like Joy :P
15:06:05 -!- Elion has joined.
15:19:31 -!- Elion has quit (Remote closed the connection).
15:31:26 -!- Tritonio_ has quit (Read error: 110 (Connection timed out)).
15:31:54 -!- Tritonio_ has joined.
15:37:16 <ehird> Who is alive right now?
15:41:50 -!- Asztal has quit ("not me").
15:43:10 -!- Insane has joined.
15:43:25 <Insane> Internet connectivity? check
15:45:03 <ehird> who wants to talk about a concatentative esolang similar to Joy and Cat? *crickets chirp* oh. nobody? :(
15:45:59 <Insane> Joy and Cat?....................
15:54:38 <ehird> google 'joy programming language'
15:55:39 -!- Insane_ has joined.
15:55:49 <ehird> they are both very interesting
15:56:41 -!- Insane has quit (Read error: 104 (Connection reset by peer)).
15:57:20 -!- Insane_ has changed nick to Insane.
15:57:44 <Insane> *program that outputs input?
15:57:54 <ehird> yes, but it's also a programming language...
15:57:57 <Insane> I'm gonna smack his lappy keyboard...
15:58:03 <ehird> first and foremost, a cat is an animal
15:58:08 <ehird> it doens't have to be only one program!
15:58:45 <ehird> English isn't your native language, is it.
15:59:09 <Insane> Just joking, I know what an animal is
15:59:44 <ehird> Insane: You know Forth?
16:00:03 <ehird> Well, Joy is like a functional (not in the sense of 'works', of course) Forth.
16:00:14 <ehird> Cat is like a functional, statically-typed (!) Forth,
16:02:14 <ehird> I don't think you're the best person to talk about this with...
16:02:24 <ehird> oklofok: You know Forth, don't you :P
16:02:49 <Insane> The only esoteric languages I know are brainfuck, NetBrainFuck and 1337
16:03:33 <ehird> Insane: Forth,Joy,Cat aren't esoteric.
16:03:52 <oklofok> ehird: i know it's a stack-based language.
16:03:58 <ehird> You could call them esoteric. But people use Forth for real-world apps, all the time
16:04:01 <ehird> Mainly in embedded systems.
16:04:02 <oklofok> and that it's old and famous
16:04:07 <ehird> Cat is a mainly-research-and-teaching language.
16:04:19 <ehird> Joy is a 'ooh, what would happen if we...' language made by a philosophy professor guy
16:04:26 <ehird> oklofok: well, you know stack based languages.
16:04:35 <ehird> well, concatentative languages, to be precise.
16:05:27 <ehird> for all A,B in P. concat(A,B) == compose(A,B) where P = programs in language L
16:05:32 <ehird> ==> language L is concatentative
16:05:43 <ehird> and unless it's a computationally useless language you achive that with a stack.
16:05:47 <ehird> oklofok: there, have a formal definition
16:06:04 <oklofok> well, thanks for that i guess :)
16:06:24 <ehird> oklofok: know Joy?
16:06:45 <oklofok> once again i just know some outlines.
16:07:30 <ehird> http://en.wikipedia.org/wiki/Joy_%28programming_language%29 good primer.
16:07:35 <ehird> basically, it's a functional, concatentative language,
16:07:56 <ehird> but instead of formal parameters and function application, it has program quoting and evaluation
16:08:05 <ehird> kind of like underload, but less crazy
16:08:14 <oklofok> the wikipedia article is all i've read about joy, probably.
16:08:30 <ehird> give it another read, as a refresher
16:08:51 <oklofok> hmm, [] is a false-like lambda?
16:08:58 <oklofok> a generic grouping thingie
16:09:16 -!- Tritonio_ has quit (Read error: 104 (Connection reset by peer)).
16:09:21 <ehird> [...] is a program
16:09:39 <ehird> and you can run it, or use e.g. a combinator to do stuff with them
16:09:50 <ehird> (i is the 'just run it' combinator)
16:11:50 <oklofok> well, that's what i meant by a grouping thingie
16:11:57 <oklofok> you can use that to get a list
16:12:14 <oklofok> anyways, i know what it is.
16:12:27 <Slereah> I'm trying of thinking of some non-lazy evaluation command. How's this? ``>A[B] converts to `A[B], and immediatly afterward, [B] is evaluated.
16:12:55 <ehird> Slereah: just don't if it's for IO
16:13:05 <ehird> oklofok: my language is kind of like that
16:13:14 <Slereah> I cannot undersandy monads.
16:13:21 <Slereah> Newton was against Monads!
16:13:24 <ehird> Slereah: Don't write a functional programming language until you do.
16:13:46 <ehird> oklofok: one distinguishing thing is that it has no special syntax apart from [...]
16:14:02 <Slereah> Is there a better source than Wikipedia on it?
16:14:17 <ehird> oklofok: what don't you liek
16:14:25 <ehird> my prog language has nothing but [..]
16:14:27 <ehird> but joy has things like
16:14:37 <oklofok> i'm assuming you meant,,.... well, yeah
16:15:25 <Insane> My prog language has: +-><[].,*~!%
16:16:24 <ehird> P := '[' P* ']' | (!WS)+ P |
16:16:25 <ehird> S := ' ' | '\t' | '\n'
16:16:45 <ehird> http://rafb.net/p/w9QzSK93.txt
16:16:48 <ehird> that's my languages syntax
16:16:55 <ehird> (if we assume ~X means 'anything but x')
16:17:29 <ehird> i also have string literals.
16:18:00 <ehird> but the language isn't
16:18:47 -!- Insane has quit (Remote closed the connection).
16:19:00 <ehird> i'm not sure how i'm doing to do assignment in my language
16:19:11 <ehird> without adding extra syntax, or using something ugly like a string literal
16:19:20 <oklofok> well, the purest way is not to :)
16:19:37 <oklofok> but that's not a *good* way
16:24:58 <ehird> i mean, fuction definitions
16:25:03 <ehird> which I need since I hav eno paraemters :P
16:25:15 <ehird> i guess i could maybe manage one bit of syntax...
16:25:36 <ehird> So, just like Joy but without the DEFINE thing
16:28:01 -!- Tritonio_ has joined.
16:32:16 <ehird> oklofok: is that ok with you? ;)
16:32:26 <ehird> it just means you can't define = as a word, and the parser needs a lookahead of one word.
16:32:58 -!- timotiis has joined.
16:33:20 <oklofok> i'd make case putting an atom on the stack and using it as a function
16:33:32 <oklofok> i'd make case differentiate between putting an atom on the stack and using it as a function
16:33:47 <ehird> oklofok: inconsistent, though - and there's no need for atoms elsewhere :)
16:33:50 <ehird> So, I think I like this idea.
16:33:54 <ehird> OK! Time to write some example code..
16:34:33 <ehird> you define as Abc, you use as abc
16:34:54 <ehird> i might use ; instead of .
16:35:01 <ehird> oklofok: what do you think i should use as a terminating mark?
16:35:46 <oklofok> i'd put ";" if you can redefine, otherwise "."
16:36:18 <oklofok> no reason, except a feeling.
16:36:26 <oklofok> i'll go buy something pretty ->
16:40:20 <ehird> Really -- all my esoteric programming endeavours are just part of the search for the perfect programming language (for me).
16:40:37 <ehird> I continuously try new abstractions, while removing others.
16:44:15 <ehird> It seems both extremes work equally.
16:44:26 <ehird> Haskell, Lisp, Joy, Cat... they all seem to be just about the same.
16:44:32 <ehird> But I'm not sure they're good *enough*.
17:01:26 -!- Corun has joined.
17:06:06 -!- Corun has quit (Client Quit).
17:07:03 <ehird> oklofok: you bacj yet?
17:07:37 <ehird> Maybe I'm looking in the wrong place.
17:07:54 <ehird> Maybe my options of: REPL-based, batch compiler, batch interpreter are wrong.
17:08:03 <ehird> Maybe my options of: unicode text file are wrong
17:13:25 -!- jix has quit ("CommandQ").
17:20:55 <ehird> oklofok: comments?
17:21:26 -!- oklofok has changed nick to oklopol.
17:21:58 <oklopol> what do you mean by options?
17:23:33 <ehird> well, like what i aim for when designing
17:23:40 <ehird> like, maybe programs aren't inherently flat text files
17:23:49 <ehird> maybe implementations don't have to be one of the things i said.
17:26:13 <oklopol> i don't consider those that important
17:57:00 <Slereah> The monads tutorial seems to require some knowledge of Haskell
17:58:49 <Slereah> I guess I'll have to learn Haskell after all.
18:02:24 <ehird> http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html http://www.haskell.org/haskellwiki/Monad_%28sans_metaphors%29
18:02:28 <ehird> the latter is just a 'WHAT is a monad'
18:02:34 <ehird> the first is 'WHY is a monad'
18:03:50 <Slereah> Apparently, I could have invented them!
18:17:47 -!- Tritonio__ has joined.
18:17:51 -!- Tritonio_ has quit (Read error: 110 (Connection timed out)).
18:19:17 -!- Rocker[box] has changed nick to RockerMONO.
18:24:14 * RockerMONO got a dialect of brainfuck that uses sockets working
18:24:21 <Hiato> as ehird said in reply to my exact question: the sky :P
18:24:50 <RockerMONO> well... it works until the socket disconnects.... but if you leave an IRC bot made in it up for 14 and a half hours after it disconnects, it will be ugly :<
18:25:22 <Slereah> In the hope of making some useful input function
18:25:29 <ehird> Slereah: and output!
18:25:48 <ehird> You can even do state with monads, just add a magical monad-creator combinator and you can write a state monad :P
18:25:49 <Slereah> Well, output seems to work okay so far.
18:26:03 <ehird> Slereah: yes, but if you do one you have to do the other, otherwise things go weird
18:26:05 <Slereah> RockerMONO: I'm still wondering!
18:26:14 <ehird> RockerMONO: 1.learn haskell 2.learn monads
18:26:18 <Slereah> But I hope that the mystery will soon be lifted
18:26:42 <Slereah> It's apparently from category theory, that one from which I don't know squat.
18:27:16 <ehird> Slereah: you don't need to know category theory
18:28:41 <Slereah> Well, I also don't know Haskell.
18:28:52 <Slereah> But I guess Haskell is easier to learn!
18:29:11 <Slereah> [Narrator : AND THAT WAS HIS FATAL MISTAKE]
18:30:54 <Slereah> This was brought to you by the campaign against functional languages.
18:34:10 <ehird> Slereah: #haskell!
18:34:18 <ehird> We're Friendly(TM)
18:37:49 -!- oerjan has joined.
18:41:17 <ehird> make Slereah's #haskell-time fun and fuzzy
18:41:30 -!- jix has joined.
18:44:08 <Slereah> Well, I'll probably read haskell tomorrow.
18:44:21 <Slereah> Don't have many classes tomorrow.
18:45:50 <Slereah> Well, more than I thought. They added some more.
18:46:06 <Slereah> But I still have nothing on fridays.
18:50:33 * oerjan just says "aye" to that.
19:01:09 <Hiato> Thanks (once again) for cleaning up the mess I leave on the wiki :D
19:02:47 <oerjan> i think ais523 did the last cleaning up, actually
19:03:14 <Hiato> well, nontheless, thanks for moving my page and what not :)
19:04:25 <ehird> If a minimal combinator can be "i"
19:04:29 <oerjan> that was him. he's not here right now (he just comes for short periods)
19:04:35 <ehird> to get an entire TC system,
19:04:44 <ehird> what is it for a stack based language?
19:04:46 <Hiato> oh, woops, well thanks anywho for the typo thing etc :)
19:04:54 <ehird> i imagine it requires multiple: dup and all that, for stack manipulation
19:05:06 <ehird> quoted programs + basic stack manipulation words + ??? magic thing ??/
19:06:05 <ehird> we just need to figure out magic thing
19:06:28 <Slereah> Well, I just use an electronic wand, personally.
19:07:13 <oerjan> ehird: have you looked at Joy?
19:07:31 <Slereah> It can be used to solve most undecidable problems. Although cannot force someone to love you, as you can learn in Alladin.
19:08:12 <oerjan> someone did a paper on doing combinators in Joy
19:09:12 * oerjan wonders if ??? magic thing = dip
19:13:08 <ehird> oerjan: of course!
19:13:15 <ehird> my neu language is based on joy, kind of.
19:13:21 <ehird> it's a functional, stack-based language so yeah
19:14:26 <ehird> it might be dip, yes
19:14:40 <ehird> oerjan: i've considered a statically typed Joy -- like Cat -- but with type inference
19:14:52 <ehird> so it's just like a regular concatentative lang, except it yells at you when you write something silly
19:14:55 <oerjan> um Cat is supposed to have type inference
19:15:05 <ehird> oerjan: its not that good though.
19:15:08 <ehird> i might even handle variadic functions
19:15:21 <ehird> you could write a printf which took an argument off the stack when it saw a certain formatting directive
19:15:24 <ehird> and it'd type properly
19:16:33 <oerjan> well you'll have to invent a more clever type system than cdiggins did.
19:17:01 <ehird> i think a printf type could be:
19:17:17 <oerjan> and he had some help from lambda-the-ultimate.org
19:17:25 <ehird> oerjan: this is true, i think it may be undecidable
19:17:44 <ehird> ( ... STRING -- STRING )
19:17:49 <ehird> a bit vague, i guese
19:18:03 <ehird> but it gets the essentials right: you need a STRING on the stack, and might need other stuff, and you'll get a string back
19:18:32 <oerjan> my understanding is that it essentially boils down to the undecidabilit of word equations
19:18:43 <oerjan> *my intuition, perhaps
19:19:06 <ehird> oerjan: the reason i said STRING is because lowercase is reserved for polymorphism
19:19:24 <ehird> swap ( a b -- b a )
19:19:44 <ehird> let's assume forth style definition syntax:
19:19:48 <ehird> this is something..
19:19:57 <ehird> oerjan: can you write the S combinator in J?
19:20:08 <ehird> my intuition is that you cannot capture its first argument in the quoted program it should return
19:20:58 -!- RockerMONO has quit ("Firefox using HALF OF MY FUCKING RAM and HALF OF MY FUCKING CPU :<").
19:21:09 <oerjan> i know very little about J
19:22:02 <oerjan> you're not just abbreviating Joy, i assume?
19:22:48 <oerjan> as i implied, someone has shown how to rewrite SKI combinators in Joy, so yes
19:22:52 <ehird> : factorial ( INT -- INT ) [zero?] [1] [1 -] [*] iter-rec ;
19:23:19 <ehird> : iter-rec ( PROG PROG PROG PROG -- a ) .... ;
19:23:22 <ehird> but that's not very helpful
19:23:25 <ehird> so i'll describe iter-rec
19:23:38 <ehird> ( TERM BASE STEP BINOP )
19:23:46 <ehird> TERM is the termination predicate.
19:23:52 <ehird> BASE is the value to use at termination.
19:23:58 <ehird> well, the program to execute.
19:24:12 <ehird> STEP is what we should repeat on, given the previous value.
19:24:29 <ehird> And BINOP is what we should apply to the next and previous values.
19:25:16 <ehird> : iter-rec ( a ( a -- BOOL ) ( -- a ) ( a -- a ) ( a a -- a ) -- a ) ... ;
19:25:44 -!- RockerMONO has joined.
19:25:45 <ehird> which is insane, but good :D
19:25:57 <ehird> oerjan: Do you think that's a general kind of recursion or is it only going to be usful for a factorial? ;)
19:27:17 * RockerMONO wonders why this channel loses topic parts and modes each time he joins..
19:28:05 * oerjan hadn't noticed the modes. actually still haven't.
19:28:14 <ehird> oerjan: any thoughts on iter-rec?
19:28:24 <oerjan> it makes my head hurt? :D
19:28:28 <RockerMONO> oerjan: nvm it was just lag =P it showed 'no modes' now it shows +nc =P
19:28:39 -!- Slereah has set topic: 10 : Continuing the tradition of me changing the topic when I get up, the topic is now GOTO 10.
19:28:53 <ehird> oerjan: Well, i'll annoate the type fully
19:29:25 <oerjan> one thing, ( -- a ) is just a unless you are doing side effects
19:29:55 <ehird> you could do side effects too
19:30:00 <ehird> maybe i'll pass in a value at some time
19:32:50 <oerjan> i guess it is at least as powerful as a while loop, so can give TC
19:33:10 <oerjan> at least if a can be a tuple type
19:33:29 <oerjan> or some sort of composition
19:35:02 <ehird> oerjan: i was asking re: expressivity
19:35:13 <ehird> here, have annotations:
19:35:40 <ehird> http://pastebin.ca/raw/880225
19:36:06 * RockerMONO 's making screwbin, binary counterpart for brainfuck :D
19:36:07 <ehird> oerjan: using that definition, and seeing how it works with the factorial example, would you say iter-rec is an expressive recursive operator, or will it be ugly for things beyond factorial-alikes?
19:38:43 <oerjan> it's a bit primitive recursive, although not exactly
19:38:56 <oerjan> i don't think you can write ackermann with it
19:40:36 <oerjan> as in, you can only make one recursive call
19:41:44 <ehird> oerjan: its not meant to be general
19:41:47 <ehird> just one in a toolbox
19:41:56 <ehird> i'm just asking if it's elegant for many other things than a factorial?
19:42:41 <oerjan> it's like a haskell unfoldr + foldr
19:43:09 <ehird> I guess it's useful then
19:43:48 <ehird> : bin-rec ( a ( a -- BOOL ) ( -- a ) ( a -- a ) ( a -- a ) ( a a -- a ) -- a ) ... ;
19:44:01 <oerjan> although for the full power of that, you want to distinguish some of the a's
19:44:31 <oerjan> actually it is not a complete unfoldr
19:45:01 <oerjan> though that can be adjusted in the combining function, so not a problem
19:45:22 <ehird> oerjan: give me a syntax for lists
19:45:24 <oerjan> it's iterate + takeWhile + foldr
19:45:27 <ehird> and i'll give you a quicksort with bin-rec
19:45:32 <ehird> and that actually sounds very useful then
19:45:51 <ehird> if you look at factorial with a grokking of iter-rec, it's very clear
19:46:13 <ehird> no stack shuffling or any of that, just the algorithm stated concisely, purely and simply
19:46:30 <ehird> and bin-rec can trivially be tail-recursive!
19:46:45 <ehird> which remidns me. list syntax :P
19:48:27 <ehird> i meant a convenient way to say [a,b,c]
19:48:32 <ehird> not using [] for obvious reason :P
19:49:00 <oerjan> ah yes, i think Joy uses the same for both but that is bad for typing
19:49:41 <oerjan> well there is only one actual bracket left, { }
19:50:37 <oerjan> actually you _could_ use [a,b,c]
19:50:53 <oerjan> saying a b and c are subprograms
19:51:06 <oerjan> breaks for single element
19:53:53 <ehird> oerjan: {} is taken
19:53:55 <oerjan> i assume type inference means the initial ( ... ) in a function could be left out, so that spot makes it unsafe to use something with ( )
19:53:56 <ehird> for {* comments *}
19:54:09 <ehird> <, > are used for comparison for now
19:54:12 <ehird> plus <1 2 3> is ugly :P
19:54:20 <ehird> bah, i need unicode
19:54:32 <oerjan> seems you need a multi-char keyword
19:57:15 <oerjan> for a slightly harder parsing, the initial , could be optional when there is more than one
19:57:20 <ehird> there's no need for a, b, c
19:57:29 <ehird> since you can have it gobble off the stack
19:58:13 <ehird> i don't particularly like that. Maybe:
19:58:45 <ehird> eh, let's do {: ... :} for now?
19:59:05 <ehird> yes, i like that, let's use that FOR NOW
19:59:09 <oerjan> because : could be an actual function
19:59:20 <ehird> no, oerjan. : is define
19:59:30 <ehird> anyway, bin-rec has gone off my screen. stop talking while i write quicksort :)
19:59:32 <oerjan> well something could be
20:00:43 <ehird> : quicksort uncons [length 2 <] [{,}] [swap dup peek <] [swap dup peek >] [concat] ;
20:00:54 <ehird> but, my problem with that
20:00:57 <ehird> is the stack manipulation
20:01:21 <ehird> : quicksort ( {,a} -- {,a} ) uncons [length 2 <] [{,}] [swap dup peek <] [swap dup peek >=] [concat] ;
20:01:26 <ehird> made it work, added a type signature :P
20:01:32 <ehird> oerjan: but that stuff to get to the pivot is pretty ugly
20:02:33 <oerjan> quicksort needs O(1) mutable arrays to be worthwhile anyhow
20:03:12 <oerjan> mergesort is better for actual linked lists
20:04:30 * Slereah goes back to work on Mulambda
20:05:37 <ehird> oerjan: the language is tentatively called LION
20:06:31 <ehird> the object structure is very simple incidentally: just a pointer, if the rightmost bit is 0 the rest of the object is a pointer to something (where *ptr == the type tag structure, and everything after that the data), otherwise the rest is a small integer
20:07:26 <oerjan> (inspired by Scheme in one defun)
20:07:26 <ehird> well, the rightmost bit would be 0
20:07:40 <ehird> Lambda in one .. node?
20:07:57 <ehird> Quoted program in one word definition
20:08:03 <ehird> qpiowd isn't very catchy though.
20:08:36 <ehird> #define SMALL_MAX ((~7)>>3)
20:09:00 <ehird> oerjan: nifty little definition no?
20:10:06 <ehird> oerjan: interestingly, ptr-to-int is just -1 ;)
20:11:19 <oerjan> how is ((~1)>>1) different from ((-1)>>1) ?
20:11:52 -!- immibis has joined.
20:11:55 <oerjan> or ((~0)>>1), for that matter
20:12:21 <ehird> oerjan: well, it shouldn't be
20:12:27 <ehird> ...111111111111111111111111110
20:12:44 <ehird> and you're right with ~0
20:12:44 <oerjan> er that 0 the most significant digit?
20:12:58 <ehird> i want the maximum value stuffable, if you lose one bit
20:13:11 <ehird> So currently that's ((~0)>>1) but I think -1 is right
20:13:13 * oerjan would call that 0111...1
20:13:25 <ehird> oerjan: Welp, I stuff on the rightmost bit.
20:13:31 <ehird> And so does mzscheme, so I have backing here!
20:14:02 <oerjan> i'm a mathematician, i expect the least significant bit to be rightmost
20:14:50 <oerjan> and >>1 shifts off the least significant bit afaik
20:15:17 <oerjan> leaving the most significant bit 0, assuming sign bits don't duplicate
20:15:24 <ehird> oerjan: You are confused.
20:15:32 <ehird> I am accessing WHAT I CAN HAVE, NOT packing stuff ina value
20:15:42 <ehird> so, an example packed small integer:
20:16:00 <ehird> So: least significant, rightmost.
20:16:26 <oerjan> 1...1110 is <<1, not >>1
20:16:37 <ehird> oerjan: your -1 relies on twos complement
20:16:52 <ehird> oerjan: Yes! Exactly! So I get 1...110, shift it to the right, then get 0...111
20:16:58 <ehird> Which is the maximum value a small integer can be!
20:17:11 <ehird> This is when I read in an integer!
20:17:16 <ehird> To tell if I can stuff it into the pointer directly!
20:17:30 <oerjan> ehird: ok i was confused but you started it :D
20:17:50 <oerjan> so ...1110 is the internal integer format
20:18:01 <oerjan> and >>1 turns it into ordinary C format
20:18:01 <ehird> 0 is for the pointers
20:18:05 <ehird> And yes, that is right
20:18:28 * oerjan assumes it's cleared up now
20:18:31 <ehird> #define IS_SMALL(x) ((x)&1)
20:18:58 <ehird> LION sp; /* JESUS CHRIST IT'S A LION STACK POINTER GET IN THE CAR */
20:19:01 <ehird> ^^ i am tempted ...
20:20:44 <oerjan> and later, /* ARGH CLOSE THE WINDOWS */
20:22:04 <ehird> oerjan: evidently internet memes never effect you
20:22:22 -!- Hiato has left (?).
20:23:08 <oerjan> indeed i browse relatively few sites
20:23:28 <ehird> 'JESUS CHRIST IT'S A LION GET IN THE CAR' is a meme, yes
20:23:31 <ehird> it's died down by now
20:25:36 <oerjan> or rather, i am reminded of a Larson strip where a lion has a cloth-hanger
20:29:42 <oerjan> do you just find numbers funny, or what? :D
20:30:24 <ehird> oerjan: you will figure it out, if you have the fu of not 10.
20:30:29 <ehird> (yes, i am being deliberately obscure)
20:30:58 <oklopol> oerjan: when you get it, explain it to me in pm
20:31:25 <ehird> it's not that hard
20:31:35 <ehird> hint: that's in my initialization function. it's for future error checking
20:33:56 <ehird> but i'm changing BADBEEF to DEADBEEF
20:34:04 <ehird> because that more accurately describes a call stack underflow
20:34:38 <oerjan> you spoiler! i was just starting trying base conversions.
20:34:48 <oerjan> for some reason tried binary first
20:35:02 <ehird> i thought 'whatever' meant 'i gave up'
20:35:14 <oklopol> "whatever, i'm not gonna play your stupid games"
20:35:26 <oklopol> ("mwahahaha, i'm so gonna crack this")
20:35:44 <oerjan> er, my giving up passed away
20:36:53 <oerjan> that badf00d actually caused me some confusion, because those 0's _do_ show up prominently in base 2
20:37:14 <oerjan> but my brain was just too slow this evening
20:39:44 <ehird> oerjan: Should Lion have a call/cc
20:39:52 -!- jix has quit ("CommandQ").
20:40:21 <oerjan> might be easy if you have a linked-list execution stack
20:40:58 <ehird> oerjan: Well, I don't :P
20:41:32 <oerjan> what are you writing it in?
20:41:41 <ehird> C, duh. Didn't you see my #defines? :P
20:42:08 * oerjan de-evolves further to the neanderthal stage
20:42:20 <ehird> don't worry, i'm going to write it simply
20:42:48 <oklopol> isn't defining like coarsening?
20:46:35 <ehird> oerjan: Feel free to help me implement it in Haskell. ;)
20:47:02 <ehird> OH NOW YOU DON'T TALK
20:48:53 <oerjan> TOO LONG WORD, HAS, HAS, THAT ONE
20:50:02 <ehird> So now you don't like Haskell either? :P
20:50:20 <oerjan> IS GREAT. JUST NOT CAN SAY IT.
20:50:54 <ehird> oerjan: WILL HELP IMPLEMENT LION HASKELL?
20:51:01 <ehird> primitive :: Stack -> Stack LIKE MUCH
20:52:17 <ehird> C can wait until we've verified the awesomeness of it, I guess :P
20:58:47 <ehird> oerjan: I have an idea for mutability
20:59:01 <ehird> instead of doing like
20:59:09 <ehird> in various clauses of Value,
20:59:20 <ehird> where Location is an Int index, in a heap array
20:59:27 <ehird> and we can just modify that array..
20:59:35 <ehird> perhaps ugly, perhaps not. oerjan: thoughts?
21:00:11 -!- Hiato has joined.
21:00:31 <oerjan> well i think that's the usual way of simulating mutable structures in pure code
21:00:50 <oerjan> it gets ugly if you have more than one type of value though
21:01:17 <oerjan> also, you don't get the benefit of automatic GC
21:01:39 <ehird> oerjan: of course, at any time a function could do some IO
21:01:45 <ehird> so maybe we'd be best off using IO and IORef
21:02:09 <ehird> should we still have (Stack -> Stack), well, now, (Stack -> IO Stack)?
21:02:27 <ehird> where StackMonad is IO with a stack in it, heh
21:02:56 <oerjan> well you could have a StackMonad even if you don't keep the Stack in an IORef
21:03:14 <oerjan> (StateT Stack IO for example)
21:03:58 <ehird> type Stack = StateT [Value] IO
21:04:03 <ehird> So we can have "primitive :: Stack ()"
21:04:08 <ehird> Just looks a bit nicer, I guess. heh.
21:04:55 <oerjan> so the actual stack is [Value]
21:05:09 <oerjan> that's a bit confusing terminology
21:05:45 <ehird> oerjan: Well, yeah
21:05:52 <ehird> A stack is just a linked list
21:06:11 <oerjan> that's perfectly reasonable.
21:06:14 <ehird> haskell compilers can do optimizations on lists.
21:06:18 <oerjan> i mean calling the monad Stack
21:06:41 <ehird> let's say its called StackMonad
21:06:45 <ehird> drop :: StackMonad ()
21:06:54 <ehird> drop = do (_:xs) <- get
21:07:22 <ehird> drop :: Stack -> IO Stack
21:07:28 <ehird> drop (_:xs) = return xs
21:07:40 <ehird> I just guess I see everything as a stack to stack mapping
21:08:02 <oerjan> although yours has the advantage we can add an error layer easily
21:08:33 <ehird> oerjan: Which do you prefer? A stack monad, with IORef for all mutable things, or a stack to stack mapping function that has an IO monad attached to it?
21:09:25 <oerjan> i think perhaps Stack -> IO Stack is better, nearly all the functions will need to look at the stack anyhow
21:10:03 <oerjan> and few will need to return any other value
21:10:06 <ehird> if we're going to do static type checking
21:10:15 <ehird> we need to make that pleasant to deal with in our primitives
21:10:31 <ehird> i.e. specifying a type for them, and all that jazz
21:10:33 * oerjan actually has no experience implementing that
21:10:52 <ehird> And especially no experience implementing type inferrence.
21:11:28 <ehird> oerjan: I'm not sure which of our options -- or a third -- will make specifying the primitive functions and their types easier
21:15:26 <ehird> oerjan: In fact, how will we specify the types at all?
21:16:34 -!- helios24 has quit ("Leaving").
21:50:13 -!- ehird has quit ("Leaving").
21:52:08 -!- ehird has joined.
22:01:34 -!- cherez has quit (Read error: 104 (Connection reset by peer)).
22:10:44 -!- unrepresentative has joined.
22:11:14 <ehird> on typability and mutability and taht stuff
22:14:01 <oerjan> i recall faxathisia yesterday was trying to implement type inference for simply typed lambda calculus in haskell
22:15:11 <oerjan> also, that will not be enough for a stack language
22:16:21 <oerjan> i actually didn't look at what Cat ended up with
22:19:59 <ehird> oerjan: i tell you what
22:20:02 <ehird> i'll get ghc back up
22:20:09 <ehird> then let's just see how it goes, when we try and write it
22:22:10 -!- GreaseMonkey has joined.
22:26:23 <ehird> oerjan: I think, data types:
22:26:55 <ehird> 1. Integer 2. Float 3. Program 4. Primitive 5. List
22:27:56 <ehird> oerjan: Bah, ok. But still have a float?
22:29:18 <oerjan> or is that what you mean by Vector?
22:29:48 <oerjan> anyway more of those are easy to add, i think
22:32:21 <ehird> oerjan: Vector is a numerically-indexed, consecuative in memory O(1) access structure
22:32:24 <ehird> (aka 1-dimensional array ;))
22:32:43 <ehird> oerjan: Tuple, maybe but i'm not sure
22:32:48 <ehird> mostly you would just use the stack for that
22:33:06 <ehird> oerjan: I think we should get basic object and stack operations, then write the parser. It often helps enlighten.
22:34:19 <ehird> oerjan: Should types be first class objects?
22:34:28 <ehird> So you could do INT and get the integer type pushed to the stack
22:34:33 <ehird> that would be fun though
22:34:39 <ehird> it'd also make implementing (...) easy
22:34:41 <oerjan> then we get dependent types
22:34:50 <oerjan> and we are already in deep enough water
22:34:53 <ehird> TYPE is a TYPE is a TYPE ...
22:35:15 <ehird> oerjan: I'm naming all the constructors LName
22:35:24 <ehird> to avoid conflicts.
22:35:27 <ehird> the actual type is Value, though.
22:35:40 <oerjan> not strictly necessary
22:35:51 <ehird> oerjan: should i not do it?
22:35:55 <oerjan> data constructors and type constructors are different name spaces
22:35:55 <ehird> i get confused when i see like
22:36:14 <ehird> oerjan: oh, extra type: String
22:36:26 <ehird> and thus character
22:36:38 <ehird> strings: immutable, or mutable
22:36:52 <oerjan> but we'll need constructors for types and values, so need to have two sets of some anyhow
22:37:54 <ehird> I seem to mutate strings all the time, when not programming in a really functional language
22:38:06 <ehird> (Lion isn't purely functional. Just you can utilize the functional paradigm to your benefit.)
22:38:41 <ehird> oerjan: instead of list, maybe we should have stack
22:38:53 <oerjan> when you have a dictionary and the keys can be mutated, you are in deep trouble
22:38:55 <ehird> but... i can't see you using a 'stack' structure heavily in programming, more than a list..
22:38:59 <ehird> oerjan: this is true
22:39:13 <ehird> oerjan: maybe we should provide 'stack' and 'list' which are equivilent :P
22:39:41 <ehird> oerjan: both are (IORef [Value])
22:39:55 <ehird> maybe we should do
22:40:16 <ehird> newtype Stack a = EmptyStack | Stack a Stack
22:40:22 <ehird> just to emphasise the difference
22:40:28 <ehird> but that might stop compilers optimizing
22:40:45 <oerjan> newtype Stack a = Stack [a] should work
22:41:02 <ehird> oerjan: pretty useless, though
22:41:09 <ehird> Should lists be immutable?
22:41:19 <ehird> Schemers seem to like their lists in Diet Immutable flavour..
22:41:53 <ehird> oerjan: by the way
22:41:59 <ehird> type Stack = IORef [Value]
22:42:03 <ehird> type Stack = [Value]
22:42:28 <ehird> if the latter, then we get | LStack (IORef Stack) which is different from the stack in Lion programs
22:42:54 <oerjan> what is the stack in Lion programs?
22:43:06 <oerjan> they should definitely be interchangeable
22:43:17 <ehird> oerjan: the stack in lion programs is just a [Value]
22:43:22 <ehird> with all the primitives being (Stack -> IO Stack)
22:44:12 <oerjan> we could go the Ref way - having just one type that is mutable, and contains an arbitrary value
22:44:30 <ehird> oerjan: personally i don't like that
22:45:25 <ehird> oerjan: another note: double vs float - i don't want two because it will make the interpreter more complicated
22:45:40 <oerjan> right, so take the best precision
22:46:13 <ehird> how do we represent the a, b and c?
22:46:23 <ehird> i.e. | LProg Type (WHAT?)
22:46:29 <ehird> i.e. | LProg Type Type (WHAT?)
22:46:37 <ehird> oerjan: speaking of which, what type is a data constructor
22:46:59 <oerjan> a function of its arguments, in haskell
22:47:14 <ehird> so how do we represent 'a type in Lion'
22:47:44 <oerjan> also, values do not need to contain types
22:48:04 <ehird> we can do that all pre-interpretation right?
22:48:14 <ehird> hmm, we will need a two-pass interpretation :-)
22:48:29 <ehird> after parsing (which will not be able to parse into values, but some AST):
22:48:36 <ehird> analyze all imports and that shiznit
22:48:42 <ehird> gather up our types, do the inferrin' and the checksin'
22:48:53 <ehird> get all yer AST, munge into values
22:49:24 <ehird> oerjan: oll korrect?
22:49:48 <ehird> oerjan: and the AST should be in Lion.AST
22:49:58 <ehird> because it's murky and most people would wet their pants upon seeing it
22:50:21 <ehird> oerjan: So: LProg [AST] or LProg [Value]
22:50:29 * oerjan thinks the same is true for ghc...
22:50:33 <ehird> [Value] would require that we resolve [a b c] into the programs that a, b and c represent
22:50:40 <ehird> which is like forth and... you can't recurse with it
22:50:52 <ehird> So... [AST]? If so, that means we have to do analysis on quoted program call
22:51:00 <ehird> Which is... kinda lame.
22:51:16 <oerjan> LProg (Stack -> IO Stack)
22:51:52 <ehird> oerjan: whoa, we're compiling?
22:51:55 <ehird> .. when did that happen
22:52:33 <ehird> oerjan: and if we don't? :P
22:52:48 <ehird> also, how would we construct the haskell? we can't exactly generate a string and pass it to eval..
22:52:57 <ehird> we should use Harpy FOR THE SPEED OF IT! :p
22:53:30 * oerjan has heard the word Harpy but isn't quite clear on it
22:54:24 <ehird> oerjan: it's a monadic haskell DSL for generating x86 machine code (and getting a function out of it) at runtime
22:54:36 <ehird> http://uebb.cs.tu-berlin.de/harpy/
22:54:39 <oerjan> not constructing haskell text, just using combinators to combine programs
22:55:10 <ehird> are we compiling or not?
22:55:13 <oerjan> well perhaps we should go via an AST first
22:55:15 <ehird> and if not, what data type for LProg? :P
22:55:24 <ehird> oerjan: oh, we will go via an AST
22:55:32 <ehird> we have to analyze all the types and all that
22:55:36 <ehird> and THEN we can compile that
22:55:45 <oerjan> we need LProg's to be available as runtime values
22:56:08 -!- Corun has joined.
22:56:28 <ehird> oerjan: just to execute them
22:56:45 <ehird> oerjan: though we do need the types i think?
22:57:26 <oerjan> of already compiled modules
22:57:40 <oerjan> then they need to include types somehow
22:57:47 <oerjan> although maybe not in the same file
22:57:55 <ehird> oerjan: I think interpretation is our best best.
22:58:03 <ehird> But then, we go back to the problem: What is an LPRog?
22:59:23 <oerjan> interpret (LProg prog) :: Stack -> IO Stack
22:59:44 <ehird> oerjan: what about it
23:00:00 <oerjan> and that is the only way a prog is used
23:00:16 <ehird> oerjan: and getType :: LProg -> ???
23:00:25 <oerjan> so the prog could be just that, and interpret (LProg prog) = prog
23:00:35 <ehird> oerjan: and getType :: LProg -> ???
23:00:39 <ehird> think about, say, a REPL
23:00:44 <ehird> when you enter an expression
23:00:46 <ehird> it has to typecheck it
23:00:49 <oerjan> it is merely a question when we do the conversion to Stack -> IO Stack
23:00:49 <ehird> but all the compiled functions it has
23:00:52 <ehird> don't have their types!
23:00:57 <ehird> they're just (Stack -> IO Stack)
23:01:18 <oerjan> i am assuming this is at the time we have already done type inference
23:01:29 <oerjan> so values don't need to contain types
23:01:29 <ehird> An interactive mode.
23:01:32 <ehird> Do you see the problem now?
23:01:44 <oerjan> the dictionary for a repl
23:01:51 <ehird> : foo ( INT -- INT ) ;
23:01:53 <oerjan> would contain (Value, Type) pairs
23:02:01 <ehird> "abc" foo {* foo has lost its type, so we can't check it *}
23:02:07 <ehird> oerjan: uhm what about the eval function
23:02:20 <ehird> i think that the best way is to have some kind of actual interpretation.
23:02:33 <ehird> LProg Type Type ???
23:02:40 <ehird> The thing we need to fill in is ???
23:02:47 <ehird> oerjan: can you please read what i'm saying
23:02:50 <ehird> we need the types at runtime
23:03:02 <ehird> oerjan: so explain.
23:03:09 <oerjan> we don't need them in the values themselves
23:03:13 <ehird> where do we need them
23:03:23 <oerjan> we just need them in the toplevel REPL dictionary
23:03:46 <oerjan> each identifier comes with a value _and_ a type
23:03:47 <ehird> oerjan: REPL isn't the only instance of this.
23:04:22 <ehird> if you have a dynamic language, where ANYTHING could happen at runtime, including loading files in mish-mash order, you NEED to store those types
23:04:31 <ehird> oerjan: OK then, let's pretend we don't need types
23:04:58 <ehird> oerjan: Well, yeah. It is a dynamic language
23:05:00 <oerjan> it could still be either [Value] or Stack -> IO Stack
23:05:02 <ehird> Not in types, but in other cases.
23:05:09 <ehird> oerjan: [Value] it could not be.
23:05:18 <ehird> [a b c] -> what Value do you use for a, b and c?
23:06:33 <ehird> so the current only option is an AST
23:06:36 <ehird> which is probably the best bet
23:06:58 <oerjan> oh i am not sure [Value] is impossible
23:07:03 <ehird> but i still think having types in the value -- even if not neccessary -- will make writing the interpreter trivial
23:07:15 <ehird> oerjan: basic rule of thumb: everything that's a Value you can put in a ( -- ) declaration
23:08:07 <oerjan> i am still not sure there is a problem
23:08:24 <ehird> oerjan: what is the value for a b and c then
23:08:37 <oerjan> that depends, obviously, on what a b and c is
23:08:51 <oerjan> if a = 1, probably just that
23:09:21 <oerjan> if a b and c are primitive functions
23:09:32 <ehird> oerjan: primitive or maybe defined..
23:09:36 <ehird> and here's the main thing
23:09:39 <ehird> functions can be redefined.
23:10:02 <oerjan> need to keep their types, right?
23:10:05 <ehird> haha, did i just stomp out our compiler design
23:10:18 <ehird> otherwise you'd have to do major type rechecking
23:10:30 <ehird> and this would break the system:
23:10:52 <ehird> oerjan: so, it does have to be an AST doesn't it
23:11:04 <ehird> ah wait! we don't EVER have to convert an AST into Values
23:11:13 <ehird> we just go through the AST and interpret it
23:11:17 <ehird> just the stuff on the stack are Value-s
23:11:44 -!- timotiis has quit ("leaving").
23:12:03 <oerjan> well if functions can be redefined they need to be stored with their names/lookup keys
23:12:30 <ehird> oerjan: yes, we'll also gain global variables from this
23:12:38 <ehird> maybe local variables would make some code clearer too
23:12:49 <ehird> though lexical vars would be a huge overhead.
23:12:55 -!- oklopol has quit (Read error: 104 (Connection reset by peer)).
23:13:02 <ehird> oerjan: we have a (M.Map String Value)
23:13:14 <ehird> oerjan: we have a (M.Map String (Bool,Value))
23:13:29 <ehird> otherwise assigning a global variable to a program would have odd results (autocommandifies)
23:13:52 <ehird> (isCommand,value). (True,aProg) or (False,anyValue)
23:14:19 -!- oklopol has joined.
23:14:34 <ehird> oerjan: that's ugly, of course ;)
23:16:34 <oerjan> a program executes while a value places itself on the stack
23:17:07 <ehird> oerjan: actually, i think we should store the type in programs only used by things like the repl
23:17:12 <ehird> it'd just make the repl a lot easier
23:17:34 -!- Insane has joined.
23:17:44 <ehird> oerjan: hmm, what to call the AST object?
23:17:48 <ehird> AST or ASTNode or Expr or..
23:18:37 <oerjan> assuming there is only one type of it, AST is fine?
23:19:31 <ehird> its just not a tree
23:20:04 * oerjan spontaneously rearranges ASTN and adds a Y
23:21:10 * oklopol adds an "i", because this channel lacks it
23:21:25 <ehird> oerjan: I think Expr is good
23:22:01 <ehird> oerjan: hould we duplicate LInt/Char/String etc for the exprs?
23:22:35 <oerjan> data constructors cannot be shared between types
23:23:57 <ehird> data Expr = EInt Integer | ...
23:24:04 <ehird> i prefer the Constant Value
23:25:55 <ehird> i was just about to paste something
23:26:09 <oerjan> only from the fridge...
23:26:11 <ehird> http://hpaste.org/5333
23:27:12 <ehird> i just need the Type type ;P
23:27:19 -!- unrepresentative has left (?).
23:31:53 <ehird> oerjan: when you're back: what should Type be?
23:32:07 <oerjan> that's the hardest part i guess
23:32:22 <ehird> it'd mostly be a duplication of Expr. But without the constructor parameters
23:32:30 <oerjan> we need Forall Var Type for polymorphism
23:32:57 <oerjan> er, do you know anything about haskell types?
23:33:11 <ehird> enough to write most stuff!
23:33:16 <ehird> But not Forall Var Type polymorphisms
23:33:25 <ehird> I kind of get the "forall a. ..." stuff though. If it's anything related
23:33:54 <oerjan> hm, perhaps Forall [Var] Type
23:34:22 <oerjan> stacks cannot be the same type as uniform lists
23:34:48 <ehird> lists are immutable
23:34:51 <ehird> stacks are an IORef
23:34:59 <ehird> uh yes, see my paste
23:35:00 <oerjan> that is almost irrelevant
23:35:14 <oerjan> lists contain only one common type
23:35:27 <oerjan> stacks need to be distinguished according to their contents
23:35:43 <oerjan> Stack Type Type perhaps
23:35:45 -!- cherez has joined.
23:35:47 <ehird> oerjan: haskell lists or my list
23:35:54 <ehird> because Lion lists are polymorphic
23:35:59 <oerjan> the first is the top type, the second the rest of stack
23:38:43 <oerjan> if there is to be any hope of type inference, then there must be a difference between what corresponds to haskell's tuple-like and list-like types
23:39:06 <oerjan> tuple-like means each position of the tuple (at least those positions we look at) must have a specific type
23:39:12 <ehird> OK, lists are all of one type... Hm... I don't know how to express that in Value
23:39:30 <oerjan> list-like means all positions have the same type
23:39:49 <oerjan> without Oleg-level type hackery
23:40:52 <oerjan> maybe that's what they do with those GADTs
23:41:52 <oerjan> that would mean having Lion types be more closely connected to haskell types
23:42:03 <ehird> oerjan: maybe we should stop using haskell's type system, the way this is going :P
23:42:28 <ehird> data Value = Value Type [... but then i wouldn't know what to put here obviously ...]
23:42:55 <oerjan> _either_ we make Value be completely dynamically typed, _or_ we need to be very clever with the haskell
23:43:25 <ehird> oerjan: i think being clever with haskell might make us bump into limimtations later on
23:43:47 <ehird> oerjan: OK, what zany magic does a Value become now?
23:45:32 <ehird> oerjan: Since I have no idea to say A BLOCK OF POLYMORPHIC MISHMASH since that is... not haskell's speciality
23:45:38 <ehird> Do we need to do weird pointer magic or something? :P
23:46:22 <oerjan> um i thought you said we _shouldn't_ be clever with the haskell
23:47:15 <ehird> oerjan: we shouldn't
23:47:20 <ehird> but i don't see another way to make Value polymorphic
23:47:41 <oerjan> we make Value polymorphic by ignoring all types in it
23:47:54 <oerjan> writing it as if the language is totally dynamically typed
23:47:56 <ehird> I think i'm missing something. What is Value's data definition?
23:48:19 -!- Hiat1 has joined.
23:48:42 <oerjan> you might remove the two Type's from it
23:49:00 <oerjan> i am slightly worried about the IORef Stack
23:49:18 <oerjan> exactly how is it supposed to be legal to change a Stack?
23:49:45 <ehird> oerjan: by pushing to it and popping off it?
23:49:51 <ehird> or swappign two valus in it?
23:50:20 <oerjan> and that can only be well-typed if all values in it have the same type
23:50:30 <ehird> It's just like the main program stack.
23:50:35 <ehird> Completely polymorphic
23:50:49 <ehird> there's only a single stack type, STACK
23:50:53 <ehird> it holds any value
23:51:21 <oerjan> that's not a single type in any static type system
23:51:46 <oerjan> that might be overgeneralizing
23:51:52 <ehird> oerjan: It is in this case, because otherwise the main stack would be badly typed
23:52:03 <ehird> So we have one magical kitten bunny unicorn polymorphic type.
23:52:16 <oerjan> in a concatenative language the type of the stack depends on time
23:52:23 <oerjan> where you are in the program
23:52:40 <ehird> 1 "abc" 2.3 [x y z]
23:52:47 <ehird> that is totally polymorphic.
23:52:54 <ehird> and having the stack as a first-class object is useful
23:52:57 <oerjan> but if it is static like Cat then the type is still fixed at a given point
23:53:07 <ehird> oerjan: oh, in FUNCTIONS, sure.
23:53:12 <ehird> that's just verified that the calls are OK
23:53:17 <ehird> but you can do whatever you want otherwise
23:53:24 -!- Corun has changed nick to RockTheDragon.
23:53:26 <ehird> runInStack :: Stack -> IO Stack
23:53:46 <oerjan> so you want a lot of dynamic checking of stacks before passing them to functions?
23:54:01 <ehird> runInStack (s : p : xs) = do foo <- readIORef s; return (interpret p s : xs)
23:54:16 <ehird> oerjan: We determine this before interpretation..
23:54:49 <ehird> Since all FUNCTIONS have well defined types, and all PUSHES do, we can determine if a CALL is well-typed, but the STACK itself is totally polymorphic.
23:56:30 <oerjan> if you dup a mutable stack you are going to get aliasing problems
23:56:49 <ehird> oerjan: present a program (use any stdlib functions you want to do it) that is a problem with typing or whatever because i'm not seeing it
23:56:56 <ehird> oerjan: also, we copy objects with dupping, I think
23:57:29 <oerjan> in that case there is no point in making Stacks be in IORefs
23:57:55 <ehird> oerjan: yes there is
23:58:36 <ehird> runInStack (p : s : xs) = do foo <- readIORef s; stk <- interpret p s; writeIORef foo stk; (s : xs))
23:58:36 <ehird> i guess you are right
23:58:41 <ehird> oerjan: but then stacks are just identical to lists
23:58:46 <ehird> so i don't feel justified including them! ;)
23:58:59 <ehird> you can stuff stacks in something else
23:59:02 <ehird> - say a structure -
23:59:05 <ehird> without having them copied
23:59:09 <ehird> thus, they need to be iorefs
23:59:32 <oerjan> but then you get aliasing problems again