Scheme has an IEEE standard, IEEE 1178-1990, which describes a version of the language slightly later than R4RS (
I see three reasonable courses of action:
1) Do the work to make R7RS-small the new edition of IEEE Scheme.
2) Do the (lesser amount of) work to reaffirm IEEE Scheme unchanged for the second time.
3) Do nothing and allow the IEEE standard to expire.
Does anyone still care about having an official, citable standard for Scheme?
(When I brought the question up on #scheme, someone asked what R7RS-small implementations exist. Currently there are Chibi, Chicken (partial), Foment, Gauche, Guile (partial), Husk, Kawa, Larceny, Mosh (partial), Picrin, Sagittarius.)
Just a funny talk I found on the Interwebs by Dave Ackley.
I don't think his ideas are particularly new but it's good to see them stated directly in a talk once.
The end result is something seemingly tangent to what is possible at the moment, scalable hardware with a programming language on top.
The paper Haskell-Like S-Expression-Based Language Designed for an IDE appeals to me at the moment because I actually like the regularity of s-exprs (to side-step the inevitable technopsychobabble corners people paint themselves into otherwise) but still really want static type checking (with some inference, probably).
The intro is great and I won't spoil it, here's what is just after the opening jab.
Plus, any paper that mentions Shen and Elm and Flow et. al. can't be all bad.
P.S. I think this video is very nice, too.
(some extra keywords: xixixao, Shem, Golem)
With all due serious respect to: TypedRacket, TypedLua, Dialyzer, TypeScript, Flow, et. al., I see most if not all attempts to add some form of static type checking to a dynamic language to be indictments of the whole venture. Sure, they might get close to having something, but the something is so far away from 'the goal' that it is proof of the tilting at windmill nature of it all. From my Day Job Joe Programmer Static Typing Bigot perspective.
Cf. the long and complicated list of Flow issues on GitHub.
I realize that building a language with typing from the ground up is empirically hard to do, or empirically hard to conceive of doing anyway. Thus instead of asking for Magic Pixie Dust Retroactive Static Typing libraries, I think I would like to ask: How can dynamic language creators at least make their dynamic language more rather than less amenable to some possible future static typing analysis?
(Of course the answer is to use some static typing engine to lint the grammar/possible productions/whatever, which is obvious and sad and ironic and undermines any such dream ever being fruitful.)
Or should we just admit that anybody who thinks we can have our dynamic cake and eat it too is barking up the wrong tree?
A while back I published a draft of an article I wrote to explore L-systems, specifically D0L systems, and would very much enjoy any feedback (positive or negative) of what I have written.
Primarily, the content which gives me pause is the mathematics revolving morphic words as I have yet to fully grok them in any greater sense than the one that I have used in my implementation.
Please, critique my work and point out any errors.
The Getting Started thread is very educational, but I am writing to point out that as time progresses more literature comes into being and there might be a more efficient way to digest programming language theory, category theory, programming language design, functional programming etc. I would love to see a curated list that describe a nice progression path from apprentice to journeyman and beyond, that still could be community maintained much like the getting started guide.
There could even be different suggested paths. I for one have programmed a lot of software, and my knowledge mostly pertains to maintainability, and software engineering approaches to distributing knowledge and writing robust systems. I am however very interested in the concepts that this site pertains to, but I have a lot of difficulties approaching it solely from a theoretical stand-point. I need application, and I find that until one's own knowledge moves beyond a particular point does it become possible to dream up one's own applications and sandbox-experiments.
And, I am sure there are other individuals that approach these concepts from a more mathematical standpoint, but I cannot much speak for them as a group as I am not amongst them.
I have been exploring Rust as of late, which has an affine type system (I hear). Is there any good introductory papers to familiarize oneself with the subject on a theoretical basis? I would have an easier time starting from a practical mindset that interleaves the "necessary" theory, edging increasingly toward a purely theoretical view but I realize that may not exist.
LIVE 2016 aims to bring together people who are interested in live programming. Live programming systems abandon the traditional edit-compile-run cycle in favor of fluid user experiences that encourage powerful new ways of “thinking to code” and enable programmers to see and understand their program executions. Programming today requires much mental effort with broken stuttering feedback loops: programmers carefully plan their abstractions, simulating program execution in their heads; the computer is merely a receptacle for the resulting code with a means of executing that code. Live programming aims to create a tighter more fluid feedback loop between the programmer and computer, allowing the computer to augment more of the programming process by, for example, allowing programmers to progressively mine abstractions from concrete examples and providing continuous feedback about how their code will execute. Meanwhile, under the radar of the PL community at large, a nascent community has formed around the related idea of “live coding”—live audiovisual performances which use computers and algorithms as instruments and include live audiences in their programming experiences.
We encourage short research papers, position papers, web essays, tool demonstrations (as videos), and performance proposals in areas such as:
Submissions will go through EasyChair. Papers and essays must be written in English and provided as PDF documents. As a recommendation, papers should be around 5 pages and videos should be 5-10 minutes in length; other non-paper submissions should consume no more than 30 minutes of a casual reader’s time. However, papers up to 10 pages and videos up to 20 minutes are also welcome. Video and non-paper submissions can by listed as URLs (e.g. to a web page, file locker, or streaming site) in the submission’s abstract. At the author’s discretion, workshop articles can be published using an institutional ISBN with full support for open access.
Any questions or trouble with submitting, please contact firstname.lastname@example.org.
There is a subset of C++ that is supposedly the bee's knees, according to Stroustrup, Sutter, and Dos Reis. Not to start an opinionated flame war, I want to know if you believe their argument holds enough water. I mean this both technically (if you stick to what they say, does it work) and in terms of practicality (are humans able to do that). To whatever extent you disagree, what are viable alternatives?
I mean this both about what they say works (their approach using 'good' C++), and what they say doesn't (cf. gc finalizers).
The Onward call for papers is on, with a submission deadline of April 1st this year. Please consider submitting your edgy PL ideas.
Active forum topics
New forum topics