From 02693e2b9590bed4bc7b1f9c0b56bad6b7e0f4e1 Mon Sep 17 00:00:00 2001 From: Torsten Ruger Date: Fri, 18 Sep 2015 11:06:41 +0300 Subject: [PATCH] adjusted name --- _posts/2015-09-03-a-new-language.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_posts/2015-09-03-a-new-language.md b/_posts/2015-09-03-a-new-language.md index 4cf9912..b1fa5f8 100644 --- a/_posts/2015-09-03-a-new-language.md +++ b/_posts/2015-09-03-a-new-language.md @@ -49,7 +49,7 @@ is a tree, not a list, as demonstrated by the parse *tree*. Flattening it just c problems. Also as a metal model it is easier, as it is easy to imagine swapping out subtrees, expanding or collapsing nodes etc. -## Saml - SalamA Machine Language +## Bosl - Basic Object System Language ### Typed @@ -65,12 +65,12 @@ all the time dynamic. The way i had the implementation figured was to have different versions of the same function. In each function we would have compile time types, everything known. I'll probably still do that, -just written in saml. +just written in bosl. ### Object c The language needs to be object based, off course. Just because it's typed and not dynamic -and closer to assembler, doesn't mean we need to give up objects. In fact we mustn't. Saml (working +and closer to assembler, doesn't mean we need to give up objects. In fact we mustn't. Bosl (working name) should be a little bit in like c++, ie compile time known variable arrangement and types, objects. But no classes (or inheritance), more like structs, with full access to everything. So a struct.variable syntax would mean grab that variable at that address, no functions, no possible @@ -91,7 +91,7 @@ That can obviously read itself and anything else, so the start small approach is Also, when writing the debugger, i found that parslet is not opal compatible and that doesn't seem to be changing. So, casting the net, i found Citrus which is small and clean without *any* runtime dependency (a great feat). Citrus has a grammar, and i find at least it looks nicer than the ruby -grammar code. So for saml it will probably be that and as small a syntax as i can get away with. +grammar code. So for bosl it will probably be that and as small a syntax as i can get away with. ### Interoperability @@ -138,8 +138,8 @@ So writing a ruby compiler by writing a ruby interpreter would mean writing the interpreter in c, and (worse) writing the partial evaluator *for* c, not for ruby. Ok, maybe it is not quite as bad as that makes it sound. As i do have the register layer ready -and will be writing a c-ish language, it may even be possible to write an interpreter **in saml**, -and then it would be ok to write an evaluator **for saml** too. +and will be writing a c-ish language, it may even be possible to write an interpreter **in bosl**, +and then it would be ok to write an evaluator **for bosl** too. I will nevertheless go the straighter route for now, ie write a compiler, and maybe return to the promised freebie later. It does feel like a lot of what the partial evaluator is, would be called