On-going LLL discussion

androloandrolo Jamtland, SwedenPosts: 36Member ✭✭
I want there to be an on-going discussion on LLL. Maybe there is, somewhere, and in that case I'd like to know. Otherwise why not have one here.

It used to be talk about LLL all the time in dev on skype, but there is hardly anything about LLL anymore.

I think it should not be as formal as when adding suggestions as issues in the github repo, this would be more of a "I want this and this is how I would do it, right or wrong" kind of thread. Basically just for fun.

So, this is what I think:

LLL works great! In general. I have very few complaints. A bit worried about 'include' being removed, but I suppose that is to merge with serpent include somehow (use the same file system stuff for everything), and generally just improve.

The macros was a true game changer to me. A milestone.

The one thing I'm missing now, that I think would be the next milestone, would be 'malloc' and 'free' operations for variables. Been thinking about this quite a bit. The way it currently works is that if you add a name instead of a memory address, it will have an address automatically assigned to it (starting from 0x80 it seems). Here's an example:

[test] 100

That would become [0x80] 100 after the switch (provided 'test' is the first variable to be defined).

If you use 'test' again, it will still be 0x80, so you sort of "implicitly" define it the first time you use it. @test would evaluate to 100.

Since this mechanism is already in place, what I would do personally is to simply add a command (malloc). It would then be possible to use defines: (def 'name (malloc)), which would call the same function that currently is used to assign addresses to variables.

This could be coupled with a (free name) operation to free the address tied to the name.

The benefit of combining it with (def) is that it could eventually use the already existing scoping mechanisms to auto free addresses when they go out of scope. Also, when improving later, I suppose allocation could happen automatically (without using (malloc)). Perhaps by using a different keyword (var 'name). Personally, I would be fine with doing manual malloc and free, but I guess it can and will be updated some time.

All of this is of course part of the pre-processing, and not added to the contract code itself.

Sign In or Register to comment.