Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Antsan]

To be honest, I don't really know what Poslin could be useful for. My own efforts are almost purely for curiosity, although I certainly hope someone someday manages to do something practical with it.
Currently I see it as a kind of interactive compiler, so take that as you will.

I never used Forth myself, but I hear it has these big advantages: It is very close to the metal, it can be implemented quickly on any given platform and it has facilities to transform it into a very high-level language. I'm not sure exactly where it is used, but I think it was somewhere between research, rocket science, embedded systems and automation.

Stack based languages in general are relatively easy to understand, as the way they operate isn't very far from what the code looks like.
Compare that to C++ or Java, where what happens and what you see are very different things and learning how they operate is an entirely different process to learning to program in them. Learning Lisp (where the difference is way smaller) helped me considerably in understanding what compilers actually do and (unless I got something terribly wrong) programming in Poslin (not only programming Poslin itself) helped me further. I think.

[Tylui]

meeping to watch

[Antsan]

I've been thinking about how I name operations. Originally I chose to use names like `e->` and `e~<-o?` because I thought that using readable names for low-level operations like this would take away names from actual user code.

In hindsight, that seems like missing the point. Names aren't for avoiding name clashes. Packages are for avoiding name clashes. I'm intending to do packags at one point.

So now I wonder whether it would be sensible o rename everything so Poslin becomes more readable.

So, what now looks like this:

Code: [Select]

eo~~ ! eo~ !
e:
b* ! ~: ! [] !
e-> & <- !
b-> & <- !
& b<- ! e<- ! b<- !
would then look like this:

Code: [Select]

curr-op-env-bind ! curr-op-env !
env-get
new-binding ! dup-here ! [] !
env-lookup & push !
retrieve & push !
& store ! env-set ! store !
which is still awfully low-level code but, I think, way more readable.

Now I am wondering…
Should the operations operating on stacks be renamed or should they stay short (that is, operations like `<-`/`push`, `:`/`top`, `->`/`pop`, `_`/`drop`…)? `!`, `&`, `#`, `[]` and `<?>` definitely won't be changed.
I would need to rewrite the standard library. That doesn't bother me in the slightest and I guess nobody is eagerly waiting for me to finish this thing, so I don't see no reason why this should be a problem, but maybe I missed something.
Does somebody maybe think that the short names are actually more readable? I mean, `e~<-o?` is full of information when you know what the single characters mean. On the other hand it probably scares people before they even have a chance to try to understand.

Any opinions?

[kytuzian]

I think it's too confusing to have a name like "e~<-o". I have no idea what that means, and I'm sure it means something when you know what you're doing, but so does the (slightly) longer name ("eo~~" vs "curr-op-env-bind"). I also think "push" and such are only two more characters than "<-", so it would be worth renaming them for the readability and typing them wouldn't really any measurable amount of time longer.

Also have you ever, like, programmed in Poslin? As in created any projects of any sort.

[Antsan]

I have not done any projects in Poslin, not counting the standard library.

[kytuzian]

I have not done any projects in Poslin, not counting the standard library.

Ah. Well I think I might be interested in trying it out a little. How does one "do Poslin"? Like, installation and such. Nevermind I'm dumb just saw the thing in the initial post. It's been so long I forgot it was even there.

[Antsan]

Yay!
On which OS are you? If you're on Windows, you still need to compile yourself, probably with SBCL, as I only test on that.

I have now replaced all the names of the primary functions with readable ones. As the standard library has not yet been ported that version not yet available. I'm waiting with pushing to bitbucket till I get that done.

[kytuzian]

Yay!
On which OS are you? If you're on Windows, you still need to compile yourself, probably with SBCL, as I only test on that.

I have now replaced all the names of the primary functions with readable ones. As the standard library has not yet been ported that version not yet available. I'm waiting with pushing to bitbucket till I get that done.

I have both Windows and OS X, but I figured I'd just use OS X. Anyway I tried get SBCL but that didn't work out so I went with Clozure CCL instead. I got Quicklisp installed, but I'm kinda stuck now. You say where Quicklisp can find it...but where is that (I navigated to the directory and did

Code: [Select]

(ql:quickload "poslin") and it said:

Code: [Select]

> Error: System "poslin" not found
> While executing: (:INTERNAL QUICKLISP-CLIENT::RECURSE QUICKLISP-CLIENT::COMPUTE-LOAD-STRATEGY), in process Listener(4).

I've never used Lisp before if you can't tell.

[Antsan]

In the quicklisp installation directory there is a folder called "local-projects". Put the poslin folder (the one containing the "poslin.asd" file) there. Quicklisp, at startup, looks into this directory (among others) to determine which systems (non-lispers might call them modules, I guess) are available, by looking into sub-directories for *.asd ("another system definition") files.

Unfortunately I don't know how to compile (or whether it's actually even possible) in Clozure CL. You'll probably have to start from the Lisp REPL then.
Here's how:
1. load poslin

Code: [Select]

(ql:quickload "poslin")2. switch into poslin package

Code: [Select]

