00:00:00 --- log: started retro/12.11.30
02:49:17 --- nick: saper_ -> saper
09:13:45 --- quit: karswell (Ping timeout: 256 seconds)
09:14:59 --- join: kumul (~kumul@66-50-34-70.prtc.net) joined #retro
09:20:42 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro
11:03:00 --- join: Mat2 (~claude@91-65-144-133-dynip.superkabel.de) joined #retro
11:03:05 <Mat2> hello
11:28:48 <tangentstorm> hey Mat2 
11:30:27 <Mat2> hi tangentstorm 1
11:30:29 <Mat2> !
11:30:53 <Mat2> how is your compiler progressing ?
11:35:22 <tangentstorm> Mat2: slowly. lots of distractions the past couple days :)
11:37:49 <Mat2> ah
11:39:10 <tangentstorm> I have been reading the new ANTLR4 book though, and it's given me a lot of ideas.
11:39:39 <tangentstorm> the parser is kind of the hardest part for me, for some reason
11:40:55 <Mat2> can you exlain that in detail ?
11:43:26 <tangentstorm> Okay, so I'm making a set of programming courses, and I plan to use a language like pascal / oberon ... But you'll be able to extend the grammar dynamically to add new things.
11:45:05 <tangentstorm> So the grammar of the language needs to be a data structure that can be modified at runtime.
11:45:35 <Mat2> that's the basic idea behind lisp !
11:45:37 <tangentstorm> So I can't just use a parser generator like lex and yacc.
11:47:06 <tangentstorm> Yeah, what I'm doing is very lispy inside, but instead of parenthesis everywhere, you can have syntax that looks like whatever you want.
11:48:17 <Mat2> or you can create your syntax from retro though defining words. Both ways it can be extended freely
11:48:22 <tangentstorm> In fact, the way I envision the lessons goes something like this:
11:49:22 <tangentstorm> 1. teach the basic imperative concepts from pascal/oberon : IF, CASE, REPEAT, WHILE, PROCEDURE, etc...
11:49:42 <tangentstorm> 2. talk about how to implement those on a computer, using retro / ngaro
11:49:58 <tangentstorm> 3. show how to translate them with a compiler
11:50:17 <tangentstorm> the compiler will very probably be a lot like lisp
11:50:54 <tangentstorm> 4. show how to generalize the compiler to extend pascal itself
11:51:42 <tangentstorm> 5. pull in examples from prolog, smalltalk, haskell, etc.
11:52:32 <tangentstorm> the end result will be more of a programming pidgin than a programming language
11:52:56 <tangentstorm> Do you know what pidgin means?
11:53:07 <tangentstorm> I know you speak like 800 languages :)
11:53:27 <tangentstorm> http://en.wikipedia.org/wiki/Pidgin
11:54:27 <tangentstorm> The thought was I would be able to teach something like prolog, something like smalltalk, something like haskell, something like forth... etc etc
11:55:43 <tangentstorm> but instead of having to remember whether a language uses "print" or "echo" or "writeln" or "puts" or "putstring" or "emit" or whatever, there'd just be one word for it across all the mini-languages
11:57:22 <tangentstorm> I do want to build the compiler up from retro ( or some dialect of forth )
11:58:10 <Mat2> ok, you will need to extend retro with a word set for list processing. On top of that I would simply implement an EBNF parser as meta representation for the syntax
11:58:25 <tangentstorm> Mat2: yep :)
11:58:32 <Mat2> there exist some good examples of such parsers in forth
11:59:13 <tangentstorm> I already wrote the parse engine.
11:59:30 <tangentstorm> It recognizes text, but it doesn't do anything with it
11:59:43 <Mat2> http://www.bradrodriguez.com/papers/bnfparse.htm
12:00:25 <tangentstorm> https://github.com/sabren/b4/blob/master/pre/pre.pas#L376
12:01:10 <Mat2> define an defining word class in retro. This way each syntax element can be represented as object holding two elements, the token string and a pointer to its implementation word (the code routine)
12:02:08 <Mat2> you can also be use the class concept of retro directly, defining a word class for tokens
12:04:02 <Mat2> probably crc knows better how to handle these
12:06:16 <Mat2> theoretical, the BNF parser need only to search for the dictionary of each token and execute it. The token words can then compile code on the fly beside parsing
12:07:00 <Mat2> this have one advantage: The whole syntax can be changed dynamical in an easy way
12:09:15 <tangentstorm> was reading the paper you linked. 
12:10:19 <tangentstorm> my engine is also a top-down parser with backtracking. interesting to see another take on it in forth
12:11:19 <Mat2> as written, in forth is would be possible to generate code on the fly beside parsing
12:11:44 <Mat2> specially in retro all you need for that would be creating a word class for tokens
12:13:40 <Mat2> theoretical the token words can also check the syntax if you set up some state variables but these should better be handled from the parser
12:18:36 <tangentstorm> a token class in retro makes a lot of sense
12:18:57 <Mat2> ask crc for help if you get in trouble
12:19:17 <tangentstorm> i probably will
12:19:26 <tangentstorm> ( ask and get into trouble! )
12:19:58 <tangentstorm> i had figured i'd make a simple version in forth that worked bottom up
12:20:05 <tangentstorm> but didn't do much error checking or anything
12:20:37 <tangentstorm> and no type checking
12:22:23 <Mat2> traditional forth is an untyped language (with exception of strong forth)
12:22:30 <tangentstorm> or rather the types would just all be "int32" like in retro :)
12:23:22 <tangentstorm> yeah. my language is going to use the type system from agda
12:23:51 <Mat2> in my opinion type checking is only useful for imperative languages which depending on some form of native-code compilation
12:24:51 <tangentstorm> http://strictlypositive.org/Easy.pdf ,- this one
12:25:22 <tangentstorm> i use type checking as a modelling tool
12:26:56 <tangentstorm> like, i'd prefer to work out how all the pieces of code fit together just by defining their types before i wrote any actual code
12:28:12 <tangentstorm> then the type checker can tell me if my ideas are sound and if i've got enough pieces to get the output i want
12:32:08 <Mat2> This method will not work in languages ​​such as smalltalk, because the syntax of this class of languages, can not be type safe
12:32:26 <tangentstorm> sure it can. it just isn't :)
12:33:59 <tangentstorm> but also... there'll be a boxed, dynamically typed layer on top, too
12:34:53 <tangentstorm> i guess i should say that when i have a good idea what i'm doing, i want to use strong static typing
12:35:27 <tangentstorm> but when i'm just exploring, then i just want to write code and experiment, and not care about types
12:35:44 <Mat2> in smalltalk you can redefine the object behaviour at runtime, same with IO or all prototype based programming languages
12:35:47 <tangentstorm> and i don't see any reason why you have to choose between them except tradition
12:36:54 <tangentstorm> Mat2: but you can check the interfaces... like "in order to run this code, the object must have methods a, b, c, and d."
12:37:43 <Mat2> yes but you must do it for each object invocation and that is very time consuming
12:37:58 <tangentstorm> no, you do it at compile time :)
12:38:12 <Mat2> see:
12:40:21 <Mat2> |1| state: isBoolean if [1.0]
12:41:04 <Mat2> or some other nonsense is correct
12:42:44 <Mat2> the problem is: the state is changed at runtime so the type of these object is only known after invocation
12:43:17 <tangentstorm> i don't understand the code. that doesn't look like any language i'm familiar with 
12:43:17 <Mat2> because the caller can clone the object and change its behaviour on the fly
12:46:03 <Mat2> ok, another code snippet:
12:46:40 <Mat2> a := 1 new
12:47:35 <Mat2> a at: '1' PUT: '1.0'
12:48:34 <Mat2> ^here 'a' changed the type from integer to real
12:49:34 <Mat2> the new type can only be known after invoking a
12:50:34 <Mat2> or what about: 1 at: '1' put: '3'
12:51:56 <tangentstorm> i understand what you're saying but i don't think it's an issue for what i'm trying to do
12:52:52 <Mat2> probably I do not understand your point in depth
12:53:35 <tangentstorm> Mat2: part of the idea of a type system is that it encourages you to not write code like that :)
12:53:53 <tangentstorm> int <--> real doesn't really bother me
12:53:56 <Mat2> ah ok, makes sense
12:54:33 <tangentstorm> in fact i think that should be a transparent change... you'd just have a wrapper that implemented numbers
12:55:03 <tangentstorm> and that way you could deal with ints, reals, floats, complex numbers, big numbers with more than 32 bits, etc
12:56:01 <tangentstorm> oh. i see what you were saying about type systems.
12:56:15 <tangentstorm> and native code generation i mean.
12:57:53 <tangentstorm> hrm. yeah, i'm talking more like interfaces between objects, function/method signatures... that kind of thing.
13:00:51 <Mat2> C++ is a bad example for problems with static type binding. These operator overloading feature results in great effort for the compiler just for checking types because the state for each operator is not fixed any more
13:02:22 <Mat2> that is a crazy and mostly useless method which just wasting cpu ressources
13:02:52 <Mat2> (and cost energy)
13:03:34 <Mat2> I mean of each operator
13:05:40 <tangentstorm> yeah
13:29:26 * Mat2 testing all 256 instruction combinations one after another
14:28:14 <Mat2> go to bed, ciao
14:28:18 --- quit: Mat2 (Quit: Verlassend)
14:58:46 --- join: harrison (~quassel@li89-226.members.linode.com) joined #retro
15:26:50 --- join: deksarr33 (~AIX@88.252.147.175) joined #retro
15:26:58 --- part: deksarr33 left #retro
18:56:35 --- join: beretta (~beretta@cpe-107-8-120-84.columbus.res.rr.com) joined #retro
21:31:41 --- quit: kumul (Quit: WeeChat 0.3.9.2)
23:59:59 --- log: ended retro/12.11.30