kazinator

34,821 karmajoined hace 12 años

Working on the TXR language: https://nongnu.org/txr

Want to talk to me? Drop me an e-mail:

[email protected]

This could change without notice; check the profile.

Git repositories: https://www.kylheku.com/cgit

Mastodon: @[email protected]

LinkedIn: https://www.linkedin.com/in/kaz-kylheku-8a8b94197/

meet.hn/city/49.2608724,-123.113952/Vancouver

Socials: - kazinator.at.hn

---

comments

hace 4 horasdiscuss

"Need" is a very tenuous word, because most of any tool stack consists of benefits.

End users benefit from things that they don't strictly need.

Once you start talking about what people don't need, it's hard to do it in a way such that they need Lisp but don't need macros.

Sometimes "need" is about dependencies; i.e. things you "need" are provided by upstreams; you stop needing things that you made yourself.

E.g. "I don't need objects. Because, well, I have lambdas and macros, and with that control over syntax and semantics, I made my own objects. So, strictly speaking, I do need objects, just don't need them from you or anyone else."

People disagree over what constitutes a benefit; something someone finds beneficial in their work is crap to someone else, and the easiest way to disparage someone else's beneficial thing is resort to the necessity rhetoric.

"Everything that I found beneficial in conducting my successful XYZ project, which got to a level of complexity and quality in so many years of effort and lines of code, was obviously necessary; all else is unnecessary."

A really sneaky way to do that is to repeatedly acknowledge the benefit of something while emphasizing the lack of necessity. With a sprinkle of FUD about possible harms that outweigh benefits ...

hace 4 horasdiscuss

In two's complement, calculating the overflow for addition is nearly exactly as complex as calculating carry for unsigned arithmetic.

Various versions of the Motorola 68000 programmer's manuals have a table which succinctly shows the Boolean formulas for calculating the flags for various operations.

In the following document it is Table 3-18. Integer Unit Condition Code Computations:

https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf

The ADD operation is in the second row of the table. See how in the right column, the calculation of C (carry out of highest bit) and V (overflow) have about the same complexity. V has only two "not" inversions compared to C's three, but otherwise both have six operands reduced via five "and" or "or" operations. C is a sum of two three-term products, V is a sum of three two-term products.

