tag:blogger.com,1999:blog-19626531.post5674202167543309865..comments2023-11-02T08:32:39.646+01:00Comments on Ola Bini: Programming Language Synchronicity: Should Ruby have optional typing and compiler directives?Ola Binihttp://www.blogger.com/profile/15793488672952593953noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-19626531.post-90262804372270388072007-09-12T11:40:00.000+02:002007-09-12T11:40:00.000+02:00I don't know very much about Ruby, but, as I under...I don't know very much about Ruby, but, as I understood, this should be used only in very few cases, for performance improvement of intensive use code. So, wouldn't be interesting to take out this optimizations out of the code? Some file like optimizations.jrb with that format:<BR/><BR/>Person.testMethod.variable is Fixnum<BR/>Person.testMethod.variable2 is Date<BR/>Person.testMethod.options =[no-bindings, no-eval, no-closures]<BR/><BR/>This remains the code compatible with other xRuby versions and gives you the same functionality. Obviously this solution is useless and error prone if you use it masively...Unknownhttps://www.blogger.com/profile/15426337679098053557noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-66120278953604475722007-09-12T11:19:00.000+02:002007-09-12T11:19:00.000+02:00Hi Ola,We already have this in Ruby In Steel. We c...Hi Ola,<BR/><BR/>We already have this in Ruby In Steel. We call them type assertions. They exist in comment blocks so don't affect the meaning of Ruby code. They are currently most useful for providing any IntelliSense which cannot be inferred (e.g. input args) but we plan to extend this to add additional features in future.<BR/><BR/>You can get an overview of Ruby In Steel type assertions by watching the short "ParameterInfo & Type Assertions" screencast on this page: http://www.sapphiresteel.com/Ruby-In-Steel-Movies<BR/><BR/>best wishes<BR/><BR/>HuwAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-74268815235864688412007-09-12T08:39:00.000+02:002007-09-12T08:39:00.000+02:00I'm probably revealing my ignorance here but anywa...I'm probably revealing my ignorance here but anyway:<BR/><BR/>If you declare arguments as Fixnum/Array/etc. don't you jeopardize future use of the code that could rely on the dynamic nature of the language?Unknownhttps://www.blogger.com/profile/16088859809385295736noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-27632246723992249492007-09-11T09:30:00.000+02:002007-09-11T09:30:00.000+02:00I don't understand why you want ruby to be like Li...I don't understand why you want ruby to be like Lisp, or Java or C or C++ or whatever. Surely, if you like Lisp you should use Lisp.<BR/><BR/>It's fine to chat about stuff and throw ideas out there, but let Ruby be Ruby. See where it goes on it's own. Lisp remains niche, so we know where that went - ie not as succesful (these days) as Ruby.<BR/><BR/>If anything, you should be recommending that List gets rid of the features that have seemingly held it back from the big time.<BR/><BR/>JonathanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-55536215056530817632007-09-11T05:54:00.000+02:002007-09-11T05:54:00.000+02:00I second daniel spewak. Implementing this using pl...I second daniel spewak. Implementing this using plain ruby sintax doesn't complicate ruby grammar, and we could use no-op function to be used in "non-compiling" ruby implementations.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-34353068032670344882007-09-10T20:22:00.000+02:002007-09-10T20:22:00.000+02:00We could of course implement this in JRuby in a wa...We could of course implement this in JRuby in a way that would be non-breaking if the same code ran in regular Ruby. For example, via additional syntax normally parsed as comments, or in a way similar to Rubinius's primitive VM instructions. It would potentially make it easier to implement parts of JRuby in Ruby without getting a perf hit from using heavily dynamic types.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-43850572511057194992007-09-10T17:42:00.000+02:002007-09-10T17:42:00.000+02:00@daniel berger: there was a very specific reason f...@daniel berger: there was a very specific reason for not putting the type declarations inside the declaration of the arguments. the reason was that I wanted to make it possible to use exactly the same syntax for locals and instances variables. this is also why I put it inside of the method instead of outside. in my opinion, the state changing of private/protected/public is kinda gross, and not at all thread safe.<BR/><BR/>@daniel spiewak: I considered using "standard" Ruby syntax but decided against it - the reason being that declare would need to be a parse time keyword and should definitely not look anything like regular Ruby. that would invite using variables as arguments or other fallacies like that. I think it's best to keep it as a keyword, totally separate in functioning.Ola Binihttps://www.blogger.com/profile/15793488672952593953noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-36717180678454030872007-09-10T17:35:00.000+02:002007-09-10T17:35:00.000+02:00It's an interesting idea. Should even be possible...It's an interesting idea. Should even be possible without screwing the language too much. The following fragment would provide the benefits of your example, without requiring new syntax:<BR/><BR/>declare return=Fixnum<BR/>declare type= :first => Fixnum, :second => Enumerable, :rest => Array<BR/>declare compiler= :no_bindings, :no_eval, :no_closures<BR/><BR/>Since declare is obviously just a method with named parameters, you could streamline the above into a single call if you really wanted to.Daniel Spiewakhttps://www.blogger.com/profile/17323566514229790079noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-58169647021519564342007-09-10T15:38:00.000+02:002007-09-10T15:38:00.000+02:00At least give us some nice notation:def test_one(F...At least give us some nice notation:<BR/><BR/>def test_one(Fixnum first, Enumerable second, *rest) => Fixnum<BR/>puts "hello"<BR/>return 1+1<BR/>end<BR/><BR/>compiler :test_one [no-bindings, no-eval, no-closures]<BR/><BR/>Keep the compiler directives outside the method if possible. Something like an annotation along the lines of public/private/protected.<BR/><BR/>Also, you shouldn't have to explicitly specify the type for "*rest". The asterisk tells you that it's an Array already.Daniel Bergerhttps://www.blogger.com/profile/05224445093970941579noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-16342590778055360352007-09-10T13:26:00.000+02:002007-09-10T13:26:00.000+02:00Just to share how other langs do this: In Dylan (w...Just to share how other langs do this: In Dylan (which is also a Lisp relative), you can also optionally specify type information, e.g.<BR/><BR/>define function built-a-house (area, height :: <integer>, windows :: <sequence>) => (house :: <house>)<BR/>...<BR/>end define<BR/><BR/>This doesn't only improve performenace, but also enables multiple dispatch based on the given type.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-69764048354622591952007-09-10T13:00:00.000+02:002007-09-10T13:00:00.000+02:00If I understand you correctly, this seems similar ...If I understand you correctly, this seems similar to the <A HREF="http://www.python.org/dev/peps/pep-3107/" REL="nofollow">function annotations</A> being introduced in Python 3 (but your Lisp example seems more powerful and geared towards the compiler).<BR/><BR/>I guess the "optionality" of features like these will add a lot of value. You can continue with your rapid prototyping, and then add typing and optimization in later iterations when you are getting ready for production. In fact, this would fit nicely with agile methods.Anonymousnoreply@blogger.com