Andrei Alexandrescu wrote:
> Alexander Pánek wrote:
>> Andrei Alexandrescu wrote:
>>> The problem I see with "!" as a template instantiation is not
>>> technical. I write a fair amount of templated code and over years the
>>> "!" did not grow on me at all. I was time and again consoled by
>>> Walter than one day that will happen, but it never did. I also
>>> realized that Walter didn't see a problem with it because he writes
>>> only little template code.
>>>
>>> I didn't have much beef with other oddities unique to D. For example,
>>> I found no problem accommodating binary "~" and I was wondering what
>>> makes "!" different. I was just looking at a page full of templates
>>> and it looked like crap.
>>>
>>> One morning I woke up with the sudden realization of what the problem
>>> was: the shouting.
>>>
>>> In C, "!" is used as a unary operator. That may seem odd at first,
>>> but it nevers follows a word so it's tenuous to associate it with the
>>> natural language "!". In D, binary "!" _always_ follows a word, a
>>> name, something coming from natural language. So the conotation with
>>> exclamation jumps at you.
>>>
>>> That's why I find the choice of "!" poor. I believe it can impede to
>>> some extent acquisition of templates by newcomers, and conversely I
>>> believe that using .() can make templates more palatable. I tried
>>> using ".()" in my code and in only a couple of days it looked and
>>> felt way better to me. Based on that experience, I suggest that "!()"
>>> is dropped in favor of ".()" for template instantiation for D2.
>>>
>>> Sean's argument that "The exclamation mark signifies an assertion of
>>> sorts" is exactly where I'd want templates not to be: they should be
>>> blended in, not a hiccup from normal code. Serious effort has been,
>>> and still is, made in D to avoid shell-shocking people about use of
>>> templates, and I think ".()" would be a good step in that direction.
>>
>> Sean has a point. Templates are not runtime constructs. So a clear
>> distinction between instantiating a function with a given type and
>> just calling a function that has fixed argument types and a fixed
>> return type is necessary.
>
> Why? This sounds objective, so you better back it up. Au contraire, I
> see absolutely, but absolutely no need for a distinction. If it weren't
> for syntactic difficulties, to me using straight parentheses for
> template instantiation would have been the perfect choice. (How many
> times did you just forget the "!"? I know I often do. Why? Because most
> of the time it's not even needed.)
>
>> The exclamation mark gives us this clear distinction and has served
>> well in terms of readability for me, especially because it jumps out —
>> not because it’s an exclamation mark, thus having a meaning in natural
>> language, but rather just because of its form. A straight vertical
>> line with a dot underneath it. That just works perfectly well as
>> seperator between identifier/type and type argument.
>
> I believe the clear distinction is not only unnecessary, but
> undesirable. We should actively fight against it.
IMHO — I forgot that before, so that’s why it might have sounded a bit
too objective —, the clear distinction is important to keep the code
self-documenting. It might not be so important in terms of freestanding
templated functions that might even be simple enough that the argument
types can be infered, but as soon as something heavily alters the way
the code and the binary looks like afterwards (CTFE, multiple templated
class/struct/function instantiates, string mixins created by CTFE
functions, etc.), it (again, in my truly subjective opinion) deserves to
be marked as such.
I see this distinction as feature, not as flaw.

Alexander Pánek wrote:
> Andrei Alexandrescu wrote:
>> Alexander Pánek wrote:
>>> Andrei Alexandrescu wrote:
>>>> The problem I see with "!" as a template instantiation is not
>>>> technical. I write a fair amount of templated code and over years
>>>> the "!" did not grow on me at all. I was time and again consoled by
>>>> Walter than one day that will happen, but it never did. I also
>>>> realized that Walter didn't see a problem with it because he writes
>>>> only little template code.
>>>>
>>>> I didn't have much beef with other oddities unique to D. For
>>>> example, I found no problem accommodating binary "~" and I was
>>>> wondering what makes "!" different. I was just looking at a page
>>>> full of templates and it looked like crap.
>>>>
>>>> One morning I woke up with the sudden realization of what the
>>>> problem was: the shouting.
>>>>
>>>> In C, "!" is used as a unary operator. That may seem odd at first,
>>>> but it nevers follows a word so it's tenuous to associate it with
>>>> the natural language "!". In D, binary "!" _always_ follows a word,
>>>> a name, something coming from natural language. So the conotation
>>>> with exclamation jumps at you.
>>>>
>>>> That's why I find the choice of "!" poor. I believe it can impede to
>>>> some extent acquisition of templates by newcomers, and conversely I
>>>> believe that using .() can make templates more palatable. I tried
>>>> using ".()" in my code and in only a couple of days it looked and
>>>> felt way better to me. Based on that experience, I suggest that
>>>> "!()" is dropped in favor of ".()" for template instantiation for D2.
>>>>
>>>> Sean's argument that "The exclamation mark signifies an assertion of
>>>> sorts" is exactly where I'd want templates not to be: they should be
>>>> blended in, not a hiccup from normal code. Serious effort has been,
>>>> and still is, made in D to avoid shell-shocking people about use of
>>>> templates, and I think ".()" would be a good step in that direction.
>>>
>>> Sean has a point. Templates are not runtime constructs. So a clear
>>> distinction between instantiating a function with a given type and
>>> just calling a function that has fixed argument types and a fixed
>>> return type is necessary.
>>
>> Why? This sounds objective, so you better back it up. Au contraire, I
>> see absolutely, but absolutely no need for a distinction. If it
>> weren't for syntactic difficulties, to me using straight parentheses
>> for template instantiation would have been the perfect choice. (How
>> many times did you just forget the "!"? I know I often do. Why?
>> Because most of the time it's not even needed.)
>>
>>> The exclamation mark gives us this clear distinction and has served
>>> well in terms of readability for me, especially because it jumps out
>>> — not because it’s an exclamation mark, thus having a meaning in
>>> natural language, but rather just because of its form. A straight
>>> vertical line with a dot underneath it. That just works perfectly
>>> well as seperator between identifier/type and type argument.
>>
>> I believe the clear distinction is not only unnecessary, but
>> undesirable. We should actively fight against it.
>
> IMHO — I forgot that before, so that’s why it might have sounded a bit
> too objective —, the clear distinction is important to keep the code
> self-documenting. It might not be so important in terms of freestanding
> templated functions that might even be simple enough that the argument
> types can be infered, but as soon as something heavily alters the way
> the code and the binary looks like afterwards (CTFE, multiple templated
> class/struct/function instantiates, string mixins created by CTFE
> functions, etc.), it (again, in my truly subjective opinion) deserves to
> be marked as such.
>
> I see this distinction as feature, not as flaw.
I don't understand this argument. For one thing, argument type deduction
for template functions is not simple at all and we're glad that it's
taken care of.
Andrei

Graham St Jack wrote:
> I prefer your suggestion of ufloat/udouble/ureal to Positive, and I
> would definitely use these. I already use unsigned integer types a
> LOT, even more than signed ones.
>
> Have you thought how (and if) auto-casting would work?
I did, and it would work. The problem is there's no precedent for it.
double x;
...
auto y = sqrt(x);
That will do a runtime check and throw if x is negative. That's
unprecedented for an implicit cast, so I was thinking of defining a
universal "unsigned" template function that does the check:
auto y = sqrt(unsigned(x));
> As far as template instantiation goes, my feeling is that the "." is
> too easily confused with method invocation. I know you are trying to
> make them look more similar, but for we mere mortals that don't do
> much template programming, we need something that stand out more.
> Something less alarming than "!" would be ok, so long as there was
> ONLY ONE way.
I agree that in the end there should be only one man standing. And the
reference to mere mortals makes me think we should bring the mountain to
them instead of them to the mountain. I know, lame metaphor.
Andrei

superdan wrote:
> Andrei Alexandrescu Wrote:
>
>> dsimcha wrote:
>>> == Quote from Andrei Alexandrescu
>>> (SeeWebsiteForEmail@erdani.org)'s article
>>>> The problem I see with "!" as a template instantiation is not
>>>> technical. I write a fair amount of templated code and over
>>>> years the "!" did not grow on me at all. I was time and again
>>>> consoled by Walter than one day that will happen, but it never
>>>> did. I also realized that Walter didn't see a problem with it
>>>> because he writes only little template code. I didn't have much
>>>> beef with other oddities unique to D. For example, I found no
>>>> problem accommodating binary "~" and I was wondering what makes
>>>> "!" different. I was just looking at a page full of templates
>>>> and it looked like crap. One morning I woke up with the sudden
>>>> realization of what the problem was: the shouting. In C, "!" is
>>>> used as a unary operator. That may seem odd at first, but it
>>>> nevers follows a word so it's tenuous to associate it with the
>>>> natural language "!". In D, binary "!" _always_ follows a word,
>>>> a name, something coming from natural language. So the
>>>> conotation with exclamation jumps at you. That's why I find the
>>>> choice of "!" poor. I believe it can impede to some extent
>>>> acquisition of templates by newcomers, and conversely I believe
>>>> that using .() can make templates more palatable. I tried using
>>>> ".()" in my code and in only a couple of days it looked and
>>>> felt way better to me. Based on that experience, I suggest that
>>>> "!()" is dropped in favor of ".()" for template instantiation
>>>> for D2. Sean's argument that "The exclamation mark signifies an
>>>> assertion of sorts" is exactly where I'd want templates not to
>>>> be: they should be blended in, not a hiccup from normal code.
>>>> Serious effort has been, and still is, made in D to avoid
>>>> shell-shocking people about use of templates, and I think ".()"
>>>> would be a good step in that direction. Andrei
>>> Personally, I think that ".()" looks a little too much like a
>>> normal function/method call. The "!()" syntax looks just
>>> different enough to make it easy to keep straight in my head that
>>> stuff with the "!" is a compile-time construct and stuff without
>>> it can be evaluated at runtime.
>> I'm arguing we _should_ make template code look like "normal" code,
>> whatever "normal" is :o). We _should_ strive for "quiet"
>> templates.
>>
>> You know what annoys the living heebiejeebies out of me? Nested
>> template instantiations.
>>
>> This!(That!(TheOther!(crap)))
>>
>> I have a ton + change of those. In superdan's words: intercourse
>> that.
>>
>>
>> Andrei
>
> im a bit drunk. but im much obliged since my name was mentioned n
> all.
>
> ! pisses me off too. i have an opinion. walter looked at unary ops
> that can be binary ops. first tilde. pulled tat off. ten he wanted
> the template thing. only 1 left was !. so he put that at work. right
> walt? now i never like ! because of nother reason. i always forget to
> put it. and yes it's not needed. i look @ code its unambig. then wtf
> do i need that crap !
>
> anyhoo would be great if ! goes away. to hell with it. need to try
> asdad.(asdasd) to see how it feels. and yeah they all jump andreis
> neck whever he posts any. or walts. its funny. hold them guns folks.
> can i delete this later i wonder.
I guess this still counts as a vote! No? :o)
Andrei

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Steven Schveighoffer wrote:
>>>> It's very alarming to me that something like this just has no problem
>>>> getting in the language without community feedback.
>>> It's there at the moment so we can look at it and see if we like it. I
>>> know Andrei likes it. Anyhow, this is the opportunity for community
>>> feedback.
>>
>> Well, here is my feedback.
>>
>> First, I hate it when D has two ways of doing something. For example, C
>> style array declarations, or function pointers. But those have good
>> reasons. We want the new style because it's unambiguous and
>> context-free, but we want the old style to allow easy porting of C code.
>
> I agree that D should not gratuitously define two ways of doing something.
>
>> But this change has no qualities I can see except that Andrei thinks it
>> looks better (at least, that's the only reason he's given).
>
> Believes, not thinks :o).
yes, of course, my bad.
>
>> There are not compatibility issues with C or some other language, it's
>> just a new syntax that looks different. Are there problems with the
>> original !()? Please give a reason for this addition besides asthetics,
>> and then we can discuss the merits. Or if the community overwhelmingly
>> loves this new syntax, I guess that's a good reason. Otherwise, I think
>> it should be rejected on the simple principle of not fixing things that
>> aren't broken.
>
> There are no objective differences, only the subjective arguments I
> brought based on linguistic conotations of "!". And actually I didn't come
> up with that argument - it literally came to me. Word followed by
> exclamation mark. Our brains are wired to interpret that as an
> exclamation. If it's frequent enough in code, it becomes really jarring.
For what it's worth, I never had a 'jarring' experience with the ! syntax.
It reads perfectly fine to me, and I actually like it.
> The one way to figure whether you'd aesthetically like something or not is
> to try it on some code. Unfortunately, that's not yet possible until the
> next release (Walter was kind enough to send me an alpha for a test
> drive). So my only request is kindly please hold off judgment until you
> can play with the notation and see how you feel.
Firstly, I won't be playing with it unless it's released for D1 (which I
doubt), and secondly, I don't think it's worth the effort to have something
like this changed for minor annoyance. Since it's completely engrained on
our brains already and we get along fine with !, there should have to be a
really good reason to change it. 'looking better' doesn't strike me as a
really good reason, especially when it is subjective (and especially when I
disagree with the opinion). This seems like a bicycle shed issue to me.
Please note, I'm not arguing for ! because of some technical reason, I
probably would have been fine with ., but since it's already !, I think we
should keep it that way unless a good technical reason comes up. The
reasons you have put forth don't make it worth it in my mind.
If this change is implemented, Walter is going to have a hard time arguing
that it's not worth changing invariant to immutable...
-Steve

