On Thu, Jun 17, 2010 at 5:04 PM, Darren Duncan <dar...@darrenduncan.net>wrote:
> Terrence, thank you for your feedback. > > Up front, I'll say that your message as a whole made me think of an > alternate approach. Rather than making the PTMD_STD dialect support these 2 > mutually-exclusive syntax options (by contrast, all the existing syntax > options are simply additive/subtractive not exclusive), I could just add a > separate dialect which is defined as being (initially) the same as PTMD_STD > but for not using the $ sigil. Then PTMD_STD as it is doesn't get changed, > and there is no extra True/False config option, but rather someone changes > the config by substituting a different dialect name for PTMD_STD, maybe > PTMD_NS_STD or something, so they are more clearly separate? The > PTMD_NS_STD spec would be a small delta document. this will create a Tower of Babel situation I think. It's nice to try to appease the masses, but having two things which are very similar but slightly different is an issue. One from a learning perspective. Two from dealing with other people's work that you need to extend. > > > Terrence Brannon wrote: > >> On Thu, Jun 17, 2010 at 2:44 PM, Darren Duncan <dar...@darrenduncan.net> >> wrote: >> I wanted to let you know that I plan ASAP to enhance the PTMD_STD >> (normal) >> dialect of Muldis D to be more friendly to people who like >> programming languages >> without sigils, so further towards Python/C/SQL/etc and from Perl/etc. >> >> what motivated this decision? did a lot of people make this request of >> you? >> > > While no one requested this change, part of the motivation comes from > feedback I got a couple weeks ago from a Python user who thought the syntax > looked too Perlish for them, I see and they were specific about what was too Perlish? > > > More support for the idea, of letting one write code without the sigils, is > another person's feedback to this same RFC that I got before yours. This > was a more database-centric person, who said that anything which made the > language look more like COBOL (as SQL does) is welcome. it looks like you are getting good crowd reaction from those people, so I would go with the Python/SQL approach as standard. > > > > > var people : Relation >> { people := Relation:{ name, addr } } >> >> it seems overly verbose to have two lines for this... could you not have >> done: >> >> var people : Relation:{name, addr } } >> > > Perhaps I could, but then it would be an alternate short form for the other > version. I actually considered it before, but omitted that for simplicity, > not that it can't come back. > You are reaching Java levels of verboseness if you cant declare and assign in a single line. that's a major turn-off for Python/Perl types. Maybe not DBA types. > > assign_insertion( &people, Tuple:{ >name, >addr } ) >> >> This ">" sign confuses me (of course I havent read the spec), but I >> immediately think of greater-than name without knowing more about this >> language. >> > > A "$>foo" is meant to be a mnemonic shorthand for a "foo => $foo", and > hence ">foo" is short for "foo => foo". It is analogous to the ":$foo" of > Perl 6 being short for "foo => $foo". > > oh that's a nice shorthand now that I know what it means :)