To be pedantic: You're conflating the syntax of regular exprssions, with the (computer science) concept. Glob patterns are a kind of very resticted regular pexressions. Ksh extended the glob syntax so it has the full power of regular expressions in the computer science sense - though without all the extensions of modern regular expressions.
“Globs do not include syntax for the Kleene star which allows multiple repetitions of the preceding part of the expression; thus they are not considered regular expressions, which can describe the full set of regular languages over any given finite alphabet.”
You're right, normal globs are not regular expressions regardless of syntax. Parent is correct too, ksh globs are regular expressions. See shopt -s extglob in bash, setopt kshglob in zsh (extendedglob for zsh's native, IMO inferior, quantifier syntax).
Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt.
But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt.
Some REPLs have nicer interactive features (such a completion than others).
Some REPLs have nicer or more powerful syntax or different data types.
But as longs as you have a Read-Eval-Print-Loop it's a REPL.
One of the issues R7RS-large ran into was in how to handle datatypes, such as collection types. Initially, Lisp-style languages had linked lists as the primary data type, but vectors were early added. So you had a "map" function (that worked on linked lists) and "vector-map" (that worked on vectors). Similarly, "length" vs "vector-length". What happens if you want to add more collection types - for example "bytevector"? Do you add "bytevector-map" and "bytevector-length"? Or do you generalize "map" and "length" so they also work on bytevectors (and also vectors)? The former is most compatible with Scheme history and tradition. The latter is IMO preferable going forward as new collection types are added - but it needs some way to talk about frameworks of types that are all sequences (linear collections). I.e. you need at least the concept of inheritance or "interfaces" as used in various languages, including Java and TypeScript.
Many languages in the Lisp/Scheme family have some kind of inheritance or interfaces, including Common Lisp, Dylan, Racket, Kawa, and many more. However, this hasn't been standardized for Scheme. R7RS-small has a mechanism to define new data types (records), but they were limited in functionality to C-like structs.
I (and others in the community) felt (and feel) that it is premature and unwise to add a bunch of new libraries for new data types until or unless we have some kind of framework for inheritance or interfaces. Others in the community (including the former chair) felt this was unnecessary and perhaps inappropriate for a language with the goals and history of Scheme.
There is no clear right answer or consensus for how to go forward, which is part of what caused things to bog down.
I learned Scheme from George Springer in the '90s.
I just want a language with S-expression syntax and a proper numeric tower (like Scheme), with modern HAMT-based immutable collection types (like Clojure), and a native JIT so I don't have to mess with Java or JavaScript.
Does Racket fit the bill now?[1][2] Coming from Indiana, I was happy when they announced the move to Chez.
I was heartened by a post here yesterday about implementing a numeric tower on WASM.[3]
The lack of “interface” was one of the main reasons I never ended up using scheme to build production systems.
I loved playing with scheme in my university days 20 years ago, and loved how one can make up any fancy programming concept using call/cc and dynamic-wind. Except if you want to have multiple implementation of some protocol or collection. Hand roll your own object model or dynamic dispatch mechanism? Hard to make it scalable, composable and compatible with other projects.
> Initially, Lisp-style languages had linked lists as the primary data type, but vectors were early added
The Achilles' heel of every Lisp is dealing with any data structure that isn't a linked list. I'm talking aref, setf+aref, vector-ref, vector-set!, char, etc. It's all just a huge pain when compared to any other language (Python, Ruby, JavaScript, Java) that has syntax for arrays, hash maps, strings. Solving the generalized "map" or "length" is really only solving one side of the problem. The other side can't be solved because the language is s-exps and "everything is a function." It would fundamentally cease to be Scheme at that point.
I haven't used clojure since forever but I don't think this was particularly problematic. They even had nice literal syntax for different collection types and fairly powerful generalized collection abstractions, way better than the languages you mentioned IMO.
Also Clojure decomplects inheritance and interfaces.
It gives you protocols to define a set of related methods, without any restriction on the underlying data structure.
It gives you defrecord & deftype to define composite associative data structures, which the fields in an object are.
Then you can combine these in various ways, giving you all sorts of polymorphic code.
Clojure even has multimethods for cases, when a single operation should happen different ways, depending on some aspect of an arbitrary data structure.
Someone defines a transformation function from arbitrary data to some other data to dispatch behavior over, then anyone can add define behavior for new dispatch values.
This succeeds if obj matches the pattern p::Point, declaring p to be the value of obj coerced to a Point.
This is integrated with Kawa's static type-checking/inference.
I'm the author of DomTerm and the above-mentioned xterm.js PR. Both use the full UnicodeGrapheme Cluster Boundaries algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie...). However, I haven't seen any specifications for how wide the resulting clusters should be in a mono-space context. So unless we enhance terminals to handle variable-width fonts (which I've been thinking about), we need to took at other terminals and make judgement calls. Generally, the width of a cluster is the width of the widest codepoint. Also, I decided that a "normal" character followed by emoji-presentation makes it 2 columns wide.
In your linked-to article, you suggest 2-em dash and 3-em dash should be 3 and 4 columns respectively. That might be reasonable, but it is explicitly contrary to the EastAsianWidths specification. You also suggest that Pictographics fullowed by text-presentation should have width 1. That seems reasonable, though I don't implement that.
To my knowledge, there is no specification for monospace width. Applying the East Asian Width attribute as a proxy does not work reliably. So in my opinion, it is all a matter of agreeing on what's reasonable while keeping it simple. I.e. if allocating text-presentation Pictographics to a width of 1 is reasonable, that's what renderers should do. It's what users would expect.
It's certainly less common now, but prior to 2015 it was common for "legacy" vendors (y'know... the paranoid and posessive types, like ProgressDB...) - or just those embarassed about the state of their products compared to the rest of the industry: they'll hide their KB articles, bug-reports and workarounds, and more besides) behind a registration-wall, or even worse: only grant you access if you have a current support contract with them.
At least their SQL documentation is public - I remember (at least a decade ago) that only Postgres, MySQL, and MSSQL made their documentation public, while info on IBM DB2 and Oracle was scarce.
I believe we're talking about the equivalent of a small LED, like half your devices already have one or more of, but infrared and probably lower intensity. I.e. a teeny invisible glow. Even for animals that can see the glow, it would low enough intensity to be barely noticable.
How do many insects respond to even small sources of that particular section of the spectrum?
People don't even realize when thier clothes have UV reflecting materials which affect birds (eg hummingbirds) so ofc y'all don't comprehend not accept what I'm saying, you literally don't know about this problem with human materials we have scattered all over which are negatively affecting creatures outcomes as we constantly trigger thier basic natures.