Andrei Alexandrescu wrote:
> Alexander Pánek wrote:
>> Andrei Alexandrescu wrote:
>>> The problem I see with "!" as a template instantiation is not
>>> technical. I write a fair amount of templated code and over years the
>>> "!" did not grow on me at all. I was time and again consoled by
>>> Walter than one day that will happen, but it never did. I also
>>> realized that Walter didn't see a problem with it because he writes
>>> only little template code.
>>>
>>> I didn't have much beef with other oddities unique to D. For example,
>>> I found no problem accommodating binary "~" and I was wondering what
>>> makes "!" different. I was just looking at a page full of templates
>>> and it looked like crap.
>>>
>>> One morning I woke up with the sudden realization of what the problem
>>> was: the shouting.
>>>
>>> In C, "!" is used as a unary operator. That may seem odd at first,
>>> but it nevers follows a word so it's tenuous to associate it with the
>>> natural language "!". In D, binary "!" _always_ follows a word, a
>>> name, something coming from natural language. So the conotation with
>>> exclamation jumps at you.
>>>
>>> That's why I find the choice of "!" poor. I believe it can impede to
>>> some extent acquisition of templates by newcomers, and conversely I
>>> believe that using .() can make templates more palatable. I tried
>>> using ".()" in my code and in only a couple of days it looked and
>>> felt way better to me. Based on that experience, I suggest that "!()"
>>> is dropped in favor of ".()" for template instantiation for D2.
>>>
>>> Sean's argument that "The exclamation mark signifies an assertion of
>>> sorts" is exactly where I'd want templates not to be: they should be
>>> blended in, not a hiccup from normal code. Serious effort has been,
>>> and still is, made in D to avoid shell-shocking people about use of
>>> templates, and I think ".()" would be a good step in that direction.
>>
>> Sean has a point. Templates are not runtime constructs. So a clear
>> distinction between instantiating a function with a given type and
>> just calling a function that has fixed argument types and a fixed
>> return type is necessary.
>
> Why? This sounds objective, so you better back it up.
I like being able to distinguish between the function signature and the
parameter list and to tell at a glance what's actually happening. Since
the dot already has a function in this context, I don't think it should
be given another. Also, if we get the option to override opDot, things
could get really weird if it's also a template signifier.
>> The exclamation mark gives us this clear distinction and has served
>> well in terms of readability for me, especially because it jumps out —
>> not because it’s an exclamation mark, thus having a meaning in natural
>> language, but rather just because of its form. A straight vertical
>> line with a dot underneath it. That just works perfectly well as
>> seperator between identifier/type and type argument.
>
> I believe the clear distinction is not only unnecessary, but
> undesirable. We should actively fight against it.
Why is it undesirable? I like the idea of static parameters as
described at the conference last year, but I don't think that has any
bearing on this particular issue.
Sean

Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Steven Schveighoffer wrote:
>>>> It's very alarming to me that something like this just has no
>>>> problem getting in the language without community feedback.
>>> It's there at the moment so we can look at it and see if we like it.
>>> I know Andrei likes it. Anyhow, this is the opportunity for community
>>> feedback.
>>
>> Well, here is my feedback.
>>
>> First, I hate it when D has two ways of doing something. For example,
>> C style array declarations, or function pointers. But those have good
>> reasons. We want the new style because it's unambiguous and
>> context-free, but we want the old style to allow easy porting of C code.
>
> I agree that D should not gratuitously define two ways of doing something.
>
>> But this change has no qualities I can see except that Andrei thinks
>> it looks better (at least, that's the only reason he's given).
>
> Believes, not thinks :o).
>
>> There are not compatibility issues with C or some other language, it's
>> just a new syntax that looks different. Are there problems with the
>> original !()? Please give a reason for this addition besides
>> asthetics, and then we can discuss the merits. Or if the community
>> overwhelmingly loves this new syntax, I guess that's a good reason.
>> Otherwise, I think it should be rejected on the simple principle of
>> not fixing things that aren't broken.
>
> There are no objective differences, only the subjective arguments I
> brought based on linguistic conotations of "!". And actually I didn't
> come up with that argument - it literally came to me. Word followed by
> exclamation mark. Our brains are wired to interpret that as an
> exclamation. If it's frequent enough in code, it becomes really jarring.
I like the use of '!' specifically for its linguistic connotation. It
communicates to me that what's happening isn't normal run-time stuff.
> The one way to figure whether you'd aesthetically like something or not
> is to try it on some code. Unfortunately, that's not yet possible until
> the next release (Walter was kind enough to send me an alpha for a test
> drive). So my only request is kindly please hold off judgment until you
> can play with the notation and see how you feel.
Will do. It's easy enough to search-replace '!' with '.'
Sean

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> "Walter Bright" wrote
>>>> Steven Schveighoffer wrote:
>>>>> It's very alarming to me that something like this just has no problem
>>>>> getting in the language without community feedback.
>>>> It's there at the moment so we can look at it and see if we like it. I
>>>> know Andrei likes it. Anyhow, this is the opportunity for community
>>>> feedback.
>>> Well, here is my feedback.
>>>
>>> First, I hate it when D has two ways of doing something. For example, C
>>> style array declarations, or function pointers. But those have good
>>> reasons. We want the new style because it's unambiguous and
>>> context-free, but we want the old style to allow easy porting of C code.
>> I agree that D should not gratuitously define two ways of doing something.
>>
>>> But this change has no qualities I can see except that Andrei thinks it
>>> looks better (at least, that's the only reason he's given).
>> Believes, not thinks :o).
>
> yes, of course, my bad.
>
>>> There are not compatibility issues with C or some other language, it's
>>> just a new syntax that looks different. Are there problems with the
>>> original !()? Please give a reason for this addition besides asthetics,
>>> and then we can discuss the merits. Or if the community overwhelmingly
>>> loves this new syntax, I guess that's a good reason. Otherwise, I think
>>> it should be rejected on the simple principle of not fixing things that
>>> aren't broken.
>> There are no objective differences, only the subjective arguments I
>> brought based on linguistic conotations of "!". And actually I didn't come
>> up with that argument - it literally came to me. Word followed by
>> exclamation mark. Our brains are wired to interpret that as an
>> exclamation. If it's frequent enough in code, it becomes really jarring.
>
> For what it's worth, I never had a 'jarring' experience with the ! syntax.
> It reads perfectly fine to me, and I actually like it.
>
>> The one way to figure whether you'd aesthetically like something or not is
>> to try it on some code. Unfortunately, that's not yet possible until the
>> next release (Walter was kind enough to send me an alpha for a test
>> drive). So my only request is kindly please hold off judgment until you
>> can play with the notation and see how you feel.
>
> Firstly, I won't be playing with it unless it's released for D1 (which I
> doubt), and secondly, I don't think it's worth the effort to have something
> like this changed for minor annoyance. Since it's completely engrained on
> our brains already and we get along fine with !, there should have to be a
> really good reason to change it. 'looking better' doesn't strike me as a
> really good reason, especially when it is subjective (and especially when I
> disagree with the opinion). This seems like a bicycle shed issue to me.
hehe... how about we swap '!' for '.' and in exchange we get to use
something other than 'enum' for manifest constants ;-)
Sean

