[racket] syntax, differently

On Wed, Aug 18, 2010 at 12:45 PM, Jakub Piotr Cłapa <jpc-ml at zenburn.net>wrote:

> On 18.08.10 17:22, Ray Racine wrote:
>
>> This topic comes up so frequently (schemes structure accessors/mutators)
>> , and has been independently solved in and around the same conceptual
>> solution (a chaining dot syntax) that I've often wondered why Racket
>> would not make such a capability "core" to the language.  ...
>>
>
> Because what Eduardo did is a quick hack and what you would really like in
> the core is to make use of Typed Scheme annotations. Maybe a way to reuse
> the annotations without the type cheking but it may not be convenient
> without (local) type inference.
>
> Agreed, I'm familiar with his general approach, which is why I emphasized a
"core" solution.  What does fly well above my head, but suspect might be the
case, is any truly solid, seamless solution offering a chaining dot syntax
for record/structure access cannot be done in the old DrScheme "scheme"
context without leaking abstractions, adverse performance implications, and
tinged with a kludge patina about it, etc.  I also suspect that  IF dotted
syntax for record access were added it would have to be carefully thought
through, require a great deal of work to implement, and at the end of the
day woven into the core of the language implementation and definition, i.e.,
any "bolt-on" solution would end up less than satisfactory in one way or
another.

 But Racket is now unfettered by the constraints of being a superset
definition of Scheme, no more so then Closure is bound by CL.  Racket is now
its own language onto itself and therefore free to define its own nature.


> It can also be done like it is in Python/Ruby/JavaScript/Smalltalk but this
> adds quite a big performance hit if not JITed very cleverly (look up tracing
> JIT compilers for JavaScript).
>

Internal representation of an "objects" properties as an association map
verses say an offset layout representation is just that an internal
representation only.  Certain semantics may be honored or not independent of
the internal representation such as the behavior on accessing a property
with an undefined value or even an undefined property.   Certain operations
may be decidedly more difficult or substantially easier based on the chosen
internal representation with various comprises and tradeoffs reached along
the way.

But I'm not advocating Racket change its internal record/structure layout
per se, only suggesting a consideration of an alternate operational syntax
for record/structure data.  Racket already has an OO feature set.

In the "old" DrScheme days, I suspect most of the language extension debates
were constrained by the desire to remain, in essence, schemely.  Based on
some remarks I viewed from the core members on the list, in the bold new
world of Racket, there is heavier weight given to a potential language
extension as to whether the feature is a pragmatic extension of the language
that helps coders out there writing real apps,  startups, production code,
get things done or maybe makes the language a bit more 'fun' to use and
ameliorates a frustration or two.

In summary what I'm asking is a two-fold question, 'if' adding a dotted
syntax to the core of the Racket language has come up for consideration.  If
it has, what was the outcome and could a little color around the pros/cons
that lead to the final decision could be stipulated on the list.  Either way
I still use Racket.


-- 
The object of life is not to be on the side of the majority, but to escape
finding oneself in the ranks of the insane. - Marcus Aurelius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100818/a3fbd065/attachment.html>