A macro is a function that takes in parsed code and returns transformed code.
The nice thing about macros is that they run during the parsing of the code, so they have no runtime cost associated with them.
Basically, you can think of it as a (limited) way for users or packages to add new keywords to a language without having to change the whole language implementation for everyone.
Many recent new keywords that were added to Python could have been implemented as macros, which means that they could have just lived in packages rather than needing to be upstreamed into the base language implementation from day 1.
Yeah, that was rather puzzling. Hopefully if this proposal garners any interest, some people with actual experience with dealing with macro hygiene issues can help fix that.
IMO Python really needs this. Working in a language without syntatic macros is such a downgrade, and there's been a number of syntax features added to the language over the years that IMO should have just been macros.
> The f-string `f"..."` could be implemented as macro as `f!("...")`. Not quite as nice to read, but would still be useful for experimenting with.
In julia, we have a rule where a macro whose name ends with `_str` is usable as a "string macro" and it receives the input string in its raw form, and then any string macro is usable by just prefixing the name at the beginning of the string.
An example is that our regex string literal implementation is literally just
macro r_str(s)
Regex(s)
end
which allows for easy compile-time regex generation. With that you can simply write e.g. `r"^[ \t]+|[ \t]+$"` which is the same as `@r_str("^[ \t]+|[ \t]+$")`, e.g.
Well they should coexist, as all string formatting syntaxes have over the years. And though I think macros would be nice to have, there's a valid concern raised in the discussion: readability. Having macros opens the door to extremely unpythonic code bases, which could be very hard for anyone outside of the primary audience to understand, let alone meaningfully modify or contribute to. And one of the things that keeps me hooked to Python is that if I install a package and it has some issue or doesn't do something I'd like, it's almost trivial for me to find the relevant section in the installed code, edit it and have the desired behavior on next invocation.
It doesn't just make sense in the very far north, it makes sense just about anywhere that you'd have many people living close together (i.e. even a village).
Most homes don't need to have their own electricity generators, their own sewage treatment systems, or their own water wells, they hook into utility infrastructure.
In a lot of european towns and cities, heat is also a utility you can hook into, e.g. my apartment has no heating infrastructure in it, we just get all of our heat through a pipe connected to a nearby heat reservoir that's primarily loaded with waste heat from a gas power turbine. Within the next couple years though, the heat from gas power will be supplemented with the biggest heat pump in the world though [1]
It's not just a city thing though, I have friends who live in a village of 300 people in the Alps and they also have a utility district heating system in the village.
Well, this has already taped-out whereas the entire reason people call the tachyum prodigy vapourware is that they keep missing their target dates for tapeout and keep delaying it.
White label reseller isn't really the right term. They don't design most of their components and buy them wholesale, but they do assemble them and most relevant to this particular comment thread, they do a lot of the device firmware and support stuff.
It's exactly the stuff that they actually do themselves that Qualcomm has been making very hard.
Some someone who learned document editing and drafting through LaTeX in my undergrad, I gotta say I'm not sure I'd recommend it anymore to people looking for a new tool.
To me, Typst is the 'weirdly missing' option here. I really see it as the most promising successor to LaTeX, which is not something I say lightly given that I spent years scoffing at the idea of Typst ever displacing LaTeX in my life.
I watched Typst from afar for many years. I finally took it out for a spin about a month ago after version 0.14 dropped.
In less than an hour I reproduced my résumé—complete with fancy functions to typeset employment entries on a grid system. In under 24 hours I was tinkering with the Typst source code.
Typst is amazing. Syntax is clean and consistent. The compiler is so so fast. Docs are excellent. And it is very close to TeX when it comes to typesetting quality. There are a few tiny rough edges that any \usepackage{microtype} enjoyer will miss, but stuff is improving rapidly.
(Also, XKCD disclaimer: this was not an LLM—I just use em-dashes a lot because TeX made them easy to type and I got used to having them.)
Typst seems to be a cloud based solution with monthly fees? How’s that even relevant to the discussion of open source, free, local tools like latex/markdown?
Absolutely not, no. At least not any more than LaTeX is a cloud based solution with monthly fees (Overleaf)
The language, ecosystem, and compiler are FOSS. There is a cloud editor / collaboration platform that is paid, but nothing about the language requires that you use it (I use it almost exclusively through emacs)
No, Typst the typesetting software is FOSS (Apache license), as is a bunch of the surrounding ecosystem (e.g. the LSP for editor support). The people making it also ofter paid SASS stuff for features enterprises like, but there is no need to use them.
> why not just compile a static but generic version of the method with branches based on the tags of values? ("Can't figure out the types, wait until runtime and then just branch to the specialized method instances which I do know the types for")
This is exactly what the new AOT compiler (juliac) does. The original article is just a bit inaccurate.
The problem though, is that if you have a truly dynamic call-site where you have no idea which method body will be called, then the AOT compiler can't know if the right method specializations will survive the trimming process, so you'll get errors or warnings when compiling with the --trim feature active (--trim is what is used to make the AOT compiled binaries small).
However, there are still lots of cases where you can have a dynamic dispatch but can convince the compiler that there will be an already compiled method signature for every possible specialization. In that case --trimm will work fine and do exactly what you described above.
It's certainly not an existential threat to Playstation, but Xbox certainly has weakened itself enough that yes, this could be another nail in the coffin, given that their plan was to retreat into the Windows ecosystem.
The low specs aren't a problem if it's cheap enough, but for every dollar this goes above the retail price of a PS5 will seriously hurt its mass appeal.
The problem for Valve is that they can't really sell this thing at a console-like discount, because it's a general purpose computer. If this thing is way cheaper than a regular computer of the same spec, corporations will just buy up Steam Machines by the palette load and use them as office machines or whatever (just like what happened to Sony when they allowed the PS3 to boot into Linux and they had to release an emergency update that disabled the linux functionality even though it was an advertised feature).
I really hope this will be successful, but it'll likely be successful in a specific niche. The nice thing though about this niche is that they don't have to hit anywhere near the same sales numbers as a console to be a success because the R&D costs are lower, and games didn't have to be specifically tailor made for it.
E.g. the PS Vita sold more units than the SteamDeck, but the Vita was an unmitigated failure for Sony because unlike the SteamDeck, the Vita needed games to be specifically made for it, whereas the SteamDeck benefits from the entire PC ecosystem so doesn't need the same level of adoption to be a (limited) success.
> If this thing is way cheaper than a regular computer of the same spec, corporations will just buy up Steam Machines by the palette load and use them as office machines or whatever
Sure, but corporations don't want/need the same spec. They don't need the GPU, they don't need the fancy controller. If you just want a cheap PC that'll run a browser and Office, you can get them for under $200. If you want a Beelink with CPU/RAM/SSD similar to the Steam Machine, that's $350, and it includes a Windows license. Steam machine has an estimated BOM of $425, so even $500 will be a subsidized price after overhead. As long as Valve prices well above $250 it'll be safe from this concern, since corporations will likely want to add a Windows license to the cost.
> It's certainly not an existential threat to Playstation
To add to this, PlayStation is almost entirely sustained by exclusives at this point, and it's starting to backfire (more and more players are just waiting for the PC release, and the wait is killing some of marketing/hype that a game would have had, e.g., FF16 likely would have done a lot better if it released for PC at the same time rather than starting with PS exclusivity, and I suspect Death stranding 2 will be the same
> If this thing is way cheaper than a regular computer of the same spec, corporations will just buy up Steam Machines by the palette load and use them as office machines or whatever
On one hand, this would be a problem.
On the other hand, if the Steam Machine doesn't support windows, businesses fleeing from MS Windows en masse because the Steam Machine is cheap would be a VERY interesting turn of events, and I'd be VERY curious to see how it all unfolds.
Sorry if I was unclear, but what I was saying was that this would be unsustainable because the only way it'd be possible is if Valve was subsidizing each unit in hopes of recouping their losses on Steam game sales.
If that happened, Valve would get bankrupted by companies buying up subsidized Steam Machines with no intention of playing games on them.
Yes that's what I understood. But it'd still be insteresting.
Amazon was once a bookstore. There's nothing stopping Steam from adapting to a "Steam Business Machines" / "Steam OS Business Edition" once it has a foothold in the business market. After all, the store already distributes software, they're just not as popular as games. So if this scenario were to happen, and Microsoft failed to react, I'm sure Steam would adapt very quickly to take advantage of it rather than sit and wait for the bankruptcy.
The nice thing about macros is that they run during the parsing of the code, so they have no runtime cost associated with them.
Basically, you can think of it as a (limited) way for users or packages to add new keywords to a language without having to change the whole language implementation for everyone.
Many recent new keywords that were added to Python could have been implemented as macros, which means that they could have just lived in packages rather than needing to be upstreamed into the base language implementation from day 1.
reply