(in-package #:poslin)3. start REPL

Code: [Select]

(repl-dyn)or, if you want to load some poslin code in a file on startup (like the standard library)

Code: [Select]

(repl-dyn "/path/to/file.poslin")
Do you have any idea what you want to do yet?

[kytuzian]

Everything else worked properly, except for the very last step, as I get:

Code: [Select]

> (repl-dyn)
> Error: Undefined function REPL-DYN called with arguments () .

I don't know what I'm planning on making, I'll probably do some Project Euler problems to get acquainted a little then figure it out.

[Antsan]

Ah, that's because (repl-dyn) relies on functionality by SBCL and isn't defined when you're using something else.
Also,

Code: [Select]

(repl-dyn "some/path")
actually doesn't work.

This one should do the trick:

Code: [Select]

(repl (new-poslin))
If you want to load a file on startup:

Code: [Select]

(repl (new-poslin)
      "/path/to/file.poslin")
You can load multiple files this way – put each path into its own string, like this

Code: [Select]

(repl (new-poslin)
     "/path/to/one/file.poslin"
     "/path/to/another/one.poslin")


[Antsan]

I now pushed the changes with the renaming to bitbucket. A version of Poslin with readable names now can be compiled from the "readable" branch. The standard library still hasn't been updated.

This branch changes the operation which creates a fresh environment to return a constant instead of always creating a fresh empty environment – anything but the path itself and bindings is immutable either way.

There is a new primary operation, `env-symbols`, which pushes a stack containing the symbols defined in the consumed environment onto the current stack. This will later be useful when optimization passes are implemented, which then can just be mapped over the already defined operations.
Related question: Is there any language that can implement optimization passes for itself and apply them to code in a running image?

[Antsan]

I guess it's okay to triple post here…

I am proud of what I managed to do today. You see, I had started on re-implementing the standard library with the new names for operations and I did that by just replacing the old with the new names.
Then I remembered that the standard specifies operations in two big sets: One set of operations that need to be primary and one set that might or might not be primary. That second set is implemented by the standard library. Allowing these operations to be primary is so that some hypothetical poslin implementor might suply more efficient versions of these operations as primary operators. With the required primary operators a swap on the current stack can only be implemented this efficiently.
I also don't want implementors to be required to implement the standard library themselves. Any implementation should run fine with the standard library as I write it.
This doesn't really work out that well if the implementations of operations in the standard library just overwrite the primary operations the implementors provide. So, when defining an operation, the standard library first needs to check whether it already is implemented and then only write the operation, if it isn't.

I just finished the first operation in the standard library. It is gloriously hideous. Fortunately the standard library will rectify this.
It looks like this, minus the comments, as these aren't implemented yet (remember, comments are a part of the standard library, not of the reader):

Code: [Select]

;[ This paragraph checks whether the operation `curr-env` is already defined ];
0 path-access ! OP env-lookup ! retrieve !
curr-env env-lookup !
.nothing ! same? !  ;[ at this point, there's only a boolean on the stack – if it is <TRUE>, the operation isn't defined yet ];

;[ now I construct the branch that needs to be executed, when the operation isn't already defined ];
.empty-stack !  ;[ that whole branch needs to be put into a stack; `[` and `]` aren't available, so I have to do this the hard way ];
0 path-access ! OP env-lookup ! push !
0 path-access ! OP env-lookup ! retrieve ! push !
curr-env push !
new-binding ! push !  ;[ this binding needs to be duplicated (as bindings are consumed by storing into them), thus the following two lines ];
0 path-access ! STACK env-lookup ! retrieve ! top !
top ! push !
.empty-stack !  ;[ this is the stack that will be converted into a thread to be stored as operation ];
  0 push !
  path-access & push !
& # push !  ;[ convert the stack into a thread and make a constant thread returning that thread ];
store & push !
env-set & push !
store & push !

. &  ;[ do nothing if the operation already is defined ];

;[ the following just puts back the correct branch and then calls it ];
<?> !
!
I am happy to answer any questions you might have.

[kytuzian]

Ah, that's because (repl-dyn) relies on functionality by SBCL and isn't defined when you're using something else.
Also,

Code: [Select]

(repl-dyn "some/path")
actually doesn't work.

This one should do the trick:

Code: [Select]

(repl (new-poslin))
If you want to load a file on startup:

Code: [Select]

(repl (new-poslin)
      "/path/to/file.poslin")
You can load multiple files this way – put each path into its own string, like this

Code: [Select]

(repl (new-poslin)
     "/path/to/one/file.poslin"
     "/path/to/another/one.poslin")


Alrighty it works...ish. I can add things to the stack but '!' doesn't do anything. As in, when I type it, I get

Code: [Select]

[ 2 3 + ! ]

And it doesn't evaluate to 5 as I expected. Am I doing it wrong or...?

It possibly has something to do with this error I get when I start it up:

Code: [Select]

;Compiler warnings :
;   In an anonymous lambda form at position 6: Unused lexical variable SELF


[Antsan]

Urgh, I'm stupid. Sorry about that.

Code: [Select]

(repl (new-poslin *prim*))
I downloaded CCL and after doing some fruitless bug tracking I realized what the problem was and tried this. It works on my computer.

The macro `new-poslin` takes a list of variables containing a list of primary operation descriptions so these can be defined. So, if no primary operations actually are defined, it's no wonder when calling `!` doesn't do anything – there is no such operation and it's not immediate yet.

Once again, I'm sorry for that.
I don't know about that warning, it seems inconsequential. If I knew where it was coming from, I might be able to fix it, but there's no hint at where that lambda is coming from or anything, so…

A word of warning: CCL will throw an error about exhausting the stack or something like that when you QUIT the repl while a sufficiently large environment is on the current stack. This seems to be because the printer runs out of memory trying to print all the stuff in the environment. If you don't want this to happen, run the REPL like this:

Code: [Select]

(progn (repl (new-poslin *prim*)) (values))
This returns nothing, so nothing needs to be printed.