Clojurians Log v2

@danielmartincraig I finished what I think I will do for now re data/time (in upcoming 0.1.88 release). I added the java-time.api library which you can access using the java-time namespace. I also added std/now . Here's some things you can do:

$ ys -pe 'java-time/instant()'
#object[java.time.Instant 0x5db4dbd5 "2024-12-26T17:31:30.014227Z"]
$ ys -pe 'java-time/instant().str()'
"2024-12-26T17:31:40.491337Z"
$ ys -pe 'java-time/instant():S'
"2024-12-26T17:31:47.035015Z"
$ ys -pe 'now()'
#object[java.time.Instant 0x3127c400 "2024-12-26T17:31:56.568229Z"]
$ ys -pe 'now():S'
"2024-12-26T17:32:01.390080Z"
$ ys -pe 'now().split(/[^\d]/)'
["2024" "12" "26" "17" "32" "13" "162033"]
$ ys -pe 'now().split(/[^\d]/).take(3).join("-")'
"2024-12-26"
$ ys -pe 'now().split(/[^\d]/).drop(3).take(3).join(":")'
"17:32:43"

I'm wondering if std/now should return utc or zoned...

Maybe both with:

now(:utc)
now(:zoned)

if std/now defaults to UTC I think that would be best.

UTC has the advantage of being the same on my dev machine and in the cloud. It also is more predictable when daylight savings is coming up

but a function called localnow could be a nice convenience for those that really just want local time

aye, but now() is a minimal convenience function for quick scripts and one liners. You probably want to be using java-time in real code:

$ ys -pe 'java-time/instant():S'
"2024-12-26T17:45:38.323953Z"
$ ys -pe 'java-time/local-date-time():S'
"2024-12-26T09:45:50.906428"
$ ys -pe 'java-time/zoned-date-time():S'
"2024-12-26T09:46:13.306874-08:00[America/Vancouver]"

$ ys -pe 'str(now())'

Ironically I'm not in America/Vancouver I'm in Toronto, 3 hours east

this is due to some java caching thing 😕

Oh cool, I'm interested in attending UBC

I'm usually in Seattle

UBC++ Vancouver++ 🙂

I used to live in Vancouver

ok well I'll default to UTC then and add

now(:local)
now(:zoned)
now(:utc) 

That's the more cloud-forward thing to do in my opinion

Easy to redefine (in a local context) if you want 🙂

$ ys -e 'now =: \(std/now :zoned)' -e 'say: "Now is $now()"'
Now is 2024-12-26T10:01:36.131175-08:00[America/Vancouver]

@danielmartincraig datetime stuff committed and pushed to: https://github.com/yaml/yamlscript/tree/devel You can build/install ys from there with:

make -C ys install

awesome, thanks!

That's a good question. Playing around with it at the airport. Looks like java.util.Date and java.time.* are not yet exposed. I can fix/release that tonight. This works now:

$ ys -pe 'System/currentTimeMillis().quot(1000)'
1734457315

$ ys -pe 'sh("date").out:chomp'
"Tue Dec 17 09:47:47 AM PST 2024"

It would be nice to have a clean datetime api in ys. Any ideas?

I'm a huge fan of java.time.*

I would be happy just to have java.time.* exposed

by contrast, I really dislike java.util.Date and find that it usually leads to problems

Safe travels!

sorry to take your time while you're on the go

np, and thanks. I will definitely expose java.time classes. Hopefully they are not very big. Should go out today. I also want a std/datetime that handles common datetime ops. But that can wait until I like it. Looking at https://momentjs.com/docs/ for inspiration. I remember liking it.

https://github.com/babashka/babashka/blob/c89ac0bd7fdd95c715bf0f4bfd85943049e34599/src/babashka/impl/classes.clj#L430-L470 That's a whole lot of time...

And guarded by a feature item. https://github.com/babashka/babashka/blob/c89ac0bd7fdd95c715bf0f4bfd85943049e34599/src/babashka/impl/classes.clj#L429 How do people typically do what you want in bb?

$ bb '(java.time.LocalDate/now)'
#object[java.time.LocalDate 0x69ac4fb1 "2024-12-17"]

It's not very urgent; there was a task I needed to do that seemed like a great choice for bringing yamlscript to work, but I was able to fall back to Python instead

so my needs are covered for now

The other thing I observed is that YAMLscript seems like it can't do a string to string alphabetical comparison with > or <

like, "abc" > "aaa" would not be a valid comparison in ys

I was attempting compare datestrings alphabetically (not advisable, but I was just trying everything I could think of)

I can make "abc" > "aaa" work and I don't have a problem with that since "abc" + "aaa" already does work

Infix + is polymorphic, where prefix + is normal clojure:

$ ys -ce '(a + b)'
(add+ a b)
$ ys -ce '(+ a b)'
(+ a b)

if perf matters

That's a general YS principal. You can make YS compile how you want.

OK gotcha thanks for the explanation

Here's a good example:

$ ys -pe 'range().take(5)'
(0 1 2 3 4)
$ ys -pe 'range().take(5 _)'
(0 1 2 3 4)
$ ys -ce 'range().take(5)'
(+take (range) 5)
$ ys -ce 'range().take(5 _)'
(take 5 (range))

like as-> threading you can state where the LHS goes, but for most core functions you don't need to. You'll pay a runtime perf penalty by not using _ , but generally you probably don't care. You don't need to remember the arg order of take.

$ ys -pe '5.take(range())'
(0 1 2 3 4)

if you care about take over +take you add the _.

I almost never use the _ in my YS programming.

@danielmartincraig I have at least 4 hours to kill on this layover, so I'll work on those things now.

Interesting, I'm sure the penalty is very minor in this case though right? I don't think it should be too bothersome in general

say that collis set to range() and num is set to 5 ... there's so many ways to take 5 in ys:

(take num coll)
take(num coll)
coll.take(num)
num.take(coll)
coll.take(num _)
num.take(_ coll)
take: num coll
take num: coll
take num coll:
call('take' num coll)
-"take".call(num coll)
call: -'take' num coll

the ys compiler can be made smarter in the future to generate faster code when it knows the argument types at compile time.

> I'm sure the penalty is very minor in this case though right? but yeah, I rarely need to think about it.

https://clojurians.slack.com/archives/C0GLTDB2T/p1733605641742229?thread_ts=1733549106.914809&amp;cid=C0GLTDB2T is from #adventofcode where I showed YS side-by-side with the Clojure it compiles to. Using a little YS script to format it: https://github.com/ingydotnet/advent-of-code/blob/main/bin/sbs In general YS has ways to make code really minimal. I of course realize the benefits of coding things in all lisp (I'm a Clojure programmer after all) but for YS it makes more sense to offer alternate forms that fit well into YAML. When I'm writing YS code, lisp/clojure is my assembly language! 😄

Having written other transpilers in the past (but not to lisp) I would say that lisp is a great language to compile to.