We don't need a string type (2013)

Post by eigenspace » Thu, Feb 11, 2021, 11:01 PM UTC

BlueTemplar wrote: post #60

eigenspace wrote: post #57

Earlier quoted context omitted.

Yes, Julia really lets one get wild with Unicode. There are certain classes of unicode characters that we have marked as invalid for identifiers, some which are used for infix operators, and some which count as modifiers on previously typed characters which is useful for creating new infix operators, e.g. one might define julia> +²(x, y) = x^2 + y^2 +² (generic function with 1 method) such that julia> -2 +² 3 13 If s…

Nice ! Python allows to define operators too, but AFAIK you can't use Unicode in those ? And ² (or any other sub/superscript number - at least some letters are fine) is not allowed in identifiers either. The point is to get closer to math notation though, if anything x +² y is IMHO even farther away than (x + y)*2 ! Any way to have (x + y)² or √(x + y) to work ? –––– The new AZERTY has a lot of improvements : ∞, ±, ≠…

    julia> √(1 + 3)
    2.0

    julia> struct ᵀ end

    julia> Base.:(*)(x, ::Type{ᵀ}) = transpose(x)

    julia> [1, 2, 3, 4]ᵀ
    1×4 transpose(::Vector{Int64}) with eltype Int64:
     1  2  3  4

Post by jerf » Fri, Feb 12, 2021, 12:58 AM UTC

KMag wrote: post #36

jerf wrote: post #20

Earlier quoted context omitted.

It is not clear to me if you're elaborating or think you're disagreeing, but that is what Go does. It is generally assumed in Go that strings are UTF-8, but in practice what they actually are are just bags of bytes. Nothing really "UTF-y" will happen to them until you directly call UTF functions on them, which may produce new strings. It's something that I don't think could work unless your language is as recent as G…

I'm saying it's useful to have valid strings and paths as separate types, but Go conflates the two types. Conflating the two is likely to lead to confused usage (such as programmers assuming there's a bijective mapping between valid paths and valid sequences of Unicode codepoints.) Pervasive confused usage of this sort in the wild in Python 2 was the motivation behind splitting bytes and strings in Python 3.

    type PathSegment struct {
        path string // not exported, so only the empty one can be created externally
    }

    func MakePath(in string) (PathSegment, error) {
        // validate the input here
    }

Post by quelsolaar » Fri, Feb 12, 2021, 3:51 AM UTC

Post by quelsolaar » Fri, Feb 12, 2021, 6:02 AM UTC

xscott wrote: post #66

quelsolaar wrote: post #65

I think that the problem with text is that the basic operation you want to do is inserts. The way memory works in computer makes that an inherently inefficient operation. I'm a bit fascinated by how bad computer are at text give that that is what we use so much of them for. As a C programmer I think that its not really possible to implement an efficient text processing library, because there is no good universal way…

I think you want a "gap buffer".

Post by cygx » Fri, Feb 12, 2021, 7:44 AM UTC

GoblinSlayer wrote: post #68

msla wrote: post #29

Earlier quoted context omitted.

"String" has multiple meanings in this context. In the context of that manpage, it means "nul-terminated array of char" which is the C language meaning. In the context of what you're replying to, a "string" is a sequence of bytes (octets) in a specific Unicode Transformation Format. Those are very different things when it comes to programmatic manipulation of those things.

What you can do with a "string" that you can't do with a C string?