I wonder how much fun one could have with OMeta http://tinlizzie.org/ometa/ ?
The Rewards of Creating a Programming Language
81–88 of 88 posts
Re: The Rewards of Creating a Programming Language
#82Earlier quoted context omitted.
erlang's concurrency is actors, which is different from go's CSP. And I nearly spat out my tea when you said that Go popularized something Haskell did; and I haven't even had any tea today.
It's always worth pointing out that CSP is a language, rather than a concept. Perhaps "CSP-inspired" would be a better choice?
CSP is based on the theory of process calculi: http://en.wikipedia.org/wiki/Actor_model_and_process_calculi
Re: The Rewards of Creating a Programming Language
#83I was hired (a long time ago) to write a language for a Very Large Telco Equipment Supplier in Canada in order to support their automated regression testing effort for their digital telephone switches. It was called, ingeniously enough, "T" (no, not that "T"). As far as I (and cursory Google searches) know, it was never released to the adoring public. I used lex and yacc (half jokingly referred to as 'ick' and 'yuck'…
I wonder how one would go about efficiently implementing such an associative array. I suppose a trie + glue logic (regexp -> NFA -> DFA) could work, for classic (read: actually regular expressions) regexps at least.
I have wondered the same thing, but wasn't extremely concerned about getting it super-fast at the time. We had an existing, older language that was much loathed and quite slow, and we just had to beat it. And awk.
Re: The Rewards of Creating a Programming Language
#84I was hired (a long time ago) to write a language for a Very Large Telco Equipment Supplier in Canada in order to support their automated regression testing effort for their digital telephone switches. It was called, ingeniously enough, "T" (no, not that "T"). As far as I (and cursory Google searches) know, it was never released to the adoring public. I used lex and yacc (half jokingly referred to as 'ick' and 'yuck'…
Just curious, did you specify order ? dict[`he.*`] == [4,2] could also hold. Or maybe [...] was a set literal and not ordered list. Interesting ideas, perlish in spirit, somehow less cryptic. Was it published ? was there other ideas you could talk about ?
My code above isn't the exact syntax. I doubt I implemented array equality. I was just demonstrating that an array would be returned when indexing the dict with a regexp.
I know nothing was published or released. I actually left BNR/NT less than a year after the language went into production (going to say July, 1990) - I don't really know how long it remained there. Perl was popular, and Tcl was definitely a 'thing' in the lab at the time - the writing was on the wall for home-grown languages.
Re: The Rewards of Creating a Programming Language
#85Earlier quoted context omitted.
Indeed. Recently I was inspired to learn K, a language in the APL family. There aren't many implementations available, so I wrote my own. Doing this forced me to come to terms with a whole range of features I might have otherwise shied away from using.
Hi! Is your implementation available for use? I'm curious - how did you test it for compatibility with the main K implementation?
Sure, here's the repository: https://github.com/JohnEarnest/ok
I don't have a rigorous approach for testing compatibility at present; My starting point was the K2 manual, and I've tried to get as many examples from that working as possible. I have been learning the language as I go, so often I don't realize functionality is missing until I stumble across an existing K program that doesn't work properly.
I'm targeting K5, which is unreleased, so there's a great deal of speculation. I think I have a decent subset of the functionality working now, but most of the time when I write new programs using it I still shake out bugs and unhandled edge cases.
Re: The Rewards of Creating a Programming Language
#86Earlier quoted context omitted.
Hi! Is your implementation available for use? I'm curious - how did you test it for compatibility with the main K implementation?
Sure, here's the repository: https://github.com/JohnEarnest/ok I don't have a rigorous approach for testing compatibility at present; My starting point was the K2 manual, and I've tried to get as many examples from that working as possible. I have been learning the language as I go, so often I don't realize functionality is missing until I stumble across an existing K program that doesn't work properly. I'm targeting…
Awesome. I started building a toy C interpreter to the k5 spec (http://kparc.com/k.txt) based on the k4 data structures (http://kx.com/q/c/c/k.h) and documentation (http://code.kx.com/wiki/Cookbook/InterfacingWithC). That k2 manual is a good find.
Re: The Rewards of Creating a Programming Language
#87Earlier quoted context omitted.
Sure, here's the repository: https://github.com/JohnEarnest/ok I don't have a rigorous approach for testing compatibility at present; My starting point was the K2 manual, and I've tried to get as many examples from that working as possible. I have been learning the language as I go, so often I don't realize functionality is missing until I stumble across an existing K program that doesn't work properly. I'm targeting…
Awesome. I started building a toy C interpreter to the k5 spec ( http://kparc.com/k.txt ) based on the k4 data structures ( http://kx.com/q/c/c/k.h ) and documentation ( http://code.kx.com/wiki/Cookbook/InterfacingWithC ). That k2 manual is a good find.
Cool! Nice to know that I'm not the only person trying to implement K5 from scraps and speculation.
Re: The Rewards of Creating a Programming Language
#88Earlier quoted context omitted.
Awesome. I started building a toy C interpreter to the k5 spec ( http://kparc.com/k.txt ) based on the k4 data structures ( http://kx.com/q/c/c/k.h ) and documentation ( http://code.kx.com/wiki/Cookbook/InterfacingWithC ). That k2 manual is a good find.
Cool! Nice to know that I'm not the only person trying to implement K5 from scraps and speculation.
It is certainly a fun puzzle; hopefully kOS is released soon to application developers.
Since you are playing in JS, you might also have a look at c.js (http://kx.com/q/c/c.js), which is the tool KX uses to translate between JS objects and k objects through web socket IPC with a k process (http://code.kx.com/wiki/Cookbook/Websocket). Might be useful to see how Arthur envisioned the k data structure in JS. Also, it would be kind of interesting to have a k5 process running in the browser talking with a k4 process running locally in the 32bit trial...