idea: '.=' operator.

Example:

mystring = mystring.strip() ;
mystring .= strip() ;

Alternatively, no operator and sugar instead:

mystring = .strip() ;

'O' shit that's a lot of changes.

Here, have a 45 minute dump of everything I've changed about the O design (assuming I haven't forgotten anything...).

boxin.space/posts/2019/11/26/o

Ok time for shit loads of waffling about language design because I'm feeling existential about . Let's fucking gooooooo

design question: does this look tidy enough to not need lambdas?

something | where ( fn ( var i ) { ... } ) ;

equivalent lambda for the same thing:

something | where ( i => { ... } ) ;

note that with the first one, the method parameter can declare the parameters, so this would be possible too:

something | where { ... /* in terms of i */ }

Here, 'where' would be declared like this:

_enum<t> where( fn ( t i ).body ) ;

The tradeoff is it's really tidy, *but* the name of the "each" is fixed.

Thinking about and I'm wondering if an underscore prefix would be a reasonable style guide for interfaces, because I'm going for snake case and putting 'i' on the front of things could be ambiguous, but 'i_' uses up lots of space, so why not just '_'. Some examples:

interface _myiface ;

class someclass : _myiface ;

I think it looks ok.

Remembering that it's a style guide, so this would be what stdlib uses, but it's not enforced by the compiler.

On writing parsers

Thought I'd dump a bunch of the stuff I learned writing parsers into a blog post.

boxin.space/posts/2019/10/18/o

Ok, grammar draft number I-don't-want-to-think-about-it.

idea: localised strings.

Put a "l" before the string and the content of the string becomes the default value (and the key to the localised value). Then there would be some designated file or set of files that store all the localisations.

All you'd need after that is some easy means of telling the program what is storing the locale.

Basically syntactic sugar:
l"Hello!"
is sugar for:
localised_content["locale"]["Hello!"]
or there about.

Wew. I have just generated this finished action table from the example rules in the tutorial I was following. That means I now have all the real logic to build the .

Gonna create a repo on for this and then start refactoring it so it looks less terrifyingly bad, then I can start adapting it to the -specific use case.

Next up:
- More tea
- Put this in the
- Start coming up with the parsing bit rather than the generating bit.

Wew. Getting the to recognise identifiers with the broader character set wasn't nearly as tedious as I thought it would be. I'm pretty sure my implementation for it is really inefficient though.

This is just a bootstrap though and I'm learning as I go, so I'm much more concerned with making it work and making it understandable rather than perfect. The perfect version will be written in once this one is done ;)

Finished hooking up the to the compiler! It now both tokenises and dataifies the tokens and returns a nice big array of them ready to go straight into the , which will be the next project to start integrating into the main program.

Other things to do are to improve the lexer to support all the tokens to their fullest e.g. allowing underscores in number literals and the full character set in identifiers.

Well... I should probably clarify that the test files are currently empty, so I've successfully hooked up the to the point where it's correctly recognising the file is empty and returning no tokens.

The next bit will be to think up some random bullshit project that I can justify using multiple files for and write it in with no syntax highlighting or compiler feedback to help me...

Got a skeleton project for the compiler wrapper program just about done. Now I'm working on hooking it up to the .

It's currently identifying a project file and then enumerating all the files in the project, so it's just a matter of tidying up the lexer and having it go over all the files and turn them all into tokens.

Lots of refactoring to do.

New post!

O progress and plans. Plenty has happened, and there's plenty to do. Overall really happy with how this project is coming along considering how huge it is.

boxin.space/posts/2019/08/28/o

See the Ultimate FizzBuzzSplat code example on the website? 16loc (9 statements) which is pretty good, but here's one in 9 that looks *waaay* cooler (but with no syntax highlighting). All the logic is in a single statement. Makes use of the pipeline and anonymous piped methods mostly - also the "times concat" '*~' operator.

This is the shit I really love in programming.

projects will have a project file that would name dependencies and include information like licences, versions, and so on - all normal stuff. But what language should the file use?

Phew. That is one PHATT syntax spec all typed out nice and pretty, which means the site redesign is ready to publish! I'll get that done now and then put it up.

idea: Don't have 'out' parameters, but instead just allow variable declarations as parameters, which are declared in the current scope just like any other variable.

idea: 'expose' properties. Sort of like an alias. Say you have some class 'myclass' with a member 'attr' that has a member 'idk' but you want to access it directly rather than via 'attr'. Easy:

expose attr.idk as thing ;

Then interacting with myclass.thing is identical to myclass.attr.idk.

Could also be used for better access control on members, for instance myclass.attr could be private, but the expose could be public so other things can access just that one member and not the rest of the class.

Show more
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!