Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-07-26

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:30 jeffreykegler ronsavage: I mean no hit on the skills of the people who created the vim macro language.  Back then, there was less awareness of language design issues, particular of what happens if you "evolve" the language bit by bit, in response to the specific requirement of the moment.
01:32 jeffreykegler If I designed a language in the same way, I'd expect the same bad result.  This is why the SLIF's semantics are not Turing-complete, though I easily could have made them that way.  I deliberately dragged my feet on adding features to the SLIF's "reserved action" language, waiting for it to become clear which way to move.
01:33 jeffreykegler I also mentioned the "Bourne shell language".  This is not quite as bad as JCL or the vim macro language.  In part that may be to the superior skills of the people involved, ...
01:34 jeffreykegler but it may also be due to the fact that it evolved, not gradually, but in 2 or 3 major, planned, phases.  This means that, while there was not an overall plan, there were only a few, very well-thought-out, steps.
01:39 ronsavage Slow evolution I don't mind. I've no doubt tho that JCL was one of many languages deliberately designed to be complex.
01:58 jeffreykegler ronsavage: re JCL.  Design criteria or not, I know that the practitioners of JCL clearly regarded its obscurity, difficulty and very steep learning curve as desirable features.
01:59 jeffreykegler People who speak of vim macros almost always express the wish that they were easier.
01:59 jeffreykegler I never heard a JCL programmer express a similar sentiment.
07:22 ronsavage joined #marpa
14:35 jeffreykegler joined #marpa
14:53 jeffreykegler1 joined #marpa
17:26 jeffreykegler1 An example of how the Lua approach is unique --  I am reading Ierusalimsky's _Programming in Lua_.  At a few points he mentions possible future changes in Lua.
17:27 jeffreykegler1 As often as not, it involves *removing* a feature.
17:29 jeffreykegler1 Two examples: the "repeat ... until" syntax.  Not often used is his reasoning, can be duplicated adequately with other features, and its removal would simplify the language.
17:31 jeffreykegler1 The other: in some contexts, Lua auto-converts between strings and numbers.  Often used, but occasionally confusing, and its removal (in favor of always requiring explicit conversion) would make Lua smaller.
17:32 jeffreykegler1 Simplicity is emphasized more in Lua, than in any other major language.
17:36 jeffreykegler1 * Ierusalimsky -> Ierusalimschy
17:37 jeffreykegler1 Pronunciation seems to be EAR-us-AH-lim-ski
17:40 jeffreykegler1 Ierusalimsky pronunciation: http://www.forvo.com/word/roberto_ierusalimschy/
18:01 Aria I do love Lua for this.
18:02 jeffreykegler1 Simplicity in the Kollos/Marpa context has a major payoff
18:03 Aria It really does.
18:03 jeffreykegler1 I am hoping to write, compile and execute Lua on the fly a lot, as a technique.
18:04 jeffreykegler1 For example, a lot of the SLIF is implemented with mini-VM's, where I create opcodes, then later execute them.
18:04 jeffreykegler1 With Lua, I could instead just write, compile and execute the Lua code -- don't have to create my own VM.
18:07 jeffreykegler1 Marpa uses the mini-VM's for dealing with semantics.  All those semantics options are translated to short sequences of opcodes.  There's a stack, and Marpa performs the ops for each node on the stack.
18:08 jeffreykegler1 (What I've just described is how the SLIF's semantics works.)
18:09 jeffreykegler1 I need to create my own opcodes and mini-VM, because Perl is too expensive ...
18:09 Aria Yeah, unless you're REALLY comfy with XS. (Nobody's that comfortable with it)
18:10 jeffreykegler1 but Lua I'm hoping will hit the "sweet spot" -- still very efficient, but lots more power than my custom.
18:10 Aria That would be awesome
18:10 jeffreykegler1 That whole mini-VM I just described is implemented inside XS.
18:11 jeffreykegler1 It's in R3.xs, which is a huge, complicated file.
18:12 Aria Yeah. Ugh. I meant within the perl core, the horrible, slowly-grown beast.
18:13 jeffreykegler1 But, yes, being as tied into the Perl internals as you have to be to have thet much complex XS, is not a fully comfortable place to be.
18:14 jeffreykegler1 It's working out OK, but has reached the point where making even small changes and enhancements is a very painful prospect.
18:14 Aria Yeah.
18:15 jeffreykegler1 With Kollos, I hoping the XS interface will become very basic and simple, and the fancy stuff will happen in Lua.
18:38 Aria That would be nice.
18:43 jdurand joined #marpa
18:45 jdurand What is not clear to my mind is the unicode support in Lua, albeit Marpa does not care about values that are user-space stuff, but a SLIF equivalent interface will require full unicode support isn't it
19:13 jeffreykegler1 Kollos will not be fully SLIF-compatible.
19:14 jeffreykegler1 In particular, going forward Kollos will take its lead in the treatment of Unicode from Lua.
19:17 jeffreykegler1 As Roberto's talk on futures (which I linked a few days ago) showed, a surprising amount of Unicode stuff can be done in Lua today.
19:17 jeffreykegler1 But Lua will never attempt to support all the Unicode bells-and-whistles, with their huge complex tables
19:18 jeffreykegler1 Someone who needs this can put a layer on top of Lua/Kollos.
19:20 jeffreykegler1 Lua is, and Kollos will be 8-bit clean.  It will not fiddle with your strings, so that it will allow you to interpret strings any way you like at the upper level.
19:26 jeffreykegler1 Re Unicode: to give the big "strategy" picture.
19:27 jeffreykegler1 Perl 5 embraces complexity, and strives (with great success) to support every last Unicode bell and whistle.  Marpa has been following the Perl approach.
19:28 jeffreykegler1 Lua pursues simplicity, and strives to be efficient, and not get in the way of upper layers which need to treat strings in very special ways.
19:29 jeffreykegler1 Kollos will follow the Lua approach.
19:30 jeffreykegler1 The most serious regression will perhaps be that the SLIF allows you to use Unicode in the SLIF DSL itself.
19:32 jeffreykegler1 The SLIF's Kollos based successor will allow you to parse Unicode text, but its DSL will like Lua source code -- 8-bit, and 7-bit if you want avoid trouble.
19:33 jdurand yes, I've read that in Lua a string is just a byte sequence with no particular meaning, if I understood well - this is ok
19:34 jeffreykegler1 Here's the advantage: in supporting every bell & whistle of Perl/Unicode, I've made the interface so complex that I've been the "point of failure" -- if I don't write it, it does not happen.
19:35 jeffreykegler1 In going to Kollos, the interface will be transparent enough (I hope) that you can rewrite to support Unicode in the way you like.
19:36 jeffreykegler1 And I think there are Unicode libraries for Lua out there.
19:37 jeffreykegler1 In studying these matters, I've been impressed with Ierusalimschy's judgement and I think he's got the right approach for a toolkit.
19:39 jeffreykegler1 The tools in a toolkit have to be selectively chosen.
19:51 Aria I really, really, really favor the 'Everything is just bytes' approach; adding more layers of interpretation is much easier in specific places, rather than having it trickle into everywhere.
19:52 Aria Watching Ruby 1.8 to 1.9 transition (strings as bytes to strings as encoding sequences) was a terrible, terrible time.
19:52 Aria The number of places error handling had to be added, the sheer bulk of the interfaces was horrible.
22:16 jeffreykegler joined #marpa

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary