> So you could presumably also set it up to implement its suggestions (i.e. if it "executes" its proposed definition for `succ` that would actually just update it in the global namespace). Fun stuff.
Yep, I've had that working in some earlier version of the tooling.
> I'd suggest rethinking this; people usually expect the tab key to auto-complete.
That's a fair point.
> At any rate, thanks for writing the description yourself.
I might let an LLM write the code, and even the user's manual, but I write my own blog post and comments. :-)
I work at ServiceNow, which sells an enterprise platform and a ton of products built on top of it.
Internal teams and customers can extend the platform by writing JavaScript, hence we have a JS runtime in the platform (the venerable https://github.com/mozilla/rhino/), which our team works on.
Same here!
I am now actually working in compilers, which is one thing I'm really passionate about, but not something I was doing professionaly. I managed to turn a toy project and some blog posts into an actual job at almost 40, so, thank you HN!
from gremllm import Gremllm
# Be sure to tell your gremllm what sort of thing it is
counter = Gremllm('counter')
counter.value = 5
counter.increment()
print(counter.value) # 6?
print(counter.to_roman_numerals()) # VI?
Of course I didn't assume to be 100% productive immediately, and I did spend a few weeks on this experiment, not just some days.
My point was more about how even modern C++ felt (to me) dated and annoying to use compared to more modern language, because of the strong (but very valid!) focus on backward compatibility that C++ has. Furthermore, the long history and baggage means that for any thing, there are _many_ different ways of doing it, which doesn't help.
And anyway, it was not a particularly serious (or, for that matter, well written or argued) discussion. As I mentioned in literally the first line, it's just a rant :-)
PS: I am unsure what you mean with "relying on LLM for configuring things says it all". In my experience, this is one area where LLMs _really_ do help a lot - it has been much faster than going through the documentation (which I also did quite a bit of, in particular for conan).
That sounds reasonable (and way better than what I have implemented).
I am not sure I am going to try it though - it probably is a bit too much code to change for something that I consider "done" and I am not working on. :)
Agreed, it _is_ annoying. It bubbles up everywhere and it feels like "something to silence the compiler" more than "something to express the safety of the code", as other people have pointed out.
Given that classes are managed by the arena, I know the reference will not be dangling thanks to the 'a lifetime.
Initially I had implemented this with raw pointers, without lifetimes, but then I switched to the reference because it felt more "idiomatic" and I had to put the lifetimes just about everywhere to make the compiler happy.
If there are better ways to do this, I would be really happy to learn, though!
I wanted to express the fact that everything that gets allocated (call stack, frames, classes, and objects) is alive and valid until the "root" VM is, thus I used 'a more or less everywhere.
I also struggled with a got a ton of errors from the borrow checker initially, and I fixed many of those with a lot of explicit lifetimes, but it's not impossible that in some places they are unnecessary.
Well, _I_ feel impostor syndrome half the times I open HN honestly!
I did have a bit of experience with VMs before, I wrote many years ago a short series of posts about it on my blog, and at my previous job I dabbled a bit in JVM byte code to solve one very unusual problem we had for a customer. I also read the _amazing_ https://craftinginterpreters.com/ years ago and that gave me some ideas.
But this project was definitely big and complex. It took me a lot of time, and it got abandoned a couple of times, like many of my side projects. But I'm happy I finished it. :-)
Indeed you are right, this is definitely a bug and could cause errors.
I guess the solution would be to add an explicit API to create a GC root, invoked by native methods (which is a bit complicated by the fact that I use a moving collector).
Many years ago I was using SpiderMonkey in a c++ project and I seem to remember there were some APIs for native callbacks to invoke that rooted values. Same problem and similar solution. :-)
About the generics - some people have pointed out the same on reddit, and yeah, you are correct. The only thing that should be done is to read the Signature attribute that encodes the generic information about classes, methods, and fields (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...)
As a matter of fact, I just did a test and the following code works! :-)
public class Generic {
public static void main(String[] args) {
List<String> strings = new ArrayList<String>(10);
strings.add("hey");
strings.add("hackernews");
for (String s : strings) {
tempPrint(s);
}
}
private static native void tempPrint(String value);
}
Yep, I've had that working in some earlier version of the tooling.
> I'd suggest rethinking this; people usually expect the tab key to auto-complete.
That's a fair point.
> At any rate, thanks for writing the description yourself.
I might let an LLM write the code, and even the user's manual, but I write my own blog post and comments. :-)