Clojurians Log v2

I’m trying to run #C0F4MB8AY on #C0SBWN3AP. I’m getting a lot of warnings, which is cool. I’m also getting an error from prismatic.schema that clojure.core/refer* is not public.

@arrdem: I’ll dig in, but do you know off the top of your head?

Also, I had to upgrade my JDK and unset my JAVA_HOME to run it. Apparently I was pinned to Java 7

Aha, refer-clojure expands into refer*, which is now private.

It’s … refer madness

Argh. Did I break refer-clojure?

yes :simple_smile:

goddamnit.

Okay. I know why. Would you please open an issue? I'll try and hotfix this.

Sorry about that.

OK

https://github.com/jaunt-lang/jaunt/issues/132

Yeah I'm surprised that this didn't break the test suite...

@eraserhd: can you give me some details about what's breaking?

@eraserhd: :refer-clojure in a ns form will work just fine. Are you seeing a (refer-clojure ...) at the top level of a file?

I didn't think so. The problem is in prismatic schema.

can you post a stacktrace?

I did a quick grep, and didn't see anything weird, but I could have missed something. Jaunt is smarter about NS forms?

it's starting to be.

Sure. I'll be back at my computer in a few minutes.

thanks. Trying to repro on my end.

:refer-clojure definitely works in Jaunt 0.2.0, do you have a snapshot build?

(refer-clojure ...) as a top level form is definitely fucked.

It’s using refer-clojure in the middle of the namespace.

Okay. That's what I'm patching right now. I'll have a 0.3.0-SNAPSHOT build for you in a sec.

https://github.com/plumatic/schema/blob/master/src/cljx/schema/core.cljx#L103

why refer-clojure needs to be a macro not a fn is beyond me...

midje has a lot of deprecation warnings. I will submit a PR later. (all about ‘:use’)

Okay. Demoting refer-clojure to a fn from a macro takes care of this.

@eraserhd: [org.jaunt-lang/jaunt "0.3.0-SNAPSHOT"] now has a bugfix for this.

you should be able to just pull it down from clojars

@arrdem Cool! I shall do so in a short bit.

Take your time. I've got my commit for the day in 😛

@arrdem I think I’m getting further now

OH, let me lein clean

All tests pass!

w00000t

made my day 😄

pushed a patch to avi. Avi is now on jaunt

We'll see how long that lasts 😛

heh

back to implementing horizontal splits

Let’s try out this code reloading thing :simple_smile:

The ns reloading thing isn't in mainline yet 😢

sorry

turns out it's actually pretty hard. Will be the main feature of 0.3.0 tho.

Ah. :simple_smile:

The fn metadata stuff bronsa was helping me with was the main blocker to getting that out the door. Should happen this week.

Oh, I read your whole blogpost last night. Oxcart is so what I would do, had I time.

I’ve been on-and-off working on a lisp called Moreso.

In fact, Clojure was the last Lisp to study before making Moreso, and it kind of broke me.

Ha

I feel like something like oxcart would be better off as a language started off from scratch rather than piling stuff on top of clojure

too many edge cases to consider in order to adapt clojure

Yeah. Clojure definitely shows all the layers.

Yeah. Oxcart was a bunch of fun. We'll see how much of that and the strict clojure stuff I did with amalloy makes it into Jaunt.

Definitely agree wrt starting from scratch, but Jaunt is an exercise in avoiding those reinvention costs.

I think you can get within a small epsilon from what's already there.

btw @arrdem I was talking about oxcart/kiss at clojurex with @mtrimpe -- the "def as pure action over an immutable ns" thing has some non-trivial obstacles to overcome

e.g. handling forward refs & mutually recursive defs

Yeah. One of the main reasons I dropped the idea.

I spent a lot of time last year sketching out how to make def a fn from an env and an expr to an ev.

I think you’d need a module form, e.g. R6RS.

Yep. Your entire file ends up becoming an implicit module.

I think a clojure-y language would gain a lot more by having racket-style compilation stages than immutable namespaces

Which incidentally is pretty much where Jaunt is headed.

I haven't read anything about those.

(not that they mutually exclusive concepts, I don't think)

I think that the ns reloading changes I've got coming down the pipe address the primary shortcomings of the existing mutable nss.

but I'm not biased at all.

@arrdem: I'll link you the paper as soon as I can find it

@bronsa: thanks.

here's some context though https://docs.racket-lang.org/guide/phases.html#(tech._phase._level)

I need to read the Typed Racket paper and Ambrose's thesis too....

debating how far I want to push adding :arglist metadata to fns directly.

https://www.cs.utah.edu/plt/publications/gpce13-f-color.pdf here it is

@bronsa: I discovered that Clojure can't/won't emit an invokePrim call for a lambda because it uses arglist var metadata to find the prim hint 😕

yeah

which partially explains my crusade against people who alter :arglists

Hah.

Yeah. I'm all aboard that train.

I've been pondering whether it makes sense for defn to put metadata on the var. For instance doc metadata would arguably be more useful on the fn.

since the var itself doesn't actually have any usage...

up until 1.3 (I think) clojure used to store the metadata on fns

although deprecated only makes sense on the var.

or 1.2

sometime around those versions anyway

@bronsa: so I had this idea today... #:foo {:unqual 0 ::bar 1 ::baz/qux 2 'unqual 3 '/qual 4 '/alias/qual 5}

please no

lmao

'/foo made my eyes bleed

I mean... if it gets rid of :_/

and ' there is normal quote on eval.

the idea is just that you define / as a symbol prefix to mean contextual qualification same as :: on keywords does.

😞

I.. just don't like it

I understand that Rich considers it a syntax bikeshed, but I agree with you about : vs :: and think it's a critical one.

but yeah, I get what you're going for

shrug I've done my bit, not going to spend any more time arguing on that proposal

kinda hard to gauge if the syntactic tradeoffs being proposed are worth it without them giving us the full context

Yeah.

happy to at least know that macro grammars in some form or the other are likely coming in 1.9

(and that Rich is, indeed, still alive)

Those will be interesting.

I agree they're much needed.

I don’t think I’ve needed anything like this. Though I guess I understand the semantic thing.

It's Rich's language and he's gonna do what he likes with it.

The example I like is that core.async was gonna be baked into compiler.java until tbaldridge wrote the existing implementation...

or at least that's how I've heard the story.

eeeeeh

I'll take any other implementation over lexical transformations

One thought on the arglist thing... having that metadata on the Var allows hinted invocations in forward declared cases.