Manuel Simoni

"Even more bugs are inevitable, software is all going to become probabilistic now" is cope. "AI bug-finding means we have to embrace closed-source now" is a psyop. Writing buggy code has moved from hard to trivial. Writing secure code has moved from impossible to hard.

these days I explicitly seriously choose C and C++ for the unprecedentedly rigorous and complete form of memory safety they allow

@joseph_h_garvin @awelonblue @Ngnghm It's a generalized syntax for denotating/serializing arbitrary graphs of objects, something that people always end up adding to other formats like JSON. CL has it built-in from the start in its syntax.

@msimoni @awelonblue @Ngnghm What is this used for? Can't you express this without it already? It seems kind of niche.

One essential difficulty about programming is that while source code is essentially a tree, running code is essentially a graph. This appears clearly when trying to offer "source level" runtime introspection tools.

@awelonblue @Ngnghm (The identifier 1 exists only at read-time, and is not part of the parsed form.)

Just a tidbit: Common Lisp code is actually a graph, always. It has syntax for referring to other forms, e.g. to create the infinite list containing foo symbols, use '#1=(foo . #1#) The #1= gives the list the identifier 1 within this form, and the #1# refers back to this element. $ sbcl * (defparameter *foos* '#1=(foo . #1#)) *FOOS* * (subseq *foos* 0 3) (FOO FOO FOO)

"When I sat down to draft the personal section of this post and tried to summarize what I remembered most about BeOS, the file system was the first thing I named. That sentiment was common in 2000, and it has not gotten any less correct since." jdhodges.com/blog/bebox-bea…

Interesting article on generating your app as assembly code directly with a proof assistant blog.zksecurity.xyz/posts/end-codi…

@akater I can provide it for every object that can be serialized canonically. E.g. every JSON object with RFC 8785. Plus of course, I can provide it for many other objects, via something like Java's equals().

@msimoni ? There is no difference. For a hashtable, the equality predicate for keys must be provided. You can't provide such for arbitrary objects.

One of the biggest differences between the Lisp and Unix traditions is that in Lisp a name may contain any characters whatsoever without restrictions (you can even have a name that's the empty string), whereas in Unix you always have massive restrictions on the characters you can put into a name, and those restrictions explode combinatorially if you need to bridge multiple namespaces. Sad! Even Lisp could be improved though by allowing arbitrary objects as names, and not just strings. Why shouldn't you be able to use a picture or a structured datum as a name?

@akater What's the difference to a hashtable?

@msimoni …not just “complicated”; that's a relavtively minor issue. It becomes straightforwardly ill-defined. Equality for each “structured object” has to be defined individually. There is no universal definition thereof.

@ElucidationsPod You need _some_ escape character, at least in a plain text syntax, just like you need \ in JSON. But that's just syntactic. What matters is that underlying data can contain any character.

@msimoni What about with no pipe character?

@avoidant77 I've expected less, so I'm positively surprised

@MaineFrameworks I agree that threat modelling is warranted, I just don't think that it's that big an issue outside of well-known problem areas (domain names, email addresses, ...). It's not like people creating variables with 0 instead of O is a massive security problem. ;-)

@msimoni All kinds of code can be subtly compromised in this way, e.g. by declaring a variable with a similar name to a legit one. I don't know how common it is in practice.

Always funny how the idea of being able to use any character in a name ruffles some feathers. This is not some extreme high tech problem. You're able to use any character in a JSON string, aren't you?

@jameskjx Clearly the problem here is not that a name may contain arbitrary characters but that the query is constructed in an incompetent way (not using prepared statements)?

@msimoni "Why shouldn't you be able to use a picture or a structured datum as a name?" xkcd.com/327/

@MaineFrameworks Yes, if this is a threat to the system then it needs to be addressed (e.g. for usernames). Otherwise, like for filenames, it's typically not that big of a deal.

@msimoni What do you do bout character spoofing, e.g. malicious attacks replace c for something that looks like c.

@_Felipe I would guess that there are a billion requests per day to internationalized Wikipedia page titles. (Does it require special care, and should it be restricted for some use cases (domain names, email addresses)? Surely.)

@msimoni And that is a cause of many bugs. The devil is in interoperating with many parser implementations. Restricting characters enables (and is governed by) interoperability lessons learned from many failures.

@ElucidationsPod They aren't $ sbcl * (defvar |'| 1) |'| * |'| 1 * (defvar |#| 2) |#| * |#| 2

@msimoni I thought parens, delimiters, a pound sign, quotes, etc. were disallowed in a Lisp identifier.

@steve_massey @ElucidationsPod $ sbcl * (defvar |(hello world)| 12) |(hello world)|

@msimoni @ElucidationsPod No version of Lisp allows '(' or ')' in an identifier

@muwlgr Would I ever use a picture as a key in hashtable? Maybe. So why should my namespace prevent this?

@msimoni good counter-example, agree. but would you give your "1" a name represented by a picture ?