Hi, Bruce! Thanks for taking the time and effort to sign up for the list just to correct my errors. I swear that I'm not intentionally spreading disinformation about Dylan – my mistakes are purely due to ignorance, not malice! Dylan is a great language.
Dylan's "limited types" do indeed appear to do the trick for allowing efficient representation of numeric arrays (among lots of other cool things). I was thrown off by the somewhat non-standard naming. Can you clarify what distinguishes limited types from parametric types? Is it just that the parameters are not considered part of the type, so you can't dispatch on them? I had encountered Hannes Mehnert's thesis when looking into this earlier, but obviously having a research implementation of a non-standard feature doesn't count – by that criterion, Java has every language feature ever invented. My syntax and o.o. lamentations were really separate from each other. I like the S-expression syntax better – I know, that's rich coming from a designer of another language with clearly algol-derived non-S-expression syntax. Completely unrelatedly, I also find some of the o.o.-related aspects in Dylan too featurey. I mean things like slot and method annotations – protected, private, `init-keyword: foo:`, `required-init-keyword: bar:`, etc. There are a lot of these and it seems like they can combine in a dizzying number of ways. I'm sure this is all thoroughly documented somewhere and it works great, but it's just a lot of *stuff*. The business of declaring attributes like this seems to have started in Smalltalk and continued in most of its sphere of influence – declaring this method to be virtual and that field to be private, etc. It just strikes me as fiddly and that there are too many things that can combine in too many ways. But like I said, this is a matter of taste. Questions... Can one inherit from concrete types in Dylan, as you can in most object systems? Is there a way to create user-defined immutable types? Thanks again for stopping by! Cheers, Stefan On Wed, Feb 12, 2014 at 4:29 AM, Bruce Mitchener <bruce.mitche...@gmail.com>wrote: > Hello, > > Joining the group just to respond to this... > > > On Tuesday, February 11, 2014 10:20:38 AM UTC+7, Stefan Karpinski wrote: >> >> We were never directly influenced by Dylan. As far as I know, neither >> Jeff nor Viral nor I have done any Dylan programming. Any linguistic >> similarities are due to common influences (e.g. Lisp, Pascal, Algol), >> convergent design, or coincidence. I'm not sure what the reasons were for >> Dylan choosing multiple dispatch, but for us it was a necessity to be able >> to cleanly express the polymorphic behaviors that are rampant in numeric >> programming. As the wikipedia page details, Dylan doesn't have parametric >> types, which means, among other things, that you can't have a generic array >> type that allows arrays that can only contains values of a particular >> element type. In particular, that means that you can't store such an array >> in C/Fortran-compatible form, which is a non-starter for numerical work >> since that's the layout that all the numerical libraries expect. Not being >> able to call BLAS is a show-stopper for technical computing. There are many >> other benefits from both multiple dispatch and parametric types, and Julia >> is unique in having the combination of (1) a dynamic type system, (2) >> generic functions by default, and (3) parametric types that you can >> dispatch on. >> > > Dylan chose multiple dispatch as it was a descendent of Common Lisp and > CLOS (and shared some of the same language designers). Dylan took things > further by making the object system a core part of the language rather than > bolted on as CLOS was with Common Lisp. > > As for parametric dispatch, Dylan lacks full support for parametric > dispatch, but your statements about not having a generic array type and the > conclusions that follow from that are unfounded. > > Dylan supported limited types as described in our language specification: > > http://opendylan.org/books/drm/Limited_Types > > The limited collection types are what are applicable here: > > http://opendylan.org/books/drm/Limited_Collection_Types > > These fully support laying out data in memory efficiently. When using a > size limit, the compiler can also optimize away some array bounds checks > (when the right information is present). The capabilities of limited > collections are used pretty extensively. (We also use them for passing > data to OpenGL.) > > Julia may or may not be unique in the way that you described. I don't know > enough about Julia to venture a statement regarding that. Dylan certainly > has supported much of what you described (although with limited rather than > full parametric types) for the last many years. > > There was also a thesis written which had an implementation of a > parametric type system extension to Dylan and it can be found linked from > our publications page: > > Extending Dylan’s type system for better type inference and error > detection > http://opendylan.org/documentation/#publications > https://dl.acm.org/citation.cfm?id=1869643.1869645 > > This was presented at ILC 2010. > > You might also find this master's thesis by James Knight on the addition > of parameterized types to Goo from 2002 interesting: > > http://people.csail.mit.edu/jrb/goo/james-thesis.pdf > > The fact that Julia is jitted is technically an implementation detail – >> there's nothing that prevents Dylan and other languages from doing the same >> thing (JavaScript and Lua both have excellent, fast production-quality jit >> implementations that were built long after the languages were created). >> That said, Julia's implementation has been jitted from the start, so its >> design is particularly amenable to jit compilation and efficient execution >> in general. I also personally find Dylan's syntax to be unfortunately >> verbose, and feel that some of the object-oriented aspects of the language >> are overly "featurey". It's kind of a shame, imo, that Dylan didn't stick >> with its original S-expression syntax and adopt less of the object-oriented >> thinking of the time. >> > > Two things here ... > > The Windows version of Open Dylan can compile and update code in a running > executable. This feature isn't yet available on other platforms for a > variety of reasons, but there's nothing about the design of things that > prohibits it. This really doesn't matter though. These are implementation > details as you said. > > The "original" S-expression syntax was just as object-oriented (and in the > same CLOS-like way) as modern Dylan is. The change in the syntax had > nothing whatsoever to do with how OO or not Dylan is. (And many would argue > that CLOS-like OO has little to do with the type of OO thinking that > flourished in the 1990s.) > > Cheers, > > - Bruce > >
