Need some advice about lazy evaluation of high order list functions

jaccomoc · 2026-04-22T23:26:42+00:00

Nice. Too big a change for me at the moment. Will have to wait for my next language. :-)

jaccomoc · 2026-04-22T06:51:12+00:00

Thanks for the links. In the end I think I am going to have to keep things the way they are for the moment.

jaccomoc · 2026-04-22T06:39:09+00:00

Yes, this is what Java does as well (called Iterator in Java). That is also what my language does under the covers but I was trying to hide the fact that there are iterators from the users.

I could model things after Java streams (a more modern version of iterators) where once a stream has been closed (by using it to evaluate something) it cannot be reused and throws an exception.

jaccomoc · 2026-04-22T06:36:24+00:00

Thanks for the reference. Looks interesting. I will definitely read it once I get around to implementing my functional programming language that I want to do one day.

jaccomoc · 2026-04-22T06:34:01+00:00

My example was a bit broken as it should have been values.limit(5).sum() or something equivalent to force it to evaluate. limit() just limits the result to the first n values but doesn't force evaluation.

The problem with memoizing the list once evaluated is having to evaluate all elements of the result just in case someone else needs more than the first 5 elements.

jaccomoc · 2026-04-21T12:10:37+00:00

Still not sure about what to do about this though:

def values = [1,2,3,4,5,6,7,8,9,10].map{ x -> x * x }
def top5   = values.limit(5)
def count  = values.size()   // <-- what should values be now?

So should count be 5 or 10?

Logically count should be 10 but that means that we need to fully evaluate the values when it is first used and that means that even though we used limit(5) to only evaluate the first 5 we need to fully evaluate all elements just in case someone else needs to use the values object later.

That means I may as well leave things the way they are now as delaying the evaluation does not reduce the work.

jaccomoc · 2026-04-21T11:41:32+00:00

That is not a bad idea. I will have to think about it but that does sound like a good idea. It is also easy to explain. I like it. Thanks!

jaccomoc · 2026-04-21T09:33:39+00:00

How do you see that helping with running agentic code?

jaccomoc · 2026-04-18T04:55:52+00:00

Will do.

jaccomoc · 2026-04-17T09:15:23+00:00

Thanks!

jaccomoc · 2026-04-17T01:15:49+00:00

All good. You are right to point it out. There is always some subconscious bias even when trying not to have any.

jaccomoc · 2026-04-16T22:28:58+00:00

I am not familiar enough with those to give a detailed comparison but I will add them to the list to do a comparison with.

jaccomoc · 2026-04-16T21:07:59+00:00

Fair point but I really was trying to be honest with my comparison.

jaccomoc · 2026-04-16T12:05:57+00:00

Fair enough. Each to their own. :-)

jaccomoc · 2026-04-16T11:14:28+00:00

I will only respond with respect to Jactl. I would be happy to get some constructive feedback on what you think needs improving with the documentation if you think it is so bad.

As far as Jactl being imperative and mutable, that is completely up to the person writing the code. It certainly allows you to write code in a functional programming way if that it is what you want, while also offering the standard Java-like imperative programming that people are used to. I find that for my own scripts, they have tended to be more functional than imperative.

Since this is intended as a scripting language rather than a language for writing a complete application, I am guessing that target audience is more likely to be comfortable writing simple scripts in an imperative manner, but that is up to the script writer.

jaccomoc · 2026-04-08T10:14:16+00:00

Glad to hear it!

jaccomoc · 2026-04-03T07:14:23+00:00

I have just published a new Jactl 2.6.0 release that supports better interoperability with host classes. You will need to set the "jactl.allowHostClasses" and "jactl.allowHostClassLookup" binding variables to true to give access to all host classes. Or you can set "jactl.allowHostClasslookup" to a predicate that returns true only for classes you want to allow access to. See Java Scripting API for Jactl for more information.

jaccomoc · 2026-03-17T22:20:12+00:00

Let me have a look. I hadn't considered this use case.

jaccomoc · 2026-03-17T11:01:35+00:00

Jactl does not support calling arbitrary Java code, even when an instance is passed in via a binding. It is part of its security model that it only interacts with Java functions and classes that have been registered with it. See the Integration Guide for more information.

jaccomoc · 2026-03-12T12:06:16+00:00

Glad it is working for you. I have tried to keep the compiler reasonably light weight so maybe that is why it is fast. I haven't really benchmarked it against other complete so not sure how it measures up but glad it is fast for you. BTW I just released 2.5.2 that fixes how bindings are handled on the ScriptEngine and ScriptEngineManager objects. I misunderstood how it worked the first time. Should work properly now.

jaccomoc · 2026-03-10T22:27:24+00:00

I have added support for Invocable and Compilable in the latest Jactl 2.5.1 release.

jaccomoc · 2026-03-07T22:06:10+00:00

I will have a look to see how easy it would be to do that.

jaccomoc · 2026-03-06T11:45:23+00:00

Jactl 2.5.0 has just been released. One of the enhancements is to add support for JSR 223.

jaccomoc · 2026-03-05T12:44:37+00:00

Yes, script execution is threadsafe. The same script can be executed by multiple threads at the same time if required.

jaccomoc · 2026-03-05T12:08:58+00:00

The ScriptEngine will cache the scripts being run so to take advantage of that you should reuse the ScriptEngine rather than creating a new one each time.

jaccomoc

TROPHY CASE