Andrei Alexandrescu wrote:
> Hello,
>
>
> (Background: Walter has kindly allowed ".()" as an alternative to the
> ugly "!()" for template argument specifications.)
>
> Just a quick question - I am feeling an increasing desire to add a
> template called Positive to std.typecons. Then Positive.(real) would
> restrict its values to only positive real numbers etc.
>
> The implementation would accept conversion from its base type, e.g.
> Positive.(real) can be constructed from a real. The constructor enforces
> dynamically the condition. Also, Positive.(real) accepts implicit
> conversion to real (no checking necessary).
>
> There are many places in which Positive can be useful, most notably
> specifications of interfaces. For example:
>
> Positive.(real) sqrt(Positive.(real) x);
>
> These specifications are also efficient because checking for positivity
> is done outside sqrt; if you had a Positive.(real) to start with, there
> is no cascading checking necessary so there's one test less to do.
>
> However, there is also the risk that Positive has the same fate the many
> SafeInt implementation have had in C++: many defined them, nobody used
> them. What do you think? If you had Positive in std and felt like
> crunching some numbers, would you use it?
>
> In order to get things really started, there's already been an exchange
> with Walter on the matter. His reply was (I haven't asked for
> permission, but I'm pretty sure he'd agree making it public):
>
> ==============
> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt
> that asserts the argument is positive. Also, this opens the door to
> Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime,
> SixOrFifteen, etc.
> ==============
>
> My answer to that was:
>
> ==============
> About contracts: Let me explain how I think that's inferior to Positive
> in two ways.
>
> 1. Enough functions are defined on positive numbers only, to justify
> factoring that contract out of the functions themselves.
>
> 2. The efficiency perk is that when using several such functions
> together, there's only one check; once in Positive-land, no more checks
> are necessary.
>
> About proliferation of types: I don't think that follows at all. Math
> found positive numbers special enough to dedicate them a special
> notation (|R with subscript "+"). There's also a special notation for
> nonzero real numbers (|R with superscript "*"). There is no special
> notation for any of the sets you mentioned. That is bound to mean
> something.
> ==============
>
> I'm interesting in further arguments. This feature is a numbers issue
> (pun not intended), meaning it will be any good only if enough people
> find it useful enough to actually use it in their own code and
> libraries, therefore building momentum behind it.
>
>
> Andrei
As others have mentioned.
Why a second class form of range restriction? Why not a first class
implementation like ADA's with ranges and subranges as specific
typedefs? I know it would be more work for the compiler writer to
implement (if it can't be done in templates) however I prefer more
generic solutions then having many once-off solutions that crudely fit
together.
Being able to simply pick a type that is within the range needed would
save having to write contracts and static contracts all over the place.
It also a great form of documentation. I would find that useful,
particularly when working with algorithms that traverse arrays in
specific sequences such as spacial data structures but need to maintain
certain constraints.
-Joel

On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> said:
> I don't favor "." any more than the next guy, but I am glad there is
> awareness of how unfit a choice "!" is. If you have any ideas, please
> post them! Ah! I! Exclaimed! Again!
Hum, I don't think we have much choice, it'll have to be something in this lot:
Positive!(real)(joke);
Positive.(real)(joke);
Positive#(real)(joke);
Positive@(real)(joke);
Positive&(real)(joke);
Positive`(real)(joke);
Positive´(real)(joke);
Positive^(real)(joke);
Positive¨(real)(joke);
Positive\(real)(joke);
Anything else I forgot?
Or we could use special delimiter characters:
Positive<real>(joke);
Positive“real”(joke);
Positive«real»(joke);
Positive#real@(joke);
Each having its own problem though.
My preference still goes to "!(".
- - -
The ".(" syntax makes me think more of something like this:
void func(T, alias methodOfT, A...)(T obj, A args)
{
obj.(methodOfT)(args);
}
which I which I could do. If methodOfT was a string, I suppose I could
use string mixins, but it pushes diagnostics about misnamed methods
further in the template and requires adding quotes to the template
parameter when instanciating.
--
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/