Re: [racket-users] Moving a Rust/Haskell abstract algebra library to Racket?

[Stuart Hungerford]

On Wednesday, 20 January 2021 at 12:34:59 UTC+11 Robby Findler wrote:

I'm no expert on algebras, but I think the way to work on this is not to 
> think "what Racket constructs are close that I might coopt to express what 
> I want?" but instead to think "what do I want my programs to look like" and 
> then design the language from there, reusing libraries as they seem helpful 
> or designing new ones that do what you want. Racket's 
> language-implementation facilities are pretty powerful (of course, if there 
> is nothing like what you end up needing, there will still be actual 
> programming to do ;).
>

Thanks Robby -- that's a very interesting way to look at library design 
that seems to make particular sense in the Racket environment.

Stu

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b56bd80d-dbc3-4bda-9aa2-07e2545a9ca7n%40googlegroups.com.

Re: [racket-users] Unsafe structs

[Sorawee Porncharoenwase]

However, ‘struct-field-info-list’ returns only fields defined by the
actual type and does not include fields that were inherited. What I
don’t see is any simple way to get at the struct’s inheritance hierarchy
—- it seems that you have to iterate ‘struct-type-info’ to enumerate the
supertypes.

Yes, that’s a (the?) way to extract field names of supertypes. The reason I
designed it in that way is that field name is a concept for each level in
the hierarchy, not across levels. You can’t have two identical field names
in a level, but you can have identical field names across levels. So
lumping field names across levels together doesn’t look like a good idea to
me.

On Fri, Jan 8, 2021 at 12:39 PM Sam Tobin-Hochstadt 
wrote:

> Thanks for this detailed account (and for trying it out). I have some
> questions inline:
>
>
> On Sat, Jan 2, 2021 at 5:34 PM Dominik Pantůček
>  wrote:
> > And now for the worse part. TR rough edges:
> >
> > * Higher-order procedures and polymorphic functions in all imaginable
> > combinations. That was a total disaster. Yes, the documentation clearly
> > states that - but typing any code using these is like trying to break a
> > badly designed cipher. Irregularities here and there. Sometimes simple
> > `inst' was enough. Sometimes casting both the function and the arguments
> > was necessary. The biggest trouble is that the error messages are very
> > cryptic and sometimes even do not point to the offending construct but
> > only the module file. I will provide MWE to show this if someone wants
> > to look into it.
>
> An example would be great here. In general you should only need one
> use of `inst` in any of these cases, and you shouldn't ever need a
> `cast`.
>
> > * Struct: Missing struct generics - when porting code that relies on
> > them, there's not much that can be done.
>
> This is indeed a limitation -- struct generics are complex and we
> (mostly Fred Fu) are thinking about them, but it's not there yet.
>
> > * Math: there really is just a natural logarithm and no logarithm with
> > arbitrary base? Yes, one-line to implement, but why?
>
> I'm not sure why this didn't get added originally, but it's easy to fix.
>
> > * Math/Fixnums/Flonums: All fx+/-/*/... accept two arguments only. No
> > unary fl-, no variadic-argument fl+ or fxior (this one hurt the most).
>
> These definitely became variadic after the type definitions were
> written, but that's of course not an excuse for not updating them.
>
> > * unsafe/ops: unsafe-vector-* resisted a lot - until I just gave up and
> > require/typed it for my particular types. Maybe casting would help, but
> > the error messages were different to the classical problems of the
> > polymorphic functions in TR.
>
> Can you say more about what happened here?
>
> > * Classes: My notes say "". Which roughly says it
> > all. Although I managed to back down to only using bitmap% class,
> > properly typing all procedures using it was a nightmare. By properly I
> > mean "it compiles and runs".
>
> More detail here would be helpful as well.
>
> > * with-input-from-file does not accept Path or String, only Path-String
> > and the conversion rules are either missing or strange at best.
> > Basically I ended up with just converting to String and casting to
> > Path-String to make everything work.
> >
> > * with-input-from-file also revealed that procedure signatures as types
> > can be very tricky - just passing `read' was not possible, because it
> > accepts some optional arguments. Wrapping it in thunk helped though.
>
> I don't understand what the problem was here; for example this works for
> me:
>
> #lang typed/racket
> (with-input-from-file "/tmp/x.rkt" read)
>
> and `Path-String` is just the union of Path and String.
>
> > * order of definitions matters. Not that this is unexpected, it is just
> > strange when working with larger code-base where it didn't matter.
> > Actually the error messages were helpful here.
>
> What do you mean by "order of definitions matters" here?
>
> > * Type annotations of procedures with variadic arguments. The only place
> > where I had to put annotations outside of the procedure definition. It
> > is nothing super-problematic, but it feels inconsistent with the rest.
>
> I would encourage type annotations before the procedure definition in
> all cases -- the `define` form doesn't really have the right places to
> put everything that can go in a function type.
>
> > * More modules need to be required everywhere. If module A provides a
> > procedure that accepts a type from module B, all modules using that
> > procedure must also require the module B to know the type. In normal
> > Racket it does not matter as long as you just pass the opaque data along.
>
> Can you give an example?
>
> > * Syntax macros are extra hard. As I use some syntax trickery to convert
> > semi-regular code to "futurized" one, I basically gave up and just ran
> > everything single-threaded. The main issue is passing 

