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 :)
