kazinator

34,822 karmajoined 12 yıl önce

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

11 saat öncediscuss

I feel there is something missing here. The narrative here suggests that the author's LLMs are generating perfect Haskell code that just needs to be rubber stamped by the compiler for execution. But, oh, that takes too long.

I'm skeptical; I would think that the problem would actually be that mistakes in a large body of Haskell code would be difficult to fix: that massaging the generated slop into compiling ranges from unpleasantly time consuming to intractable.

Might the author be hiding the honest statement of the problem: that he would rather move fast and break things as a slop artist, but the guard rails are too rigid in Haskell?

16 saat öncediscuss

"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 ...

17 saat öncediscuss

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.

evvelsi gündiscuss

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.

evvelsi gündiscuss

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

evvelsi gündiscuss

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.

evvelsi gündiscuss

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

evvelsi gündiscuss

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.

evvelsi gündiscuss

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.

evvelsi gündiscuss

> Perfect timing! Are you a Swiss watchmaker?

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

3 gün öncediscuss

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

3 gün öncediscuss

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

3 gün öncediscuss

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

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

3 gün öncediscuss

Those are dining philosophers!

3 gün öncediscuss

Mathematics.

3 gün öncediscuss

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

4 gün öncediscuss

Bring another radio, or bluetooth speakers.

4 gün öncediscuss

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.

4 gün öncediscuss

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.

4 gün öncediscuss

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.