Re: [racket-users] Moving a Rust/Haskell abstract algebra library to Racket?

[Robby Findler]

I'm no expert on algebras, but I think the way to work on this is not to
think "what Racket constructs are close that I might coopt to express what
I want?" but instead to think "what do I want my programs to look like" and
then design the language from there, reusing libraries as they seem helpful
or designing new ones that do what you want. Racket's
language-implementation facilities are pretty powerful (of course, if there
is nothing like what you end up needing, there will still be actual
programming to do ;).

Robby


On Tue, Jan 19, 2021 at 4:58 PM Stuart Hungerford <
stuart.hungerf...@gmail.com> wrote:

> Hi Racketeers,
>
> I'd like to try re-implementing a library for experimenting with abstract
> algebraic structures in Racket (that is groups, fields, rings etc, not
> algebraic data types like sum or product types). With Racket's strong
> numeric hierarchy and programmable programming language philosophy it seems
> like a good environment for experimenting with mathematical structures.
>
> This library was originally developed in Rust and more recently Haskell
> and made heavy use of Rust traits and Haskell typeclasses to implement
> these structures for the builtin numeric types as a well as my own derived
> numeric types (e.g. finite fields). I understand Racket is not Haskell (or
> Rust) and naively trying to emulate typeclasses or traits in Racket will
> likely lead to un-idiomatic code. Having said that, what Racket idioms
> would be most useful for this kind of project?
>
> A typical typeclass (from the Haskell version) would be:
>
> ```
> class Monoid a => Group a where
>
>   inverse :: a -> a
>
>   power :: Int -> a -> a
> ```
>
> Thanks,
>
> Stu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/a1ce47b2-9dab-4b33-b50b-557bfef7e331n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOM_pt6EfuXvov8jWb_%3D9u%2BqaKh2UN7bhaaYFYruaQmfJg%40mail.gmail.com.

[racket-users] Moving a Rust/Haskell abstract algebra library to Racket?

[Stuart Hungerford]

Hi Racketeers,

I'd like to try re-implementing a library for experimenting with abstract 
algebraic structures in Racket (that is groups, fields, rings etc, not 
algebraic data types like sum or product types). With Racket's strong 
numeric hierarchy and programmable programming language philosophy it seems 
like a good environment for experimenting with mathematical structures.

This library was originally developed in Rust and more recently Haskell and 
made heavy use of Rust traits and Haskell typeclasses to implement these 
structures for the builtin numeric types as a well as my own derived 
numeric types (e.g. finite fields). I understand Racket is not Haskell (or 
Rust) and naively trying to emulate typeclasses or traits in Racket will 
likely lead to un-idiomatic code. Having said that, what Racket idioms 
would be most useful for this kind of project?

A typical typeclass (from the Haskell version) would be:

```
class Monoid a => Group a where

  inverse :: a -> a

  power :: Int -> a -> a
```

Thanks,

Stu

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a1ce47b2-9dab-4b33-b50b-557bfef7e331n%40googlegroups.com.