Conlangjugator

[chris_notts]

If one is concerned primarily with performance, even though it is lazy by default Haskell outclasses Python (I have seen it compared to Java with regard to straight-line performance). Also, Haskell has excellent concurrency support, being able to support thousands of threads at a time across multiple cores, and has very nice concurrency-related facilities such as Software Transactional Memory and Async, whereas Python has relatively poor concurrency support (e.g. even though it can have multiple threads, it cannot take advantage of multiple cores). The only other language I have seen which is comparable to Haskell with regard to concurrency is Erlang.

Having said that, for an SCA poor performance is more likely to be a symptom of a poor algorithm than a poor programming language. We're not talking big data here, so you can likely achieve acceptable performance in almost any language. The main win for Haskell in this case is speed of writing the code, not executing it: once you've got a handle on the language, writing an interpreter / compiler in Haskell is pretty easy due to good parsing libraries, good pattern matching, and for regular expressions specifically default laziness. My very verbosely commented custom regexp implementation is about 200 lines...

[alice]

Python? Haskell? Wimps! Come on, if you can't do it in Fortran 77 on a 4-bit machine then it isn't worth doing.

Seriously, though, I've found both Ruby and Scala to be good languages for an SCA. Pure functional Scala with recursion and immutable objects in particular lends itself to interesting solutions.

[bradrn]

Pure functional Scala with recursion and immutable objects in particular lends itself to interesting solutions.

I'd be interested to hear about this in a bit more detail - it sounds fascinating!

(Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

[Travis B.]

As writing an SCA in Haskell has already been done, I should write an SCA in Forth for attoforth (which would be more of a challenge than writing one in Haskeell) - but that'd have to wait until attoforth is ready, as I have not written a Unicode library for it, and I should add things like support for command line arguments (even though one could invoke an SCA within attoforth, using the attoforth REPL).

[chris_notts]

Pure functional Scala with recursion and immutable objects in particular lends itself to interesting solutions.

I'd be interested to hear about this in a bit more detail - it sounds fascinating!

I've been meaning to learn Scala. It sounds like a good compromise: easy access to a more mainstream ecosystem (Java) without the general crapiness of Java the language and with nice functional features baked in.

Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

Zompist made one as well...

[bradrn]

Pure functional Scala with recursion and immutable objects in particular lends itself to interesting solutions.

I'd be interested to hear about this in a bit more detail - it sounds fascinating!

I've been meaning to learn Scala. It sounds like a good compromise: easy access to a more mainstream ecosystem (Java) without the general crapiness of Java the language and with nice functional features baked in.

You might also be interested in Eta - a fork of GHC to let Haskell run on the JVM.

Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

Zompist made one as well...

I know - I was just listing the people who have participated here so far. I was just surprised that so many people here had made their own. And really, it would be interesting to have some sort of comparison!

[chris_notts]

You might also be interested in Eta - a fork of GHC to let Haskell run on the JVM.

Cool. Purescript (http://www.purescript.org/) is similar (not GHC-based though) for Javascript. Unfortunately it's strict, I suspect because getting decent performance with wide-spread laziness is almost impossible if your compilation target is Javascript. I really wish that, instead of Javascript becoming the standard, the web had agreed some kind of lower-level sandboxed byte-code. It would make it easier to replace the horrible mess that is Javascript with something better.

I know - I was just listing the people who have participated here so far. I was just surprised that so many people here had made their own. And really, it would be interesting to have some sort of comparison!

Sure. I have some old documentation for HaSC if it would be useful for your feature comparison...

[bradrn]

You might also be interested in Eta - a fork of GHC to let Haskell run on the JVM.

Cool. Purescript (http://www.purescript.org/) is similar (not GHC-based though) for Javascript. Unfortunately it's strict, I suspect because getting decent performance with wide-spread laziness is almost impossible if your compilation target is Javascript.

I know about Purescript already - it's a nice project.

I really wish that, instead of Javascript becoming the standard, the web had agreed some kind of lower-level sandboxed byte-code. It would make it easier to replace the horrible mess that is Javascript with something better.

You mean like WebAssembly?

I know - I was just listing the people who have participated here so far. I was just surprised that so many people here had made their own. And really, it would be interesting to have some sort of comparison!

Sure. I have some old documentation for HaSC if it would be useful for your feature comparison...

Well, I haven't actually started anything yet - I think I would need a list of SCAs first before I could start comparing them.

[chris_notts]

You mean like WebAssembly?

I guess, but is anyone actually using it for anything? I remember a similar Google initiative years ago- is this that rebranded? JS has too much traction now for a multi-language web, unfortunately.

[zyxw59]

I honestly don't find it particularly surprising that so many people have made their own SCA — I made my own[1] because I wanted features or syntax not supported by any of the ones I could find, and it made for an interesting programming project.

[1] Original version, written in Python: https://github.com/zyxw59/soundchanger/
Second version, written in Go: https://github.com/zyxw59/conlang/
Third version (not finished), written in Rust: https://github.com/zyxw59/rssc

[Travis B.]

You mean like WebAssembly?

I guess, but is anyone actually using it for anything? I remember a similar Google initiative years ago- is this that rebranded? JS has too much traction now for a multi-language web, unfortunately.

WebAssembly is cross-browser, and supercedes previous efforts like asm.js, and should be useful as a compilation target for a variety of languages. Note that currently it does not support garbage collection, unless a language compiled into it provides its own, but this is planned on being added in the near future.

[alice]

I honestly don't find it particularly surprising that so many people have made their own SCA — I made my own[1] because I wanted features or syntax not supported by any of the ones I could find, and it made for an interesting programming project.

That's exactly why I keep asking about a Grand Unified Sound Change Applier!

Meanwhile, I heartily recommend Scala; it fixes almost everything which is wrong with Java and has few things wrong with itself. It's not *that* easy to learn, however.

[bradrn]

I honestly don't find it particularly surprising that so many people have made their own SCA — I made my own[1] because I wanted features or syntax not supported by any of the ones I could find, and it made for an interesting programming project.

That's exactly why I keep asking about a Grand Unified Sound Change Applier!

I was actually thinking the same thing! It would be amazing if everyone who has written a SCA were to implement something including all of their respective features. Although we may just run into this problem...

[chris_notts]

I honestly don't find it particularly surprising that so many people have made their own SCA — I made my own[1] because I wanted features or syntax not supported by any of the ones I could find, and it made for an interesting programming project.

That's exactly why I keep asking about a Grand Unified Sound Change Applier!

I was actually thinking the same thing! It would be amazing if everyone who has written a SCA were to implement something including all of their respective features. Although we may just run into this problem...

The problem is that some features may be fundamentally incompatible. For example, many work on the basis of string substitution which implies one internal model. Mine has a completely different internal model which means symbol substitution is meaningless:

Input string -> featural phonetic representation -> output string

This means, for example, that if you convert a pulmonic stop to an elective using a features sound change, this is stored as a feature change not as a text substitution, amd then when it's time to write the results HaSC will take the features +velar +ejective... and it will look at the symbols you imported and figure out for itself that k + 0315 COMBINING COMMA ABOVE RIGHT is the best way to write that sound.

[alice]

The problem is that some features may be fundamentally incompatible. For example, many work on the basis of string substitution which implies one internal model. Mine has a completely different internal model which means symbol substitution is meaningless:

Input string -> featural phonetic representation -> output string

This means, for example, that if you convert a pulmonic stop to an elective using a features sound change, this is stored as a feature change not as a text substitution, amd then when it's time to write the results HaSC will take the features +velar +ejective... and it will look at the symbols you imported and figure out for itself that k + 0315 COMBINING COMMA ABOVE RIGHT is the best way to write that sound.

This is what mine does too - it helps to know that, for instance, <tʰ> is related to <t> in a systematic way - which is why I was asking so many questions about phonological models a while ago. This way is a bit more complicated, since you have to convert to and from your internal representation, but ultimately more powerful.

[bradrn]

That's exactly why I keep asking about a Grand Unified Sound Change Applier!

I was actually thinking the same thing! It would be amazing if everyone who has written a SCA were to implement something including all of their respective features. Although we may just run into this problem...

The problem is that some features may be fundamentally incompatible. For example, many work on the basis of string substitution which implies one internal model. Mine has a completely different internal model which means symbol substitution is meaningless:

Input string -> featural phonetic representation -> output string

This means, for example, that if you convert a pulmonic stop to an elective using a features sound change, this is stored as a feature change not as a text substitution, amd then when it's time to write the results HaSC will take the features +velar +ejective... and it will look at the symbols you imported and figure out for itself that k + 0315 COMBINING COMMA ABOVE RIGHT is the best way to write that sound.

What sort of features exactly are incompatible with this model?

[chris_notts]

What sort of features exactly are incompatible with this model?

I mean that they have different semantics. You need to pick one. A good programming or scripting language has simple consistent semantics, but some features naturally fit with a different underlying model of the problem.

In HaSC, for example, if you told it that the characters a and b have the same phonetic content, then you can't then a -> c without also doing b -> c, and furthermore HaSC will normalise all its output to be consistent, so the spelling difference a vs b would be neutralised in any case. For HaSC, the exact textual representation of a word is only relevant at the beginning and end of the process, so that data is not available to be read or transformed mid-sound change.

In an SCA that works by character substitution, you have more direct control, and you can transform the spelling of the word directly. The spelling is the word, in a way that isn't true for HaSC, so that data is always available. But the cost of that is that you need to enumerate all changes by looping over lists/groups since the SAC itself doesn't understand the phonetic nature of the changes you're making.

[bradrn]

What sort of features exactly are incompatible with this model?

I mean that they have different semantics. You need to pick one. A good programming or scripting language has simple consistent semantics, but some features naturally fit with a different underlying model of the problem.

In HaSC, for example, if you told it that the characters a and b have the same phonetic content, then you can't then a -> c without also doing b -> c, and furthermore HaSC will normalise all its output to be consistent, so the spelling difference a vs b would be neutralised in any case. For HaSC, the exact textual representation of a word is only relevant at the beginning and end of the process, so that data is not available to be read or transformed mid-sound change.

In an SCA that works by character substitution, you have more direct control, and you can transform the spelling of the word directly. The spelling is the word, in a way that isn't true for HaSC, so that data is always available. But the cost of that is that you need to enumerate all changes by looping over lists/groups since the SAC itself doesn't understand the phonetic nature of the changes you're making.

Why would you even want to work on spelling as opposed to phonemes? As far as I know, sound changes work on the latter, not the former.

[chris_notts]

Why would you even want to work on spelling as opposed to phonemes? As far as I know, sound changes work on the latter, not the former.

I'm not saying you'd necessarily want to, but that is in practice the model of many SCAs. Even though they're called SCAs, they're operating on textual representations, so a "feature" of them is preservation of those textual representations and access to that data. They behave differently to an SCA which regards the textual representation as just an input/output format. So for a super SCA you need to decide: are you going for a featural / phonetic model, or operating on textual representations, or are you somehow offering access to both representations simultaneously?

[cedh]

Why would you even want to work on spelling as opposed to phonemes? As far as I know, sound changes work on the latter, not the former.

Well, "spelling" in the sense used by chris_notts is not necessarily the same as "orthography", but in the context of an SCA could be any of (1) orthography, (2) broad phonemic IPA transcription, or (3) narrow phonetic IPA transcription. The thing is that in an SCA based on character substitution, this transcription is used as a string of symbols, while in a feature-based SCA it is converted into segments with phonetic features before the sound changes start, and only converted back to a string of symbols after all actual sound changes are done.

(I can see the advantages of both methods, and I acknowledge that a featural model seems to be much closer to how sound changes work in reality, but I personally still prefer using the character substitution approach because of the additional direct control.)