These calculations assume that we perform the addition as unsigned, and so we then have access to all three operands: the S, D, and R (source, destination and result). (That terminology is specific to the MC68K whose instruction set doesn't support the result going to a third operand which is not one of the two input operands.)

All the difficulties come from the higher level language semantics that don't provide a way to safely perform an overflowing operation and then detect overflow from a calculation applied to the two inputs and result.

I.e. some assembly-language-like "higher level" languages make things worse than assembly language, for the sake of abstraction and portability.

In a language that has arbitrary precision integers, you'd pretty much never want them unsigned, or even to have signed and unsigned flavors.

Whether unsigned or signed is better is a matter that is a combination of personal opinion and the quirks of a given systems programming fixed integer language.

The trade-off reasoning would be different, for instance, in a language that requires implementations to provide two's complement signed integers, with wraparound semantics. Or, say, no wraparound semantics but a robust overflow detection system coupled to exception handling.

There are other matters beside overflow, like conversions. In C, mixtures of signed and unsigned bring in some implementation-defined conversion rules, which nudges the argument toward "all unsigned" or "all signed" for the sake of avoiding mixtures.

I like to trot out the following argument.

Suppose a, b and c are small integers close enough to zero that any additive/subtractive combination of them is free of overflow.

If they are signed, then we can make inequality derivations like

  a + b < c

      b < c - a    // subtract a from both sides; "bring to other side"

If they are unsigned, then we cannot do this. That is a barrier to refactoring code with arithmetic conditionals and just reasoning about it.

It's acted as a road-concentrating hub to simplify logistics.

If you have an interpreter only, no compiler, using macros for metaprogramming anwyay at least prepares you for the eventuality that one day there will be a compiler. The macros will Just Work as before, only the expanded code is now processed by compiling.

Suppose you reject the idea that there will ever be a compiler. Macros are still useful for doing "compiler-like things" in the context of interpretation, like transforming code into something that will interpret better.

We can regard the interpreter as a virtual machine acting on a representation of the code; the macro system lets you manipulate the representation in a pre-computed pass, which has no further cost at run time.

If you have a code expansion pass on top of an interpreter, for supporting macros, you can use that as an excuse to perform built-in code transformations that are not macros; those enable you to have more flexibility in how special forms are implemented.

In TXR Lisp case is a macro (family) which performs certain optimizations like recognizing values in a range and emitting a table switch. This works interpreted or compiled:

  1> (macroexpand '(case x (1 'a) (2 'b) (3 'c) (4 'd) (5 'e)
                           (6 'f) (7 'g) (8 'h) (9 'i) (10 'j)))
  (let ((#:test-0005
         x)
        (#:swres-0007
         '#:nohit))
    (and (integerp #:test-0005)
      (<= 1 #:test-0005
          10)
      (sys:setq #:swres-0007
        (sys:switch (- #:test-0005
                       1)
          #(('a) ('b) ('c)
            ('d) ('e) ('f)
            ('g) ('h) ('i)
            ('j)))))
    (if (eq #:swres-0007
            '#:nohit)
      (progn) #:swres-0007))

It is faster to do some checks and interpret the sys:switch special form to dispatch by a numeric index than to do a large number of exhaustive comparisons.

Ultimately, the way we optimize interpretation is by compiling, but it can still be worth it to have better interpretation here and there.

You don't want to do this kind of optimization at run-time; you don't want the interpreter to be evaluating the condition "are these cases integers (or characters) in a tight range?". That's a property of the syntax in which the cases are constants; it wants to be pre-computed once.

Not all Lisp dialects have well-developed hot patching systems. The OOP system has to be carefully designed for it. What if a class definition is superseded by a reload, but there are existing instances? The Common Lisp dialect of Lisp has useful answers to questions like this, but not necessarily every Lisp you come across.

Even Bash supports hot-reloading. I've developed modules that are updated in place by sourcing:

   $ . /path/to/script.sh

A version of this font with more chord shapes in it would be useful, like say CMaj7:{digit1-9} would yield different fingerings/voicings for each trailing digit value. You could put together a chord progression that has reasonable voice leading, and could be mostly played as written.

Alex Kenis put to the test the hypothesis that since guitar pickups with blade polepieces present a more or less horizontally uniform magnetic field, horizontal (side to side) string movement should not be picked up very much.

This has implications for timbre, because the horizontal component from pickups that have individual pole pieces is a distortion. The fundamental (first harmonic) translates to a double frequency signal, due to the string approaching the pole piece twice per cycle.

> Perfect timing! Are you a Swiss watchmaker?

No, Gen X, with Seiko automatic on left wrist.

hace 3 díasdiscuss

It's a kind of /dev/random, but for culinary ingredients.

hace 3 díasdiscuss

So it's something along the lines of demiglace or the stocks it is made from.

hace 3 díasdiscuss

Antrax lead guitarist Dan Spitz went on to become a watch maker:

https://en.wikipedia.org/wiki/Dan_Spitz

hace 3 díasdiscuss

Those are dining philosophers!

hace 3 díasdiscuss

Mathematics.

hace 3 díasdiscuss

It could be that this person has something profound to say, but ... it's about AI. Sigh and swipe left.

hace 3 díasdiscuss

Bring another radio, or bluetooth speakers.

hace 3 díasdiscuss

The mods to disable the thing have to be cleanly reversible.

What if you disconnect the speakers? Do they have a sensor for that? If so, replace them by an 8 ohm impedance.

An alternative amplifier can be connected to the speakers then. Or just use portable bluetooth speakers.

If driving alone, for music, I would then listen on headphones. That's illegal in many places but at that point, having had to disconnect the speakers, I'd be acting out of spite.

hace 3 díasdiscuss

It's completely idiotic. Technology should be assisting in performing the attention itself, not nannying the driver.

Sometimes there really isn't anything that needs your complete undivided attention. You're on a deserted, straight highway flanked by open, barren fields.

hace 3 díasdiscuss

Ian's knot is not new kind of knot with its own properties; it's a kind of procedure for producing the standard knot. The resulting knot doesn't remember which procedure it came from.

hace 3 díasdiscuss

The selling point of this knot is the adjustability (pull on the loop to relieve the clamping tension to adjust size) but I suspect that mechanism also makes it less secure than the standard knot.