@mousetail Yes, I mean JS. To me "It infers types before compiling and if the types change it invalidates the compile" sounds like an explanation why "Without knowing types the compilation step has very little benefit" is wrong, but I'm not sure if you meant it that way

ooo, top users cap

@EldritchConundrum It proves my point? It needs to know the types before it can compile. Otherwise there is little benefit.

@MichaelHomer I guess for a non-procedural language you could gain some benefit to convert to a procedural form first but at that point but it's far less efficient than if you knew the types

I suppose there’s no point bringing up the obvious Forth, Python, Visual Basic examples here

Python compiles to bytecode and type resolving only happens at the bytecode interpretation stage

Well that sounds like a benefit

@mousetail But the types can always be known. No need to even infer it, you can just look at the actual types at run time. This means any dynamic language can be improved by compilation.

In all honesty I have to think that just treating JIT as equating to compilation seems like stretching things a bit

What you are saying is true. Many "interpreted" languages still have a bytecode compilation step or JIT compiler that provides various benefits. I'm going to think a moment how to rephrase my argument.

But it seems like mousetail has a very specific idea of “compilation” in mind that other people probably aren’t using, so everyone is talking past one another

These boundaries are always a lot blurrier than we tend to think in the abstract

Python is arguably compiled as much as Java is but we don’t think of it as such

And then modern high-performance specialising JITs can handle just about anything thrown at them with asymptotically equivalent results, no matter what information they started with

That is clearly true, yes, it’s sloppy language

Java, while almost everything is just an object that can't be optimized, does have primitives that can be known at compile time and thus be optimized. Specifically without a JIT compiler needing to collect data first

I visited Laurie a few years ago when the PyPy composition stuff was all going on

VM warmup is generally big enough that that stuff just isn’t going to make any difference

How would I define an AST node for an expression that returns a value?

Like, would it just be a union of a bunch of different types of value-returning expressions that could recursively include more ValueExpressions?

(yes, I did finish the lexer)

yeah, something like that

well…

speedruns boilerplate%

saw that one!

Obligatory disable ublock to use it, us jobs only

Colours!

it's really just reskinned Indeed

as mentioned in the answers to the meta post

@Ginger Yeah that's what we basically figured out straight away

???

We being the TL reaction party

mmm

tell them I say hi :p

I don't think expressions returning a string should be a union,

but half-decent code is not what I was designed to make

the shape of your AST is probably going to reflect the way the expressions are structured and parsed, rather than what type they have. It's often more convenient to process types after parsing, in a type-checking phase.

^

and your language with type-checking involved is proooobably not context-free

so trying to make that participate directly in parsing is just asking for headaches

@Someone but for structurally different kinds of expressions, yeah

oh well

time to throw away half this stuff

I'm just trying to figure out how to make an AST node for an expression that returns a value

unions are completely pointless, since if I have a node that has a value-returning expression as a child (like printing), I can't even pass in the child and then have the constructor pass it in to the class

since this->valueexp = valueexp is apparently UB with tagged unions

but what other pattern am I supposed to use!?

This is the wrong phase to be doing that in because if the expression is a function call you (probably) don’t know what type it will produce at this point

So you can’t have different node types for different types of produced value

The simplest thing to be going ahead with is probably a single-typed language (just int) so that you can ignore all of this and come back to it once you’ve gotten through the whole pipeline and have the experience

I mean for something like an addition expression

like, if I have one for an addition expression (with two ints), and one for just a plain int literal, I need to be able to handle both for my output statement

Why is that a problem?

There’s a member function on an AST node that returns a value when you call it

(If you implemented it that way, other ways work too)

If all your values are int this could literally just return an int, but a union of the language-level data types is fine too

isn't that duck-typey, though?

is that what templates are used for?

No?

I don’t see how templates could help here other than saving a little typing, you still have branching based on run-time data

But in any case, again, let’s suppose you only have the int type

There’s clearly no type problem then

but what I mean is, how do I define the type of stuff that returns ints?

int evaluate(EvaluationContext ctx)

A type that contains that member

All your evaluable nodes will have that super type and implement their local behaviour

This is just regular polymorphism

…no wonder why I'm having such a problem with it