I have a second person working on the code. That's an odd experience, it's sharing something that you've been working on for so long. It's hard not to take it personal at times. Fortunately the new guy is good.

Has decent ideas and is taking it in directions I wouldn't have thought of. Which is is the whole point.

separating characters

Right now gloo&gl is taken as a unique identifier. Because all characters that are not a number or string are taken as as an "atom"

By saying, all latin numeric characters form one set while everything else combines as something different would translate that into 3 identifiers gloo, &, and gl.

Makes it easier for doing functions and writing the code in general

Possible changes

I'm considering two possible changes for posl.

1. Separating ascii and special characters into different groups. This would allow for a condensed form of writing the code
2. Including an EOL indicator - This would be huge change in the structure and format that's allowed
   

looking for help

Finally decided that I need more eyes to view the code. So I put up a "for help" sign on sourceforge

jedit plugin is now compiling and is marginally functioning. Just haven't had the time to really dive into the details yet.

Well that just sucks

I don't get much time to work on posl. Maybe an hour a week. I usually do more thinking about it and design then actual implementation.

So I took some time and wrote a shell plugin for jedit. Got it working, and my system crashed before I could get it submitted to subversion.

Lets call it a kick to the teeth :)

Scala

I used to like Scala. Never found much of a need for it and I thought some of it's concepts were a bit off. But it was exciting and it was fun to play with it for a while.

But it's user base is really starting to turn me off of it.

I see scala fanatics running around and criticizing people for not liking it, or for thinking it's too complex, or for daring to work on a competing system.

Really?

Wow.

split is complete

Got the engine split off from the rest of the "language" now it's technically possible for you to restrict the DSL down to a few specific commands. Don't want math? Don't add it. Don't want functions? That can be restricted as well. All in a jar that under 20k

Oh, I left currying in, after all. I guess I'm just weak that way.

I also got highlighting working correctly in jedit. Working on adding a plugin to provide a shell based console.

Need to work more on the error handling/display. But hell I only get an hour or two a week to work on this

posl engine

I'm really excited about the updates I've been making to posl. I'm looking to tear the existing command structure out and focus on separating the actual DSL framework with the implementation. Creating an engine so to speak. The idea here is that by splitting the two, I can focus on the "how" things will work in a clearer manner.

What I want at this point is an ability to add, with no dependencies, a simple dsl that will allow you to do whatever you want it to, as long as you provide the underlying commands.

The trick is to make it extensible enough that you could write programs in it.

I mean, what I'm doing is overkill if you simply want a command line proxy to an underlying java object. But the ability to scope, define, pass functions, that's where the fun is.

Removing currying from posl

Part of the exploration in creating a language was to see what I could do with it. To see the edges that could be obtained. So I started off rather happy that I could easily support currying from a written function point of view. And what I mean by written function. Is that for functions that were written in the language itself I could rather support it. But for those commands that were implemented in Java, well that was a tad bit more difficult.

For a while I was fine with that, but then as I refactored I realized that just how ingrained as part of the language currying needs to be. It is one of those features that doesn't necessarily get bolted on, but it is part of the definition.

So as I worked on reducing the scope of what I was doing, I realized that currying would be confusing (partially implemented) or overly cumbersome (implemented to support the java commands) and did I really need it?

I mean I had a state based mechanism so currying wasn't as clearly needed.

Well, I've gotten to the point where I need to reduce cruft. My vision for posl is refining and at this point I will be removing currying.