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.
I'm a developer and code junky. I like languages, and the premise behind how and why people write the code that they do.
Tuesday, February 15, 2011
Monday, February 14, 2011
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.
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.
Subscribe to:
Posts (Atom)