Hi again Joel,
I think that you are refering to the 'module functions that are promised for
version 3.0? If that is the case then maybe we should be patient and in the
mean time develop the dialect that effectively emulates a percent dataype, i
just wonder....
>> type? 55%
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) type? 55%
>> [55%]
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) [55%]
>> parse [55%] rules
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) parse [55%] rules
hm... It appears that a dialect as has been described wouldn't even be
possible. Any ideas?
Enjoy!!
Ammon
A short time ago, Joel Neely, sent an email stating:
> Hi, Gregg,
>
> Gregg Irwin wrote:
> > We could go on with every single SI unit in existance?
> >
> >
> > Not a stupid idea at all. This is where I see dialects playing an
> > important role, and comes back to what I said in my reply to Andrew,
> > that this is where I've thought percentages would fit best.
>
> I agree completely. Such things belong in a dialect, not in the
> core language.
>
> Looking back at the history of programming languages, there's an
> issue of balance between
>
> a simple language a bloated language
> which is small and which is complex and
> easy to learn, but and impossible to learn
> too small for real because of unbridled
> programming tasks feature creep
> (and so never used) (and so never used)
>
>
> There's a "sweet spot" in the middle, and I respectfully suggest
> that REBOL/Core should seek to find (and STAY IN) that zone. The
> whole idea of an extensible language is to provide the most common
> and useful set of features, along with a simple means for the
> programmer to add those concepts that are required for the special
> circumstances of a particular task/project.
>
> That said...
>
>
> Instead of asking for specific twiddles, I'd be interested in the
> response of RT to the ideas of either:
>
> - providing a means for extending the syntax within dialects so
> that new forms could be added at the mezzanine level, or
>
> - providing a means for switching on/off classes of extensions
> (perhaps coded natively) to avoid bloat and namespace collisions
> for those cases where the extensions are not needed.
>
> Thoughts, anyone?
>
> -jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
